What happened to xojodocs.com?
Table of contents
No headings in the article.
I’ve been pretty quiet in the Xojo community for the last 6 months, and that’s not going to change for the foreseeable future, as I have projects that other tools are better suited for. I have received several inquiries as to whether I am now against Xojo and I can wholeheartedly deny that.
Since I use Xojo (after all, since 2005) there are always voices in the forums that predict the end of Xojo, or that certain functionalities are not satisfied or missing. Of course, there are good reasons for some friendly moaning, as several bugs have existed for years, I could never make friends with the feedback app, the loading of many plugins takes quite a long time and the management and update of plugins is time-consuming, but overall you can create prototypes for all kinds of platforms very quickly with Xojo, I still do not know any other tool that implements this range of functions so easily, even for laymen.
For me, this is also explicitly true for Xojo Web. The ability to have a visual editor makes it extremely easy to prototype quickly. The fact that the compiled code comes with its lightweight web server makes it extremely easy to publish your application. And special tools like Lifeboat help with the roll-out.
If all this is still too complicated for you, you can use Xojo Cloud and roll out your application with a few mouse clicks. The third option is to build your web server, which again is not rocket science:
In my opinion, no other tool makes this so easy, which is why I continue to use Xojo Web to quickly visualise initial ideas for customers. But simplicity always means making compromises.
That’s just my business case, I’ve only ever used Xojo for internal tools and for applications for non-profit organisations that have little money and where functionality coupled with the lowest possible development and production costs are paramount. Here we are also talking about only a few users per app, so scaling and load balancing is not an issue. However, these customers also don’t have a budget to regularly update applications, which means that I can’t always use the latest version of Xojo, or would have to absorb the costs for such an update myself, which of course makes little sense. This is my biggest criticism, new versions can break existing code, and it is the rule rather than the exception. Of course, this applies to other tools as well, but it just remains a disturbing fact (for me).
Xojodocs.com, a web application, I mainly used internally to test new releases is one such example. Updates ended up being time-consuming in that I didn’t add any new functionality, I just adapted the code for new releases to test what a new release is breaking. But the reason why I discontinued the application is another one: Xojo finally provided a new documentation system (https://documentation.xojo.com/ versus http://docs.xojo.com), and with that, I would have to completely rebuild the parser to read the former wiki, I just don’t have the time at the moment and it wouldn’t pay my bills either. To be fair, though, Xojo already alerted me when I first released that web app (over a year ago) that they were working on a new version of the documentation. So I’m not upset or disappointed, it was clear (to me) from the beginning that it would come to the point that the application would no longer make sense at some point. All good.
If you work with alternatives (in my case currently node.js and TypeScript) then, of course, you have more design options, because you can define for example the layouts with pixel precision, but you also have to be aware that this has its price tag. Not only do you have to master node.js, TypeScript, and CSS (or other alternatives and frameworks), but you also have to delve much deeper into how to get your application rolled out. While this isn’t rocket science, it’s not as easy as clicking a few buttons in Xojo, more or less.
So for me, it’s only logical and part of the concept that Xojo Web (like Xojo in general) always means a compromise. However, it’s a tool that’s incredibly effective for prototyping small programs and tools and still, some will disagree, as they build some great apps, which actually pay their bills.
What’s annoying is that new Xojo releases could always mean a regression, but you see that in many (aka all) tools. My biggest gripe is localisation challenges. Whether it’s managing currencies or manipulating dates, this is where you regularly get stuck. Plugins help here in the backend, but only to a limited extent in the frontend.
Frontend and backend are the last points that should not go unmentioned. With most common alternatives, you have to take care of the separation between the front and back end in web development yourself. That alone should be a challenge for many developers. Even if such a strict separation has many advantages, especially in terms of performance, it is another technical hurdle. With Xojo Web you don’t have to worry about that. The compiled version includes everything you need to get your app up and running quickly.
So I still like Xojo Web, and knowing other tools, it’s very impressive what has been achieved with Xojo Web 2. However, in my opinion, you also have to know that there are natural limits to complex projects, especially those that require pixel-perfect design or high performance. To a certain extent, they can be managed with workarounds, but you may have to decide for yourself whether another toolset is better. Personally, though, I still love the option of not making that decision until I have a paying customer who can decide on a solution through quick prototypes. Here Xojo Web is still unbeatable, at least for my business.
Last but not least, no matter which tool you work with, it is much more important to work productively than to invest too much time looking for the jack of all trades, which doesn’t exist, and most likely will never be available in IT.