Xojo

My Xojo Wish List for 2018

A new year and another XDC coming up which gives us opportunity to reflect on where we are and where we are going with Xojo. If you are like me Xojo is your favorite programming tool to use and I rely on it daily to build great experiences for customers. However, that is not to say that it is not without fault or room for improvement.

I wanted to take some time to discuss my top wishes for 2018 from Xojo, Inc:

#1 “New” Framework Progress

First and foremost, I want to see the inevitable conclusion of the “New” framework on all operating systems and targets. I want to see a plan for enhanced language features and classes and capabilities that Xojo will offer us. I want to see all UI widgets and controls support the new native types introduced with Apple iOS in 2014!

Since that time, we have seen very little improvements to either the new framework, the iOS platform, or otherwise. In November of last year, I asserted that the “New” framework was a dud. There had been no meaningful improvement or announcements about potential improvements in recent history. The post created a bit of controversy but alas my call for someone at Xojo to step up and be the “language czar” and talk about all the cool things Xojo will enable in the future has gone unanswered.

If Xojo is to compete in the future as a rapid application development platform and language then it is vital they learn from their competition. An example of such is concurrency which I have highlighted in the past.

#2 Console Helper Apps

Xojo threads are a misnomer and do not help you in any meaningful way speed up the performance of your application or operate concurrently in the background. They were at best an abstraction model for separating sophisticated methods from the user interface. However, since the change of no longer allowing threads to access the user interface, you end up having to use timers which are more work to setup and more difficult to manage.

Never mind that in Xojo your application is only able to utilize a single core at a time so now the tricky mess of thread and timer management is hardly worth the effort. For anything sophisticated that you may want to do without locking up the user interface you are advised to build console helper applications. The idea is that the operating system will distribute your workload across all the available CPU cores as needed and saving you the mental effort of true threading model.

Unfortunately, building console helper apps is much more difficult than it needs to be. I first wrote about the need for the IDE to abstract away a huge portion of this effort in the first part of my 2017 review series in March of last year. I have not received any feedback from Xojo or heard anything in this area to facilitate this need. It is getting harder to sell Xojo as a rapid application development tool when your projects become significantly more complex when the IDE could so clearly help you. I hope to see some announcements in this area at XDC.

#3 Interops

I believe Interops were first announced at XDC 2016 and slated for a 2017 Q4 release. I understand that last year had some priority adjustments and so I am not unhappy with the timeliness on this one. However, as declares are essentially critical to producing any meaningful iOS results I am very keen to get more information about this feature. There is a session on it at XDC 2018 so I am very excited to see what they have cooking.

#4 Android

It would not be a complete list unless it mentioned Android as it rounds out the platform and makes Xojo consultants more marketable. I will however caveat that with saying if it is released in such a minimal manner as iOS and maintained as poorly then it will simply be marketing fluff. Xojo really needs to commit to mobile and bring their best creative minds to the table to innovate in this area.

Tools like Creo from CreoLabs demonstrate a whole new paradigm of thinking about this problem and Xojo stands to learn a thing or two from similar products. There are countless developers who do not want to deal with Java, Objective-C or Swift and there is a real opportunity here for Xojo to succeed. Combined with a fully functional new framework that is actually cross-target and usable across all user interfaces without numerous data type conversions; Xojo would nearly double my productivity.

Conclusion

I could write an exhaustive list of things I want to see improved upon in Xojo in 2018 but each year brings us only a handful of new capabilities so one must be realistic. In 2017 Xojo kept up an aggressive pace of bug fixes and quality of life improvements in the IDE and standard libraries (old and new).

The much-rumored Windows flicker problem should be resolved or greatly improved soon and that will be a substantial release in its own right. We must also take the time to appreciate the first ever 64-bit release of the IDE and the realization that Xojo has come full circle as a modern software development platform. This should also give us pause however that the fundamental technical hurdles have been overcome and we are staring at the platform as it will be for the near future.

More optimizations will be found and talks of possible IDE tweaks or improvements were discussed at the last XDC demonstrating continued improvement. That aside the 64-bit future is here, the mobile platforms are realized or past conceptual stage, we can build for all three major platforms and operate on the Raspberry Pi. It is time for Xojo to double down on the rapid application development platform that it promises to be.

Lastly, I would be remiss if I did not mention my greatest wish at Xojo, Inc: The opening of the beta tester program and more transparency into the development lifecycle of the product.

The need for absolute secrecy hurts the product in my opinion. The desire to not have to apologize when milestones are not met is purely selfish and does not take into consideration the ideas and passions of the larger community. I am also disappointed when thoughtful ideas and tough love criticisms can so easily be discarded, or discussion topics censored and deleted for fear of acknowledging that the product is not perfect.

Most acknowledge that no software development environment can ever be perfect. I resent the desire that some have to refrain from mentioning areas where it is not meeting its maximum potential. I feel dishonest if I do not share with customers the pitfalls of using it and I am delighted when I can say “Xojo is a perfect fit for this.” I look forward to being able to say that more often in the future.

Best wishes to you all in 2018.

Xojo Web Framework 2.0?

I am stoked about XDC and many of the presentations that are on the agenda. I’ll write about that more later but there is one that stands out to me:

Web Framework 2.0 | Greg O’Lone, Xojo Inc.

The Web Edition of Xojo (then REAL Studio) was released in Fall 2010. Since that time very little has changed. I cannot think of any additional widgets from the original feature set but perhaps there is a handful.

It was in some ways ahead of its time and in others behind it.

For example, there still is not really a competing product or environment that can produce web applications as quickly as Xojo Web. Single page applications were not very common in 2010 and certainly there were very few frameworks for building them. Angular released around the same time in October 2010. Both React from Facebook and Vue were released in early 2014. Even with those frameworks the time to develop in them is significantly longer than using Xojo Web.

This has a great deal to do with the way Xojo Web mimicks desktop applications. This makes the underlying business logic portable while still maintaining some of the same user interface elements. If you need to build a small utility or application you would be hard pressed to beat the speed of development of Xojo Web. I can have an application running in my browser that performs some action all via client side javascript in a single page application in approximately 2 minutes. Its takes longer than that to download, update, and start a React project. Never mind connect a web backend via JSON calls, return a response, present response, etc.

The product has aged gracefully and even kept pace with modern environments despite being relatively untouched over its seven-year lifecycle. There have been slight improvements here and there but it is largely the same product as when it was released.

Identifying the top weaknesses for Xojo Web currently:

  1. No responsive design capabilities which makes building for different devices painful.
  2. Outdated and not very secure embedded web server:

    The built-in web server is HTTP 1.0 compliant only and has some considerable security and performance implications. For example, it is very easy to perform a denial of service attack on standalone Xojo web apps.

    Most of these issues are mitigated by sitting behind a load balancer or running in CGI mode like we do at ServerWarp. Xojo Cloud operates their apps in CGI mode so you are good there as well. However, those of you running standalone on your own servers need to be mindful in this area.
  3. Lack of new and updated widgets for modern web usage.
  4. Overly complex and difficult to import javascript widgets from other frameworks or toolsets.
  5. Building web services to interface with other desktop and iOS applications built in Xojo is way more work than it should be for a RAD platform. See my product Rapid Services for a way to improve this and build web services as fast as you can web applications with Xojo Web.
  6. Web styles leave a lot to desire in terms of skinning and maximizing web application aesthetics.

I have a vested interest in the Xojo Web product as we operate the largest Xojo web hosting platform not owned by Xojo, Inc. I have launched and operated hundreds of these applications in standalone, CGI, and load balanced modes. I have seen and worked with many of these customers to help them get the most out of their applications.

My biggest fear with Xojo Web 2.0 is that the desire to “build something new” could hurt the product. If Xojo completely switches to a responsive design then it will be nearly impossible to support the existing web applications which are based on fixed locations on the HTML page.

It would be cruel and difficult for customers if you said starting next release you can no longer work on your existing Xojo Web project as the new web framework is fundamentally incompatible. You could support Xojo Web v1 projects but then you end up with essentially another target. How much support and updates do they provide to Xojo Web v1 or is it considered legacy and only maintained such as the classic vs new framework debate.

The term responsive design was not coined until May 2010 and while the idea existed via other terms like fluid, elastic, etc. it was not widely deployed. I do not fault Xojo for not supporting the paradigm. According to Wikipedia; Mashable labeled 2013 the year of responsive design. It has been pervasive ever since.

Consider for a moment how responsive design would actually work in the context of the IDE. The fact that you design your web application in a similar manner to desktop apps is a nuanced, sometimes awkward, but surprisingly consistent experience. I cannot fathom a responsive design framework that would work reliably in the IDE.

When you are “drawing” your web application in the IDE you are not manipulating HTML/javascript in real time. You are just laying out controls in the manner in which you want them to appear in the browser. This is really what gives Xojo Web its strength as a truly rapid web application development tool. You do not interface with HTML or Javascript at all unless needed and rarely at that.

A responsive design using CSS/javascript can fundamentally alter your web view based on screen size and orientation. I struggle with how the IDE can present widgets that are presented entirely differently depending on the size of the screen. How would you ever map that correctly to the controls from the library.

I am also concerned we may get some version of the auto layout tools used for iOS. Those are terribly unintuitive and challenging to produce the correct results without much reading, manipulation, trial and error. I personally would find that extremely frustrating if used on the Web.

Between the IDE challenges, project backwards compatibility concerns, and general risks involved with a new target or framework I take pause with a “brand new framework”. I think Xojo should be focused more on finishing the new frameworks they have already started. I understand for purposes of marketing that having fancy new features and targets is advantageous. I would just like to see a new control for every supported platform each release. If that cadence had been maintained Xojo Web would not need a new framework today.

Let us assume that Xojo was not working on a new web architecture. I have a list of things I would like to see improved in what we have today. If done correctly I think Xojo Web would be future proof in the short term and allow them to focus on iOS, Android, Windows flicker, etc.

  1. Instead of breaking your current paradigm of fixed location widgets in favor of responsive design; How about presenting three views similar to how you do it with iOS.

    A smart phone view, tablet view, and desktop view. You would drag widgets to each applicable view depending on whether they should appear and how they would appear. They would share a name across all views so your backend code is not concerned with the size.

    When necessary you could still use the Session.Platform identifier to handle specific circumstances. The infrastructure is already there we just need some design time IDE enhancements to optimize for the varied screen sizes.
  2. Update the embedded web server to support HTTP 1.1 and 2.0. Let’s also add in request timers, content length verifications, and pre-request body header analysis to prevent and stop various attacks or bad requests.
  3. Add some user controls. Date picker would be a good start. I have never seen a RAD tool sold without a date picker before.
  4. The Web SDK via WebControlWrapper is not actually that bad but the learning curve is pretty high. I would like to see some work on making that easier or supporting some of the larger toolkits out of the box.
  5. See Rapid Services for a better way to implement web services creation and consuming.
  6. Styling and theming Xojo Web apps needs a major overhaul. I have built an entire theming library for Xojo Web for some of our applications and I plan to release soon. GraffitiWeb and others are great but for widgets but making your application look good is still too hard.

I am curious how many of you share my priority list and concerns regarding a new Xojo Web? What are you looking for in the next version or to be improved upon in the current?

The “New” Xojo Framework is a Dud

The people have spoken and the new framework is a dud. Outside of iOS development the new framework is only used sparingly when you have no other choice. There are numerous actors speaking up about this on both the forums and via their personal blogs. Recently Bob Keeney of BKeeney Software addressed some pain points of the new Xojo.Core.Date class on his blog. Xojo CEO Geoff Perlman makes an effort of defending the choices around the new Xojo framework but frankly nobody is buying it and Bob Keeney illustrates this perfectly in the comments.

Xojo.Core.Date is certainly flawed and it is not out of desire for code purity or technical merit. It is flawed because it was designed by an engineer to be consumed by engineers. However, Xojo is a product which was designed for prosumers and small valiant teams of software developers aiming to be more productive.

It shares a lineage with Visual Basic in getting out of your way and making your computer as a tool more accessible. The fact that it is so capable and can be used by computer scientists and engineers to build beautiful software products is a virtue few similar products share. It has for a long time walked a tight line between exposing or abstracting too much of the underlying system. It is rewarded for that effort by a very strong and passionate community and continued operations outlasting most other tools of its category.

Sway too far on the side of pure technical merit and code verbosity and you find yourself in a situation where hobbyists, prosumers, and long-time customers no longer recognize the product. Alternatively, if you abstract away all the details, fail to offer plugin SDK’s for all targets, and move away from Declares to an unknown “Interops” system you risk losing the professional users and barely-hanging-on third party ecosystem.

I keep repeating this idea in my posts that I do not understand why all the mystery that surrounds the Xojo product and its ongoing development. Why all the subterfuge about priorities and goals. Xojo will say “We want to support as many targets as reasonable.” Cool. We accept that. “We will support Android sometime in 2017.” We have no screenshots, no class hierarchy, no design goals, nothing to base any kind of opinion on what that product will look like. It is difficult to get excited or plan for the future when many attributes of Xojo iOS left us wanting more.

I know many who have attempted to build iOS apps in Xojo and decided it would be more profitable to learn Swift. Especially so when they were going to have to start over with a new standard library anyway. I am scared to think about what the Android platform might look like. Will it have the new framework? Or some unique variant of it with its own caveats and controls?

We seem to be moving towards a direction where Xojo is a cross platform IDE and compiler toolchain first and language second. All concerns about how the user actually writes their code and what that experience feels like and how productive they can be is secondary to shoving it into the IDE and calling it done. Maybe it was always that way but the framework shines a light on the self-imposed challenge they face.

Customers will put up with long term LLVM changes and delays. They will put up with an IDE that they prefer less than the previous version and a vague commitment to “fix it” in the future. They do fear it might actually get worse instead of better when the design process is completely secret. They can even deal with years of backlogged bug requests which are tagged as “Needs Review” or “Verified” with no fix in sight as they can often ‘Declare’ and work around it.

What concerns me is they may not put up with an entirely new language they do not even recognize. It is annoying to have to re-train for the new framework depending on what version of the IDE you are using and what platform you are targeting. Moving between projects is painful when I have to keep notes on which versions of Xojo has certain features working or broken. Feedback item #46943 with an essential performance issue on a CORE datatype to the language remains unfixed or even verified after a large release, a point release, and a beta release. How are bugs prioritized? Language data types functioning correctly would be #1 for me as without it you do not have a language.

If Xojo does not care that basic features such as data types are not working properly on all platforms then it gives us ZERO confidence in the new framework. As customers do decide to embrace the new framework, they discover features that are broken or missing on one platform or another. It is simply not tested very well and not used internally and only exists for the sake of iOS.

Somebody needs to take responsibility for the language and trash the new framework or commit to it. Especially considering there is no reason why you could not simply replace the Classic underlying implementations with the newer ones to give us the modern features with our existing code bases.

HTTPSocket could be an alias for HTTPSecureSocket which could essentially just be the new Xojo.Net.HTTPSocket behind the scenes. That is called abstraction and that is what customers pay Xojo for: A unified development environment and standard library across ALL platforms.

As it stands this is how many new programmers get introduced to HTTP sockets on the forums:

-----

New Customer: Hi! I like Xojo and I’d like to query a web service and get some results. I tried using the HTTPSocket but it is not working.

Old Customer: Hey great to have you. Well you should use HTTPSecureSocket because it supports SSL and most web services require SSL these days.

New Customer: Oh great I had no idea that even existed. Why the distinction? Isn’t SSL ubiquitous?

Old Customer: Yeah Xojo did not change HTTPSocket in the off chance that a customer desires HTTP capabilities without SSL functionality. We have not found that customer yet but alas we are still looking…

New Customer: Okay thanks. I tried it but it does not work. Something about authentication error. The web service says it uses digest authentication because basic authentication is less secure. I tried to use the ‘AuthenticationRequired’ event but no go. Tech support said I also need to use HTTP 1.1.

Old Customer: Ah yeah so for that you want to use the new Xojo.Net.HTTPSocket class (there is no Xojo.Net.HTTPSecureSocket) because it supports digest authentication, SSL and HTTP 1.1.

New Customer: Ah wow makes sense. Okay so I have a problem and that is I can’t seem to get my data back. Where does the response string get returned?

Old Customer: The new class is asynchronous which means you need to entirely change your thinking and handle the PageReceived event. Best ways to do that is drag an instance of Xojo.Net.HTTPSocket to your window (actually drag an object and rename the super because the new classes are not in the library…) OR subclass Xojo.Net.HTTPSocket

New Customer: Wow ok thanks.

-----

The IDE outside of iOS makes no effort to promote the new framework. You would not even know it existed unless you were working around an issue and someone suggests a new framework class. If you are not working around the classic framework then you are actively discouraged from using it at all. Many users on the forum repeatedly say to avoid the new framework and even Xojo engineers remind us that Classic is not going away anytime soon so no need to invest in it today.

May I ask what is the point? Why does Geoff and company work so hard to convince us that the new framework is technically better and that we will “get used to it”? They make no effort to commit to it or even verify it is working correctly on all targets. What is the endgame?

If you are going to commit to it then lets formally deprecate or remove the Classic framework and force users to move forward or stay behind. It is a simple choice and the upcoming capabilities of the platform should sell itself. To make that process of converting easier add in some helper methods and properties that make the new framework feel like the old one.

For example you could add a TotalSeconds property to Xojo.Core.Date and abstract away the details of the Xojo.Core.DateInterval class to better support existing code. You could have a SQLDateTime() method on Xojo.Core.Date so we don’t have to run to the documentation to figure out how to get a Date into a Database.

You might be right that it can be done with extension methods but if all your customers are using those methods now then why not just add in a Classic extensions module to every new project (or provide a checkbox when starting a new project – “Support Classic API?”). It then automatically adds in some Classic API support to the new framework via extension module to make converting easier.

Or if you are not going to commit to the new framework and make it easier to use then please call it a dud and get rid of it. Many customers rely on Xojo to abstract away the details. They do not want to be introduced to three different ways to initiate an HTTP socket with various pros and cons. Especially when in that case the old sockets are simply obsolete and should not be used.

Behind the scenes you can make the Classic classes use the new framework equivalents. To the end user the API never changed and the value of the platform continues to improve as you evolve the standard library. Now that is a subscription worth paying for.

However, if you decide that the computer scientist and code aficionado is your target market then be prepared for the new framework to die a slow death and Xojo’s future with it.

Introducing the new framework was Xojo’s very own Windows 8 moment. Now it’s time to bring it all together in a way that reinforces the Xojo value proposition:

One development environment. One language. One standard library. Many targets.