I saw people complained about memory leaks in Web projects. Since a few customers may be affected when they move to Web 2 later this year, I want to help to get this rock solid.
Earlier in February I looked to find memory leaks and reported one as case 63378. I don’t know whether my information helped, but as duplicate of 63378, this is now marked fixed.
Friday and Saturday (Yesterday), I spent a couple of hours looking for more leaks. I found one with Xojo.GenerateJSON adding a reference count for arrays and reported that as case 64456. This is now reproduced by Robin and I hope to see an engineer fix it soon. Probably just an oversight and sadly none of the testers (including me) saw that before. Well, the 2021r1 had to ship to get people use it in production to reveal the bug.
I hope to see soon a .1 bug fix update for this and (or r2 with the fix), so we have again a Web Engine, which can run our web apps for weeks without filling memory quickly.
Anyway, if you guys see other cases, where I (or you?) may help to find more information to point better to the root cause, this may help Xojo to make a better product and help everyone here using Xojo.
They made several releases after your report, several after my reports, completely ignored. Mine they said “the reported bugs already existed before the report” and that is the usual excuse to send the report to the long list of “maybe we will fix it sometime in the future, when a good number of new bugs will be reported”. Not silly bugs like “drawing dashed lines is not working”, more like simple bugs they can fix in 10 minutes but without it apps crash. The famous “showstoppers” in a Xojo lingo. I feel that Xojo is becoming a waste of time. A never stable programming language, that seems to aim to be a never stable programming language by design.
theres “language”
and “framework”
theyre not one & the same - most people talk about them liek they are the same thing - but they arent
console apps are about as close to the barebones “language” as you can get
XojoScript even more so
That part has hardly changed at all except for DIM and VAR now being allowed
The framework is a different story
When you write a console app you use the “language” + the console framework
A desktop app uses the language + the desktop framework
A web app uses the langue + the web framework
Some of this is all jumbled together since things like Asc, Chr etc are common so there are bits of the frameworks that are common cross all project types
Where the “Xojo” framework added a new namespace that could be optionally used this revamp is just taking the existing framework(s) and rearranging and renaming things
Which is why its so bloody painful (unlike the Xojo namespace which you could use or not as you saw fit)
the language itself is quite stable ( as noted )
the frameworks and the code they rely on … well …
that said as I delve into more Web 2 I’m finding it needs a lot of help
simple things are harder than they should be
Well, I was very happy to find the leak with JSON -> String conversion.
I hope that one gets fixed soon.
And then we may have a r1.1 or r2 which could be the first deployable version of Web 2!
which means a version you can run for weeks without having to restart because memory gets filled quickly.
If we will get another promise of “we will fix it in a future version” (like an R2), I’m done. And chances are it will go this way and they already decided it. Once confirmed, I’ll give up on Xojo Web for anything different than toy projects. And will keep looking at the Desktop version, very cautiously, like a unreliable development system, until they finally convince me to abandon it too. The reality is that after more than one year, they never shipped the Web2 1.0, always a 0.x version, and sometimes creating regressions affecting some of, kind of, stable parts. I waited for years for an usable Windows version, in 2019 I tried a desktop, with few problems; and watched the promise of web 2. At the end of 2019 they released a crazy alpha of the API2 and Web 2 that they regretted later. In 2020 there was the promise of fixing API2 and Web 2. One year later I can say: no one can use it in production unless you use it in a intranet, shared only by your friends that will make fun of you crashing interfaces just typing 3 ENTERs, or 3 ESCs; and you needing to restart the app all the time to avoid the crashes due to known leakages not fixed for months
Ok, you know I know it. I just wrongly expressed myself. I meant “Development system using that proprietary language, known as Xojo, name used as the whole thing, or language, interchangeably”.
Yes Rick and all this reasons brought me to the point to switch my environment to JAVA with Cuba Project and that’s it. I can generate Server Site GUI and Client Site Gui, I can write code and I get it to work like I wanted it when I wrote it. Nothing else. No Leaks, no idiotism, no changes in the middle of the day without warnings.
Beyond all the bugs and the pre alpha state, in words of @Alwaysbusy , “there must be something fundamental very wrong on how this works!” it is really slow, there are to much trafic and delays in the events. If Xojo cant fix the bugs, they are not going to fix the core problems.
The “how it works” that makes that bad feeling in the UX is that a Web app is made of 2 parts glued together, that should have proper isolated processing, the UI (client side) and the backend (server side). In many environments we write an interface code that solves things on the client side without the need to send any data to the server side, like reading a field, and do some math, and present a result concatenated to a string from other field, show an error message, asking for a retry…, all client side, and depending on the result the final value could be sent to the backend to process the server side of the app we wrote. Xojo mix those in a concept called “server round trip”, all things are sent from the UI to the server, and all processing is done on the backend, and the backend send the UI updates back. This can kind of work, for some very simple UIs, in low latency environments (like an intranet) using powerful and fast servers; but can be unacceptable for $5 VMs on the internet… that other tools can handle easily. I don’t see Xojo separating the processing in 2 sides in the current design, you guys will need to wait for Xojo Web 3.0
there is a definite lack of the ability to say run this code client side or run this on the server which would complicate users lives but probably make for much lower bandwidth & server requirements and improve latency
It is still Cuba Platform but renamed to Jmix, the replacement has to do with the unlucky name Cuba…english vendor was never thinking about the Cuba Project and many people told them this so… Jmix is the same Platform with new features but renamed to Jmix.
It all comes down to the socket event loop. Sure it’s chatty but if it can handle 4000 requests/second doesn’t really matter minus latency. If you can only handle 40 and then add 5 users you are dead in the water + latency.
They said that people should plan the “migration”, because it differs, Jmix is supposedly another (more advanced) engine, so it does not feel like “the same, just renamed”. But ok, it seems the next step in the evolution of such tool, but probably can break some things.
