This is the third 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
-----
When I started this series, I did not anticipate the level of feedback that it would encourage. With over 100+ Xojo forum posts discussing the pros and cons of my suggestions I am thankful they have been mostly well received. There have been some negative sentiments and disappointing comments from those who misconstrue my intentions but let me be clear: I love Xojo.
One of the reasons I love Xojo is because I feel software development should be more accessible to the average person. A computer science degree is deservedly respectable in the industry but should not be required for every task. Computing has become so ubiquitous that programming should not be as difficult as it is. Xojo represents a perspective on software development that with easy to use tools one can be equipped to meet the challenges facing them. We at 1701 Software have used Xojo to control custom hardware devices, build mobile and desktop applications, operate a secure file sharing service, monitor / manage virtual machine infrastructure, and much more. Xojo similarly to Java operates on several platforms in both 32-bit and 64-bit variants and allows you to use a time tested and proven language to achieve your goals.
The principal difference between Xojo and Java is how you reach those goals. With Java and others, you have any number of community and commercially supported IDE’s as well as your favorite text editor to develop software projects. The IDE’s in my experience can either be underpowered or completely overwhelming and lack a certain aesthetic finesse that I have come to expect from my macOS environment. Generally speaking you still have to maintain the appropriate version of the Java JDK or framework you wish to use and you may have to do some build configuration steps in order to actually produce libraries and executables to be used on any environment. Sadly, Java actually has the upper hand here whereas compared to C++ and other cross platform tools the build steps, IDE’s, and development resources available are varied and typically challenging to use. Even if you find these tools easy to use there is no question that setting up your build environment and keeping it synchronized with the rest of your team requires time and diligence to construct and maintain.
Xojo simplifies all of that with an IDE that “out of box” is ready to go. Immediately after installation you can start designing an application, writing code for the built-in event handlers and hit “Run”. No other environment even comes close in regard to the “out-of-box” experience. While there are tools like LiveCode and Flash that sort of mimic this behavior, they do not use native controls and rely heavily on their own runtimes and environment. With Xojo you can produce a fully qualified Win32 or macOS Cocoa app in less time than it takes to install Visual Studio. The IDE is to thank for that and trust me when you have mostly completed your project and ready to start testing the IDE helps you there as well.
Of course, you and I both know you should be testing throughout the development process but sometimes it is just not practical to test the code you are actively working on in every environment. You will thank Xojo for their quick installation times and “everything bundled in” approach to software development when it comes time to install the IDE on test devices and virtual machines for debugging purposes. If that was not easy enough you can even use their excellent remote debugger tool to test your code on the other platforms without even leaving your primary development machine. These kinds of ease of use scenarios that take into account the typical development workflow of a cross platform developer gives you a warm and fuzzy feeling that Xojo knows what it takes to deliver.
With easy access to constructing new windows, classes, modules, etc. in your project the IDE hand holds you through the process of organizing your project. The IDE maintains your codebase internally and through visual cues, a tree view navigator, and tabs you can zoom in and out of your project depth as needed. The IDE also allows you to easily share code with others either in an open source approach or a commercial approach using a single file format for your entire project. Nothing is simpler than reporting a bug or sharing a development construct with others than sharing a single file. Naturally this is not optimal for larger teams or those who care about their source code history and so it conveniently supports a source control text based format as well so you can track your changes. Commercial operators will be pleased to know that classes and modules can be encrypted so you can sell them in the open market. A new Xojo plugin methodology that has been announced should further enable third-party development and amplify the number of plugins available in the marketplace.
The Xojo IDE is responsive, attractive, and easy to use even for the software newcomer. For the professional developer, you will find subtle but important features such as object attributes, build steps, and IDE automation enabling you to perform even the most challenging tasks. Where other programming languages require specific tools to handle continuous integration the Xojo IDE can perform these functions “out of box”. (Note to self in the age of Internet downloads is there a more modern saying than “out of box”?) Lower level plugins powered by C++ can be added and removed very easily through the use of a “plugins” folder. The Xojo IDE contains an off-line version of the framework and language documentation for those times when Internet is not available.
My overall point here is that while I suggested that the standard library of Xojo framework be open sourced I only did so because to me the power of Xojo is in the IDE and compilers. I would not pay for the framework with a third-party IDE and I would be happy to swap out the framework if a better one came along. What attracts me to Xojo and what keeps me there is the “instant-on” (there it is!) capabilities of the IDE without having to write a dozen configuration files and map JDK’s and library paths for every machine I use. I use a lot of machines on a daily basis and just thinking about using other tools gives me a headache. I also know that when I present Xojo to newcomers to software development or even the old timers that they are surprised how much can be done with it. Is it right for every job? Of course not. We specialize in .NET for many of our enterprise customers and the occasional Java when some library simply cannot be replaced. When I have a choice and when circumstances allow I always choose Xojo first.
Of course, this would not be a proper part of my review series if I did not point out some areas where the Xojo IDE fails and what I suggest for improving it.
First and foremost, as I outlined in my first part of this series I would like to see multiple project support in the IDE. Even if it never truly supports multiple projects concurrently I would love to see the ability to create console helper apps side by side with the primary app and let the IDE do the work of constructing those executables, passing simple arguments back/forth, and managing the directory layout of the ultimate deliverable. It is simply too much work right now to build a console helper application and connect it to your main executable.
Second it has been noted several times that each platform has subtle but unique differences in the appearance of native controls. Buttons and labels for instance use different heights and text sizes by default. This means that despite spending a great deal of time designing your application it might look rather bad on Linux when you ultimately test it out. You are then stuck spending hours doing “#If TargetLinux” and tweaking each individual control manually on their respective “Open” events and it is tedious. On the right-hand inspector, I would like to see the property window remain as it is with all the control properties. However, I would also like to see 3 tabs for each platform with property “overrides”. From here you could visually say “On Linux make button height 30” without having to write any code to achieve it. If the respective property override is blank or unfilled then it uses the global property.
Third once you do start working on larger projects you very quickly want to share modules with other projects. It becomes quite tedious to do so currently because the IDE does not support external modules with sub-classes. We really need this fixed and I don’t know what kind of effort it will be but I also don’t care. This is a small and subtle bug that you don’t encounter until you have made all kinds of architecture choices around external items only to discover it does not work as you would expect. It is very annoying opening a project on another machine and then having to re-map dozens of external classes when one module would have been appropriate. It would also allow for the correct name spacing of our libraries which is just good architecture in my opinion.
Fourth speaking of plugins and the ability to encrypt code and share it; We need a proper package manager for Xojo. I should be able to shop a “store” or “marketplace” for code and pull down all kinds of classes and utilities directly from the IDE. It should support trials, demos, and allow for purchasing of the commercial variants directly from the IDE. It should also emphasize and support open source work and allow you to right click on a folder and say “Import from GitHub” where it would pull down the latest code from a specific repository inside that project folder. Keeping it synchronized and alerting you when third-party code has changed would be awesome as well. I would love to know when MBS has updated their plugin automatically in my IDE. This is more useful though for open source components where you do not receive a regular newsletter announcing the change. “Oh Kaju has been updated?! Awesome yes please download the updated bits.” I suspect a great deal of this will be possible with the new Xojo plugin format coming down the road and I hope they have something like this in the works.
My fifth and final suggestion for the Xojo IDE is about the upcoming navigator changes they alluded at XDC 2016. Make sure that Alpha/Beta is very long winded and open to almost everyone who wants to try it. Let’s not shoe horn this in at the last minute and screw up our workflow. The navigator may not be ideal but I have gotten used to it and very productive with it and we need to make sure whatever changes are coming are in fact you know… better. This is not about resisting change but making sure the community really backs the direction otherwise they are better off with what they have today. The Xojo navigator changes were quite dramatic and at that time not enough customer feedback was solicited in my opinion.
I still have many parts of this series to complete so fill out the box below to subscribe to updates and news about our Xojo development, components, and resources!