I’m required to use specific tools from time to time because the customer specifies them in my professional life. There may also be guidelines that dictate how to name your variables, functions, and classes and how you need to document them with some companies. Sometimes you just don’t have the freedom to choose your favourite tool or platform. But as much as I like macOS over Windows, I pretty much love returning to Xojo when I had to use a different toolset. Why use Xojo? You can only answer this question individually, and I can only share my experience.
Many tools have their justification and their pros and cons. It is by definition impossible that an “all-rounder” can do everything and that just as well, quickly, stably, and future-proof as a specialized tool.
That is not only the case with programming but also with everyday household items. Let’s take a washer-dryer combination. To the best of my knowledge, the dryer unit still has limitations (for instance, less laundry weight possible) than two separate units. A stove with an integrated microwave and a steamer has advantages (all-in-one) but limitations to two or three individual devices (the most obvious difference: you can not effectively use the functions simultaneously for multiple dishes).
Programming is no different. Specialized tools and programming languages often focus on a few tasks (one operating system, one platform, or a particular output type). They excel on that job wonderfully, but only in this one specific area (or a very few). Consequently, this often means that you need a large number of tools and frameworks if you want to target multiple platforms. Xojo is sometimes a compromise, but that’s, in my opinion, the nature of the beast.
There have always been manufacturers and development tools that try to serve multiple platforms. Google tries that with “Flutter” and this is quite successfully. With the latest version of Flutter, you can develop for Mac, iOS, Android, the Web, and (beta for Windows). It’s an excellent concept, but there are limitations here too. The most obvious one, but one that is usually not immediately apparent, Flutter is essentially designed for the front end and not the back end.
With Flutter’s programming language (“dart”), you can quickly get around here by building a “bridge” between the front and back end (e.g., an SQL database).
But of course, you should do this via REST-APIs (no direct SQL queries). That means that you build your own REST-API first (which does the SQL queries), and then you can access it from Flutter via JSON exchange. You can create that backend component with Dart (the underlying programming language of “Flutter”) or something else like python, PHP, node.js, etc. but, compared to Xojo, it is quite an overhead. Consequently, you will need to deal again with several tools, all of which you have to learn, understand, and practice. I like that I can achieve all of this with Xojo in one IDE.
At some point, you will also notice that Flutter is fast and straightforward but that the framework, like all frameworks, imposes a corset on you. You can program across platforms, but you don’t have all the design options you would have if you develop directly for iOS or Android (via Swift, Kotlin, etc.). Plus, you will need to tweak your code as well to work perfectly fine on all platforms.
What still fascinates me about Xojo? Xojo certainly has limitations. Still, essentially I can do many tasks with one tool, whether Console, Windows Services, Office Automation, Windows, macOS, Linux, iOS, Raspberry, or Web. I can perform all of these tasks, usually with the same procedure (e.g., direct SQL statements on a database without building an overheard backend on top of my databases).
The API2 changes, beaten up by many, are annoying for a long-time developer, but I understand that they are essential to standardize the different output formats further. Overall, the API2 (for new projects) is also a real blessing for the most part. Already today, I can use large portions of my code unchanged for several platforms, but in any case, at least the approach is the same or similar. In my opinion, an important “feature”.
What bothers me about Xojo and where I think they are doing themselves no favour in the market is the modest number of “controls” out-of-the-box. The fact that there was no reasonable date control for years is challenging to understand, and a way to change the look of a “Listbox header” was missing for years. Fortunately, there are external plugins, but I would see their use in extending functions rather than enabling the essential functions or even fixing bugs. It is still complaining at a high level because I have always found a way to circumvent the problems, but most often at additional costs (plugins and my time).
The other thing which often puzzles me is the speed of releases. New features, especially bug fixing, usually take a very long and frequently add new bugs or challenges.
On the other hand, I don’t want to test a new release every week as a tester. Perhaps it would be a solution to limit the “point releases” to one or a few functions. E.g., a point release will only target to fix the current JSON memory leak, another one, the WebFileUploader and so on. Message to the testers: “Please test this up and down now; nothing (!) else has changed in this release!”. But who am I that, in ignorance of the internals at Xojo, I should be able to judge whether something like this is even feasible and makes sense?
Overall, Xojo enables me to implement quick, maintainable, and scalable solutions for my customers with little effort. I don’t know of any other development tool that covers so many areas, especially without building a complicated backend. In my opinion, only Java can map this very well and stably. However, the costs are similarly high with external tools. And with Java, I am also dealing with a platform that looks the same or similar to desktop applications but works entirely differently, so many users are usually highly irritated. That’s not blaming Java. It is a good solution in many cases, but a completely different concept. I find it challenging and unreasonable to compare it to Xojo.
Last but not least: It is probably the highest compliment for a manufacturer when disappointed users have (temporarily) turned away but still spend every free minute commenting on Xojo Forums. Many are still discussing details and workarounds or even trying to develop a better Xojo themselves. Please don’t get it wrong, I like the Olympic spirit, and I admire the commitment to such a task. In addition, it is amazing how far some developments have come. Exciting times are ahead of us. I’m not saying that building your own Xojo is something to avoid, but I doubt that it will be magically free of bugs or will cover all the functionality of Xojo anytime soon. What Xojo has implemented so far is more than impressive, and it does the job for me (though with many workarounds sometimes). I don’t see any competitor on the horizon yet, being close to achieving as much as I can build with Xojo today. As I want to be productive, I prefer developing to searching for another tool. You are probably not one of the most productive developers anyways if you are seeking all the time for the next best toolset. Love it, change it or leave it! I like Xojo, and I change it where it doesn’t work the way I want. That’s another advantage of Xojo: the possibility to add missing functionality, where needed.
Long loading times in the IDE are my biggest challenge, as it is the consequence of such add-ons. The initial loading time when using many plugins and add-ons is not competitive, period. That was never up-to-date and is undoubtedly no longer state of the art. Better integration of GIT is another topic on my wishlist, but other than that, I have to say that I’m still delighted and very productive with Xojo.
Update: May 26th 2022:
I still believe in the idea of Xojo. But especially for large or more complex web applications, please consider the following article: