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.

Should Xojo support Javascript/Typescript?

Interesting conversation going at the Xojo forums about whether the product would benefit from a more popular syntax. Polling data shows us that developers do not care for the stigma of basic-like syntax. VB.NET is especially afflicted by this mentality despite sharing the the entire .NET framework and all of its capabilities with C#.

In my experience the Xojo community are avid supporters of static type checking. Non-IDE assisted properties/methods via 'Operator_Lookup()' or dynamism tends to be frowned upon. I occasionally receive emails asking for help with SQLdeLite or comparing it to ActiveRecord. Xojo developers get spoiled by the IDE’s auto-completion that they lack a certain confidence when it is not there.

Thus I think Javascript would not be an optimal fit for Xojo.

However that is not to say that we cannot add some borrowed language features to make Xojo more appealing to basic-naysayers. I would like to see semicolons and brackets added as purely optional syntactic sugar.

Imagine:

    For count As Integer = 0 To myArray.Ubound
        myListbox.AddRow(myArray(count))
    Next

Could Be:

    For (count As Integer = 0 To myArray.Ubound)
    {
        myListbox.AddRow(myArray(count));
    }

We could make also Dim seem a little less 1980’s as well.

Imagine:

    Dim count As Integer = 0

Could Be:

    Integer count = 0;

A little massaging of the syntax while being purely optional would make Xojo more palatable for the large Javascript/C family of developers. I am not or have been a Xojo compiler engineer but I can only deduce that these changes would be easier than building a Javascript front-end.

If you like random Xojo ideas, suggestions, and tips like these then please subscribe to our newsletter.

Xojo in 2017: A Review [Part 5: When To Use It]

This is the fifth and final part of a multi-part review series on the Xojo programming language, environment, framework, add-ons, community, and more.

The first part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part1

The second part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part2

The third part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part3

The fourth part can be found here: http://www.dev.1701software.com/blog/xojo-in-2017-part4

-----

Xojo is a significant product.  Targeting Windows, macOS, various Linux distributions, iOS, and Raspberry Pi from one language is an undertaking.  Xojo also sells a web product compatible with modern Internet browsers.

The goal here is to allow you to focus on your application versus the wide variety of platform differences. In my experience Xojo is one of the best options when considering a cross platform solution.

However, there are disadvantages to Xojo and you should know when not to use it:

• When maximum performance is required. Xojo console applications can be quite fast but desktop applications do suffer from a large framework. Application safety features can be disabled and compiler optimizations toggled to speed it up but you are certainly never going to beat bare metal.
• When maximum concurrency is required. Xojo applications can only use one CPU core at a time. There are numerous reasons for this and it is not likely to change. I demonstrate in earlier parts why the story around accessory applications to utilize more cores needs serious revisiting.
• When you are using platform specific features. Xojo’s promised “interop” capabilities should deliver better availability of platform specific features. However even then out of the box Xojo has few platform specific features. The ones they do have tend to be bare bones and not widely updated or enhanced. Xojo delivers a lowest common denominator approach. You can overcome this with extensive work.
• When you are deploying to a single platform. The lack of platform specific features makes this a sub-optimal approach. Programmers tend to be optimistic and believe that deploying to a new platform is “coming soon” so you should prepare now. If you know that you will be on a single platform for 12+ months you should focus on using the tools for that platform.

There are some great advantages to Xojo and here are some cases where you should use it:

• When you are building a line of business application. These days company staffers are using all kinds of devices. You do not want to prevent someone from working because a company utility does not run on their platform.
• When you need to build a quick and dirty prototype. Xojo is really fantastic at building working mockups that evolve easily with your ideas. Mockups and design concepts are helpful but a functional prototype helps users conceptualize their needs and delivers better results.
• When you do not have time to rewrite your prototype in a “real language”. Xojo provides full object-oriented capabilities such as classes and interfaces to allow you to build complex software. There is nothing stopping you from turning your prototype in a high-quality application.
• When you are concerned about your software documentation and architecture. Xojo with its IDE keeps every project organized in very similar ways. Excellent built in search and navigation of the code hierarchy allows for great code discovery. Its basic syntax is easily read and understand. Xojo programs are not difficult to share with others.
• When you want to share code between target platforms. Xojo through the use of modules and platform conditionals makes it very easy to share the same platform-independent logic across all targets. It is really great to write some REST API code or PDF code and have it work on all targets with little to no additional effort.
• When you want a central location for documentation, community and support. Xojo’s commercial nature is a strength for many customers. They prefer the official documentation and support channels that Xojo provides. While I advocate for the open sourcing of a subset of Xojo’s functionality I do believe in Xojo as a commercial entity and product.
• When time is of the essence. I do not think there is a faster or easier way to compile a working desktop application for this many targets anywhere. It may certainly be doable by Java and others but it is nowhere near as efficient or fun.

I personally enjoy using Xojo for every project where appropriate but it is not always the best tool for the job. I hope this series has given you some indications as to where I think Xojo is, where it could go, and why you should consider it. 

If you were discouraged about Xojo I hope this series demonstrated that a lot of people rely on it daily and it is a good product. If you are encouraged about Xojo and concerned there may be lurking problems well I hope I have presented the most challenging ones to overcome.  If the tradeoffs sound agreeable to you then you should consider it for your next project.

I will continue writing here my experiences and feelings about Xojo. This however is the end of my 2017 review series. I have some big open source and commercial add-ons being released soon so I want to focus on writing great documentation and example projects for them.

Once we get into 2018 it will be XDC time and I am very excited to meet more of the this community in Denver. Thanks for tuning in and don’t forget to sign up for our mailing list.

Thanks for reading.

Phillip Zedalis