Everything’s a tradeoff. The problem is that Xojo isn’t protected from its own stupidity.
During my fairly brief flirtation with Xojo, I thought the “eat your own dogfood” argument had some merit, but not as a reason to never use outside dependencies. I don’t think that was ever the point of the idea. I think customers appreciate Xojo being built in Xojo (mainly because it encourages the language to be more full-featured and in theory at least would mean the tooling would have to be less buggy) but not to the extent that it divorces the product from how the industry at a whole is evolving. It has to hold its own so that it doesn’t tip too far the other way and become some weird island unto itself. And it still has to be responsively maintained, bugs actually fixed, and no major (much less multiple) missteps architecturally. Especially the antipattern of tossing something out for a total rewrite (API2, “Web 2”) AND then abandoning backward compatibility.
I remember rejecting the web target out of hand when I found it used its own server and it couldn’t scale much in terms of connections and there wasn’t any commitment like “we’re working so that you can serve Xojo apps with (say) Apache”. Did no one foresee this? It’s just not how these things are done. Developing into an open standards environment you have to abide by those standards. You’re not going to convince a business to build on and support some tiny company’s proprietary homebrew web server.
Xojo is the equivalent of an evolutional dead end.
But that has to do also with the history. They could have moved to another platform. But possibly not with native UI components. Nobodyy of the Scene wanted that cause native is SOOOO important. So it is really complex to stand the problems behind.
No point in re-litigating native vs non-native controls, but it seems fairly clear to me that either way, one option is to rely on someone else’s framework or platform for the actual rendering. Two that I have seen used are Avalonia and MAUI. When you have that worked out by fairly large companies with a good following then while there’s some risk that 10 years from now they’ll quit supporting it, and certainly within a generation you’ll have to at least go through some major evolution to keep up – still, division of labor is one of the great inventions of humanity, and it shouldn’t automatically be off the table. Nor should the tradeoffs of using 3rd party libs make you think there are no tradeoffs for NOT doing so.
Interesting thought piece on the two major styles of organizational change and two kinds of persons who drive one or the other.
TL;DR: Incremental improvement or “move fast and break things” basically. I’m capable of both in the right context personally, which is probably why I’ve done reasonably well.
I’d suggest that Xojo is stuck in an incrementalist loop and (probably mostly due to top leadership) is basically incapable of breaking out of it. Not that it is ever easy.
I suppose that a lot of political situations involve similar modes of change resistance, come to think of it!
I am not beleaving that there is no need for changes in XoJo. They could have done this with nig changes instead of API2 so they could have changed the needed things in their syntax and language and could have now direct compiling for all platforms and llvm compiling and jvm compatibility and all platforms. Price for it is, sure, really big changes. But they would earn a better platform and more future security. Also they could have from that moment on a wide ecosystem: Kotlin and Java ecosystem. For the price of native UI on Desktop.
THIS was a huge issue
One of the goals was of course full ownership of ALL IP so in the event the company got bought then transfer of IP would be easy
So BSD style licensed code was fine since it was basically “free for any use”
But GPL was a no go
But you can use gpl with classpath exception in commercial projects without any problem. I guess it was the problem that somebody don’t want to show sourcecode