That is an excessive amount of hardware (and therefore cost) for 1M requests per month. My PHP+PG+Nginx setup can handle at least 6M requests (probably more, just haven’t hit traffic numbers that high yet) for about $100.
Changing the model to being more front end would probably boost what Xojo can support
With it the way it is architected and everything running on a single threaded server I just dont see how Xojo can compare
And I dont mean that as a slam - it is architected the way that was possible then
But that probably needs to evolve to the more front end driven set up you described
23 requests per second per server (NOT per instance), he said that the “servers” had one instance per core, in mac mini should be 8 cores so 23 requests / 8 instances ~ 3 requests per second per instance (on asumed peak time)?
1 Like
I initially thought that was what Web 2 was going to be.
-Karen
2 Likes
I honestly dont recall what was said about the overall architecture
Would have to go back & watch the videos from the various conference sessions about it
That’s not much.
Really?! C’mon… I completely understand the attack on my solution on TOF, but this is just grasping at straws
And I refuse to answer angry as it appears he is trying to provoke me with untrue’s.
For those following the topic: This Kristof is a collegue of mine and I’m working at his computer today so I’m not logged in as Alain Bailleul but it is me answering.
We could build a bus using 100 bicycles. It’d still be a bus. 
@riccardo Cruz that is the most incompetent sentence I ever had to read. Use package and there is no problem with anything on the target machine. You have not a bit of an idea about java but try to speak about it without having any knowledge of professional computing. This answer is showing me that the problem is real: people with no Idea about computer technologies. It is ashaming that somebody writes stuffs which are definitely not true. Not even a bit.
I am using JPackage and sometimes also JLink Distribution. In both Cases it is not from interest if there is any JVM or JDM installed on the target computer. Why? While in that cases the Software comes compiled with everything it needs to run natively without any side installs.
Possible since when? decades. Used by professionals: since decades. Only nubes trying to distribute commercial Software as Java jar Files. You can do that. When you can be absolutely sure that the target computers are coming up with the correct Java Version. For example when I deliver to devices I am building I can deliver jar files. No Question.
In all other Cases I am delivering: native packages. And all of the “problems” you mentioned are NOT EXISTANT. That shows that you try to make politics against Java with lies. Try to speak truths. And try to be not a TROLL. That is one of the biggest problems. Trolls. We have to many of them.
It would be different if you would answer: yes, Java solutions are really powerful but for the most users too complex while they do not want to spend this amount of time to learn Java. Clear: no question, that I would understand.
But this culture of speaking non truths to rescue Xojo as the BEST of all development packgages is not working at all. At the end of the day that is one of the sources why Xojo looses Customers.
Completely agree with you!
Okay, let’s just forget performance for a second, an hour, or 10 years. Let’s assume Xojo is by far faster. Okay, I almost can’t write from laughing now, but alright…
In any case, the performance analysis does not bring much IMHO. Are we talking about an API that generates a token, reads one record, or updates 150 tables in a backend? That’s like comparing apples to oranges. Though Xojo is almost unknown, word would certainly have spread if Xojo Web 1 or 2 was the insider tip, the new big speed booster. Elon Musk would have tweeted about it, or Jeff Bezos…potentially even Donald T (as he likes fake news).
Let’s just talk about functionality. For example, how easy it is to deal with JSON files (reading or writing) with nodeJS, Go, or JAVA, and how easy it is to operate a database, with frameworks that take care of the low-threshold work. Not only NOSQL Databases like Mongo can easily store JSONs directly, the latest postgres DBs have interesting solutions too, but Xojo doesn’t use the current or appropriate libraries.
Those frameworks have routines for authentication, automation, scheduling tasks, for using multithreading. Most of them include toolsets for automated API documentation, the tools can handle git, etc.
So what does Xojo have to offer? Even the current plugin developers can’t keep up with the plethora of functions of latest non Xojo frameworks, and this not just because these alternatives are free.
To be fair: it was never the goal of Xojo to be the fastest and feature-richest solution. The Greens have promised cross-platform development, simple and fast UI design, a contemporary development platform, stability and fun development. Not much or NOTHING is left of it (at least if you have experienced a bit with modern alternatives).
Back to the performance. If Xojo can handle millions of API requests in a certain hardware and software server environment, we can be sure that it will be 10x, 100x faster with any modern framework / language, ecosystem.
1 Like
That is all okay Jeannot. And yes, the concept behind Xojo is nice especially while people with nearly no knowledge can develop Software. But reaal complex projects with about let’s say 60 or 70 MB of Sourcecode without bitmaps and so on means clean sourcecode / text will lead to a crashing IDE. At least under Linux and Windows it is 100% crap. And also with MacOS you may get into the situation that it crashes.
But even that is okay. But what Mr. Cruz was doing is simply not okay. He was directly lying. What he said has no, really no contact to the reality.
The Build System to deal with…yes, you have even the choice to use Ant, Maven, Gradle… what fits your needs is the best for you. And that is not really dealing. The other way around. Let’s say Maven. I can get my Project Archetype, all my libraries and so on, in short: all external stuffs I need with a few Maven lines.
That means: I am loading all the wanted Libs (for Xojo users: Plugins) with Maven and Maven takes care that on all platforms for Compilation I get the right ones loaded and the right ones deployed.
And on top of it, let’s say like the topping of an original italian Gelato; it compiles and packages automatically my deployment Files. And what does Xojo? It deliveres outdated runtimes for C++ for example. On Linux with modern kernels it is total Crap. It has no real working garbage collection. Not a good Idea.
On the positive Site for Xojo: yes, you compile for all platforms from one platform but only when you are compiling with a mac computer. And compilation means in this case also: packing the libraries needed in a resources folder beside the app. So far so good. That is not possible with Java. You need to compile on the platform where it shall run. Means: I need to compile and pack the Windows Version on Windows, the MacOS Version on macOS and the Linux Version on Linux, one Exeption: the IOS Version and the Android Version you need to compile on MacOS. Exeption: using CodenameOne you can compile with their BuildServers for Android and Ios. Small projects even for free. hubba. For free.
And another thing Xojo is best: the graphical Designer … ahh, just a moment, for Desktop, IOS, Android and Web you can even develop one JavaFX UI with Scenebuilder as Drag and Drop UI. Hubba. yes, for sure.
So what Mr. Cruz is here true?
And by the way: in my company we have many dev computers even on many operating systems. Guess what. We have no problems with the Java Version. We can compile on all machines. What we have to decide for the Development machines: which JDK to use. that means nothing else than: which compiler Version we shall use. And okay, that should be always the same Version. That’s true. It would be the same with Xojo, write as 2022.4 and try to compile on another computer with 2020.1 and you will realize: that is also not working. Please compare stuffs that are comparable.
That happens when people writing Stuffs they have not an Idea of.
1 Like
Well, I’m not sure if he’s lying, but I think you’re right that he has no idea what he’s talking about; that’s for sure.
As you know, I had to work with Java developers in the SAP area starting in 1999 because, interestingly, SAP included Java in the first SAP Web Server. You could use ABAP or Java (since it was faster in that area). I was on the ABAP team. There was friction over who did what, and as is often the case, there were subjective differences, but I never questioned the incredible performance and usefulness of Java in the backend.
Around that time, I was also exploring Java for GUI in my free time. Of course, it was still a bit rough. AWT… ugh. Swing was somewhat better, but it was also unattractive in the first versions and not comparable to today’s Swing. Realbasic was top-notch for GUIs around 2004/2005, but the software was never the king of performance.
And after this “good” time, we took giant strides down the mountain… and they increased that speed after the renaming to Xojo.
If we examine today’s JavaFX, I haven’t found anything that Xojo can do and JavaFX cannot. Cross-platform development from one PC is suitable for hobbyists (professionals need to test anyway and require multiple computers). Compiling with GitHub actions or similar is all they needed and will cost them far less than a Xojo license.
This is what I mean when I say Xojo has lost its way. They are attempting to solve challenges in 2023 that no longer exist in any other modern toolset. And they are living from users, who can’t or just don’t want to change their ecosystem, which we have to accept as a fact.
1 Like
Ahh, no, not entirely true. Top Notch GUI was QT in 2002 with C++ and that was also so in case of performance. There is no question, Xojo was never even close to be a Top Language. GUI Development was simple with QT builder also available as KDE Studio. I wrote many X Platform GUI Stuffs with C++. That was running, that was simple, that was good. And native. Even today it would always be my first choice when and if native would be needed.
it was top notch for me (in terms of looking good, easy, and at that time even affordable). I never cared about the price ticket, but today they beyond of that a hobbyist wants to pay in the are of development.
But yes, I accept your choices. The great thing about your choices are, that they are yours 
Is that solution pure Java, or B4J?
I had a Xojo Back end a few years ago, Had many disconnections and had to be restarted daily or ended up not responding. I spent a lot of time with that code but cant be improved, avoided migrating to another tool for the time but had a WTF moment when I migrated it to B4J in a single day of copy/paste/retouch
That is the nice part. B4j is a wonderful solution for everybody which is interested in developing in a basic dialect not far away from Xojo.
Or you use java. Makes the same. For me no problem but many others need to learn java.
In this case B4J. I could not mention the name on TOF so I wrote Java instead as for the server part B4J is just a thin layer on top of it.
By the way: every program written in B4J results in a pure Java program. The clue is: B4J compiles directly to readable Java Sourcecode and then compiles to jar. If wanted the java sources can be obfuscated.