This is the second 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 truth is you cannot easily make a distinction between Xojo the language from its framework or “standard library” in typical programming language speak. This is because of how Xojo is produced as a commercial product. In most programming languages (especially recent open source ones) the syntax and rules that govern it is distinct from the built-in functionality that the language possesses. Beyond those capabilities is a packaging system or an import mechanism that allows you to draw on additional libraries to complete your desired objective.
In some languages like Swift the standard library is small in scope as most fundamental functionality is already found in the Apple/Next foundation libraries. The cross-platform objectives of Swift are being enabled by duplicating the said Objective-C/Darwin frameworks to other platforms such as Linux. This allows Swift code to more easily be ported from one platform to another. Google Go (or Golang) is the opposite and provides a very extensive standard library capable of powering web servers, performing compression and cryptography for example. A great deal of network code built in Go is ready to be compiled on any supported platform due to the standard library being so robust.
Xojo is like Go except without the benefits of an open source standard library. If you want to build a web server you have no choice but to use the built in TCPSocket and ServerSocket implementation provided in Xojo’s standard library (or framework as they call it). Xojo has no packaging system or central repository of plugins or third party libraries. While the Xojo standard library is quite large it varies based on the platform you intend to use it on. This can make coding difficult because you have an expectation of a method or class being available or working identically on all support platforms but this is often not the case.
More damaging to the process of writing code in Xojo is that the standard library is not the only nuanced aspect of the platform. Core data types that should be iron clad and completely reliable on every supported target can vary wildly in their implementation and support. Feedback item #46943 as of this date is ranked 880th and “Needs Review” despite ample evidence that the new ‘Text’ data type simply does not function on Linux as advertised. For those of you new to Xojo and not aware of what Feedback is we will discuss the pros and cons of this tool in a later review part. You should know that the Xojo community is likely unaware of this bug because if they were it certainly would not rank 879 other bugs to be more important. Without reliable data types the rest of the platform is also unreliable because you cannot predict outcomes of standard type operations.
[ For those of you unable or unwilling to use Xojo Feedback to review case #46943 it demonstrates in a reproducible fashion that the ‘Text’ data type is magnitudes slower on Linux. Specifically using the ‘Text.Characters’ iterator is extremely slow compared to any other target. Fortunately there are other ways to iterate through the contents of a ‘Text’ variable but they certainly are not pretty and basic unit tests should have identified this issue or shown a disparity. ]
If you are not using the new ‘Text’ type on the platform affected then you are unlikely to use caution when using it. You only find yourself in this situation after spending weeks developing your application and then deploying it to the platform to discover it is not running as expected. Oh no!
Now you will tell me “Phillip it’s okay nobody uses the ‘Text’ type yet except for iOS” and you might be right. Except that I do for all my projects because I want to use the new framework so I can write cross-platform code. If I cannot share business logic between my desktop app and my iPad app then the tool has failed at its primary objective. Suddenly we must maintain different business logic code bases because iPad can only accept the ‘Text’ type and Linux cannot use the ‘Text’ type reliably.
Even worse these nuances can vary from one Xojo version to the next. Often with customer consulting projects I am forced to use one release of Xojo for one project and a newer release for another. In a larger project of mine with multiple executables (multiple Xojo projects unfortunately as mentioned in part 1 of my series) must use different Xojo versions for the same ultimate deliverable! Absurd.
There’s two reasons for this: One is old history now and cannot be changed and all we can hope for is Xojo takes my thoughts to heart and reconsiders their strategy for the second reason.
The first reason takes us back to iOS on Xojo. iOS is such a different beast from the rest of their targets requiring IDE enhancements and substantial reworking of many of their classes. Specifically, on iOS few of the core operating system libraries are synchronous in nature so many of the Xojo classes needed to be redesigned to accept this new paradigm. They could have taken the easy route and bolted on overloaded methods and new events to existing classes but Xojo engineers decided that asynchronous operation was the future. Rightfully too as we see languages like Javascript with Node.js, Google Go, and Erlang take off in popularity. However instead of just designing new classes that would either be iOS only or slowly reach all the targets as the “new framework”, they re-designed the entire language.
While the syntax looks familiar every class was touched, name spaced, and even core data types altered. Friendly favorites such as the ‘Variant’ object ceded to the ‘Auto’ type which means “I could be anything including a runtime error that I wasn’t what you wanted when you wanted it.” The new ‘MemoryBlock’ type has countless forum posts asking, “How do I use this thing” and “how do I get Text in and out of a MemoryBlock”. If that weren’t enough it turns out the new data types don’t even work (as addressed above) and aren’t being fully tested in every Xojo release.
Finally, what really will upset you about the new framework is how awfully long it has taken Xojo to implement the classes necessary to utilize it on all platforms. With iOS receiving extremely slow updates to its limited standard library there is little incentive for Xojo to push the new framework when its widely avoided by the community for being cumbersome to use, broken, and/or not available when needed.
This leads me to my second conclusion about why I am often forced to use multiple Xojo versions for any given project. The reality is the IDE only gets better with each release. It gets faster, adds new features, themes, documentation, etc. I want to use the new IDE when it ships and I want to continue supporting the company because I believe the IDE represents how programming should be presented. I absolutely hate having to compile piles of C++ code and switching compiler flags and getting my build environment together. On macOS that could mean screwing around with Homebrew to acquire the Linux-esque packages needed to compile a library or executable. On Linux that means gathering the bits to the compiler toolchain which vary from distribution to distribution. On Windows you have to struggle with Visual Studio project versions and now with Windows 8 & 10 multiple SDK versions that are changing rapidly.
I do love working with Xojo daily. I want to fire up my IDE, write some code, hit compile and have executables that work. Xojo is the closest thing to the perfect environment I have found for all the types of devices in my life and in those of my customers.
Truthfully, I absolutely hate that core data types can be broken in obvious and unbelievable ways. I hate regressions and how Release .1 and .2 are often re-fixing things that were fixed in a previous release. Most of all I hate how the standard library can fail on you entirely in unpredictable ways from one release to the next. You often find yourself in a situation where you are debating the pros and cons of two releases and which is the path of least resistance. Which version will cause the least amount of pain hoping and praying that the next Xojo release fixes it for you. If you file a feedback there is a good chance it might. It will probably break something else though.
What I am trying to say is the quality control at Xojo is not good. I am also saying that if you are patient and understand the complexity of what they are trying to achieve it can be great. However, what is a lengthy rant if not for at least one suggestion:
Open source the standard library.
Xojo does not need to be 100% proprietary. For one it’s absurd in 2017 to be a programming language who safe guards all of your inner workings. You have plenty of intellectual property in your IDE and compiler toolchains. I would subscribe to your product even if it was an IDE for more common languages because I enjoy the experience. Second most of your classes are just rehashes of operating system provided classes that you have written a wrapper around. If not an operating system library then some other open source library like Crypto++. Xojo writes wrappers for other libraries for a large portion of their standard library yet hypocritically denies their users the ability to write wrappers around their framework in the EULA. Huh?
I am advocating and would continue purchasing and supporting Xojo if the standard library was open source. The community could help fix bugs and extend the platform with classes. Xojo could package the “officially” supported version with the IDE but the source and instructions on how to build for all platforms would be available on say Github. If a new release of Xojo breaks the HTMLViewer for example then we could take the version from the last release and compile it for the new IDE.
In fact, we could even mix and match which versions of the library classes we need for a given project. How about exclude classes we would never need to minimize the size of the framework and our executables? The community could do so much to extend the framework beyond its original scope and breathe new life into every release of Xojo instead of playing two steps forward, one step back.
I will cover the Plugin SDK in another part of this series and some of the most popular plugin vendors in the Xojo community. In short: the Xojo standard library suffers extensively from lowest common denominator and an additional investment in third party plugins is essentially required. Xojo wants to move away from the Plugin SDK and to their new LLVM pre-compiled plugins that they have mentioned but never fully scoped out for the rest of us. While I find that intriguing and useful it should not be a binary choice. I want to see the entire standard library turned into one giant Plugin SDK.
-----
For those of you that will tell me I am being overly critical I apologize but I do not accept your premise. I am writing this from the perspective of someone who uses Xojo daily. It is not my job to advertise for Xojo or help them generate more revenue. They market their product as a tool that does cross platform development with a large and useful standard library. I and most consumers using the product will take them for their word and assume the product works as advertised.
My objective in this series is to communicate the pros and cons as a professional Xojo developer making a living with this tool. I want to communicate to the business owner, future client, and forthcoming developer the challenges that they will face. I also hope to build consensus around logical and attainable solutions that would make the product better for everyone. If I did not love using Xojo then I would not take the time to write all of this down so I hope you find my criticisms useful. I also do not want to spend cycles regurgitating content you can find on Xojo’s developer center or marketing materials. I am reviewing the product as it stands in 2017 and where I see it headed in the future. I am not developing a brochure to market it to you or suggest you should not use it.
The truth is that Xojo necessitates this level of scrutiny by staying 100% proprietary. They so far have not wanted users contributing to the core framework or optimizing the product for their own use cases. They want you to use Xojo exactly as they have designed it to be used and unfortunately the right answer probably lies somewhere in the middle.