Taking real professional tool hand is worth the amount of work when learning while at the same moment you leArn industrial needed skills.
But thatās not the point, but I agree it might be a nice incentive. I just doubt that most of the Xojo users need skills on an industrial level (aka certifications). Most people just want to get their smaller jobs / hobby done. And that worked quite well at the beginning of RealBasic, especially as there werenāt many alternatives on OS X ( as rightly pointed out by Karen).
Things are different today, many, many tools are available and many are very easy to use (GO for instance, it will hardly take you longer than a weekend to get started), but still people are afraid of the efforts or they might get nerveous around the magic word ānativeā. But in this case start with Swift for macOS (not too complicated to get into it) or us python, php, quasar, vue, react for web - angular is most likely far too much for some one who used Xojo web in the past.
Quasar for instance is extremly easy to start, only prerequiste is to read. My general advice would be: why not start playing around with some tools (go, vue, java, rust, you name it) in parallel to your Xojo work. Just reserve an hour a day ā¦ The problem is that you have to start, the rest will come over time. No one who worked with Xojo is a dumb deveveloper, have trust in yourself to learn something new (plus something free of an annual subscription). And if you need a full blown cross dev UI, then chose JavaFX. Thatās the next thing ā¦ ask yourself if you really need cross platform? At the time of Realbasic it was one of the rare easy options to develop on a Mac, this changed as well. If you used Xojo on Windows, ask yourself if you really need macOS.
Getting one good solution implemented on ONE platform is probably better than falling on cross dev with Xojo ā¦
Donāt worry API N+1 to the rescue, waitā¦ You mean it made things worse? Canāt be, tāwas my idea and I know what people want.
FYI: I made 3 public offers to help Xojo with my complaints about the crumbling Mac framework. One time the CEO actually wrote to me saying that Dana has asked him to contact me.
So I replied and he ghosted me, he doesnāt want to change a thing, heās doing just fine thank you very much /s
Iām not Karen (no shit sherlock), but if I may. I do not have faith in their desktop framework going forwards. The main reason being is that theyāre NOT putting focus on an already dilapidated framework.
There is so much it doesnāt support and cannot support with some serious refactoring, on top of that, API N+1 added more bloat and more complications to a framework that they have to use other tools to modify, yeah, not even their own language.
Not to mention that in recent years, show stopping bugs are duct taped, and come back at a later date, take the version number crashing Xojo made apps problem. So many people told them what theyāre doing wrong, yet they refused to listen, and the crashes came back within months.
I have accepted that it is inevitable and are using that as a reason as to why I must make the journey to another tool.
On the plus side, the new tool will give true multi-core processing, smaller, faster and less memory hungry apps, that have full access to the entire GUI toolbox and system provided frameworks, without needing an expensive plugin or years of understanding declares. Iāll be able to just use SF Symbols and dynamic colors, scrollviews, tableviews, OS handled color picker and many other things that Xojo couldnāt give a damn about.
2 Likes
It is usable (well at least API 1 - never moved to API 2) but in general it has way too many rough edges, limitations and incomplete/limits features than it should have at this point in time.
Also the capabilities of the language itself have not increased in a long timeā¦
All that said, it still does produce reasonable X-platform (Mac -Win) apps for in-house use that donāt need to do anything fancyā¦ and itās what i know.
I coded in a number of other languages long ago ā¦ but in the last 20 years I have only used this one.
- Karen
1 Like
wellllllllll ā¦
99.9% of the time Iād agree
there may be options that can be put into use
Not the compiler though 
That is no change. If Compiler or framework. For the user it is the same problem. And with the compiler: the point is: you need always to use the IDE to compile. In my opinion not the best Idea. Maybe you rethink to build a Java Backend for your IDE with JavaFX. Could do the Job completely and would work.
Why Java? While you then would have a Xojo replacement which really works and has a future. Writing a Web App is also possible with this workflow. I can assist you with the virtual machine building for the WebApp. The Rest isnāt too complicated. as Xojo has many similarities especially in inheritance to Java there is a good migration way. Would need two years but would result in that what you need: a replacement for the Xojo Developers.
As someone who is now immersed in the Go language Iāve been very impressed with Golang progress in the past 9 months. Two major language feature updates (all while still backwards compatible), speed enhancements, structured logging, added security and vulnerability checks, added project templates, and they just added perfectly reproducible verified toolchains.
Some of these changes help everyone right away. Some only help a narrow group, at first glance, but help everyone in the long run by making the ecosystem more secure and robust and increasing trust in the language.
Xojo keeps thinking new targets and API 2 are the way forward. I think we all have our doubts on that.
1 Like
Xojo fell way behind Swift, which evolves significantly every year. Xojo was incepted in 1996 and Swift in 2004ā¦
The Xojo language of today looks very much like a language of the 1990s.
2 Likes
Xojo keeps thinking we donāt need explicit compiler Guy. That is the difference to GO Language. Without that you canāt do all that.
Is it really the language? I donāt think so. I personally believe it is rarely about a language. Look at go. From a language perspective it is quite ālimitedā, but still very powerfull. It is more about the ecosystem, the support, the roadmaps, the commitment to deliver on promise, itās about performance, security, documentation, amount of users willing to help, etc.
Loog at go, Java, C++, C#, C, Rust: all of them having together that they have even growing ecosystems. Especially Languages like Java having big amount of ecosystem around. And that is not the case in the Xojo World. There is a jungle of paid Plugins for much money.
as I wrote:
It is more about the ecosystem
something where GO still has a way to go (pdf libraries for instance) compared to Java, but still much better than Xojo.
Xojoās compiler, and language, arent horrible
There are aspects that could use updating and improvement - no question
Async/Await as a built in language feature would be nice
And improving its ability to crank out speedy code would be nice
The majority of the bugs are in Xojoās framework which provides the controls people use, and a lot of the global functions that are used
However, USERS of Xojo dont realize that āthe languageā and āthe frameworksā are not one & the same because of how its bundled together and spoken about by Xojoās staff & CEO
They conflate ālanguageā with āframeworkā as do many users
In C++ stdio is just a āframeworkā in Xojo terms
In Java jdbc is āa frameworkā as well
They could be replaced by something else - but its unlikely they will; be because they are robust reliable etc
IF it were possible to replace Xojoās framework with one of our own making then would Xojoās language & compiler be the same problem ?
Iād expect not
But, thats not something that can be done easily in Xojo
Or at all
and thatās why the story is over ā¦ 
- only a question of time. I donāt see how they can get their head out of the sand and the competition is not sleeping, every day counts (in theory). But what do I know, Iām not a genius.
Yes, this is the end. Using Xojo is riding a dead horse. The talented management is doing the grave diggerās work. Time for mourning.
1 Like
and watching all the joy in GPās face while people are throwing money into the freshly digged grave day by day ā¦
2 Likes
Why Iām working on a few things in C# instead of Xojo
There is a massive difference. All that languages can be compiled with their native compilers for the native platforms. That makes it more performant than the llvm compiled stuffs. All of that languages are much much faster than Xojo compiled stuffs. Xojo compiled means without a real gc. That makes problems on all edges. No threading is implemented and nothing like sync-async. Stuffs I miss on that language while for example sockets are the biggest pain in the backside I ever met in my entire life. I am aware of that in Go, C, C++, Rust, Java and C#. None of that languages has a so miserable speed in String concatenating, none of them has a so miserable speed in all benchmarks I know. I testet 40. All of them in Xojo at least 20 times slower than in the other languages.All stuffs could be better when done with a better compiler, better frameworks and so on. But that will never be. It is like waiting that a dead steer will spend milk. That will not be happened. And while Xojo is a dead end there is no chance to change that. Thank about an implementation of threading. Would be funny. Hmm. Strikethrough. Impossible. Too slow.
This is the entire point. Compiler related, language related and framework related. So what you want to tell me? That it would become as flexible like C, C++ or Java? I never laughed more hard. Sorry Norman.I am Scientist. Facts are counting. And this facts I have in case of Xojo. the Language. The Framework. The Compiler.
Thatās it. It is at itās end.
Xojoās compiler is also native - I have no idea why you think it isnt ?
Go uses LLVM. Rust uses it.
Many modern compilers use LLVM
LLVM is JUST a compiler construction set
There are things about Xojoās use of it that result in slowness that I cant say as they are internal only details
Lets just say its not optimal
And their last compiler guys knew that and had a plan to correct that but ā¦
GC isnt the problem
It uses a well known predictable and reliable mechanism
The leaks GENERALLY are not in it handling of memory related to object creation & destruction
Most are right in the framework itself
I believe async/await would requite compiler support
And an overhaul of their existing frameworks to remove items that are not reentrant and therefore not thread safe
IF I werenāt prevented from revealing āinternal detailsā you might understand why LLVM isnt the issue. Nor are their paradigms used for SOME things like strings etc
I tend to agree that its unlikely Xojo will do anything about any of this
Sadly
You have strong opinions about it
And some facts based what you know about it as an outside observer
I definitely know some that you do not - so my opinion is differently informed that yours
I would say āmore completelyā informed than yours
Now, do I think Xojo WILL do anything ?
No