Oh I imagine they could fix it if they wanted to. For some reason they like to work on the new & shiny rather than fixing what is already out there.
We use PHP extensively and have had to deal with lots of dodgy situations. Its obviously better than Xojo Web by the sounds of it but by no means perfect.
I’m not sure, but didn’t the original programmer of Web 1.0 leave the company? Which could make it more difficult to fix that one.
Fixing this memory leak bug in Web 2.0, adding the missing features and handling their speed issue (by design unfortunately) should get major attention now if they want to save this platform. I don’t think people are willing to wait a couple of years again for a stable version (like what happened with iOS before it finally got some much needed attention).
1 Like
I dont think anyone is asking for PERFECT
But a reasonable and reliable plan on how to report & get those issues dealt with
That isnt happening consistently or quickly enough for many
1 Like
lets say that after a decade working there I’m quite sure 
Yes thom left Xojo but there have been lots of fixes to Web 1.0 since his departure
It really would depend on knowing what causes the memory leak
If its in the C++ framework then fixing it would be great for every last xojo app
That every xojo app doesnt leak like this suggests its within how the xojo portion of web 1.0 works
And that definitely should be something that they can fix
1 Like
I do wonder sometimes what the Xojo devs do all day as the level of productivity appears to be quite low.
Maybe they would get more done if they didn’t faff around organising hang outs and pointless stuff like that.
I can tell you what I did
Go back read the release notes and just about every last IDE bug fix was me (the VAST majority)
As well as some framework fixes in C++ and Xojo code
About 60% of all fixes in the notes were my doing for a long time
2 Likes
I honestly am thinking the same thing sometimes, but didn’t dare to say so (even here). 
Not having a physical central company place anymore may have something to do with that? (just wondering as not everyone has the discipline of Norman).
An example of this is if they answer on the forum ‘but we are not ALL working on Android now!’. Well, what the hell are the others doing then in that period of time and why do they output so little results for the platforms they are working on? No wonder there is frustration.
It is all a bit to playful these days and I’m missing the seriousness a company like Xojo should display…
1 Like
For that I thank you.
I think this will definitely be a factor as I know our company’s productivity nosedived a bit last year during the lockdown when everybody was working from home.
Too many distractions (he says while posting on a forum).
1 Like
Xojo is good for only Desktop & Console apps. Rest are a marketing gimmick.
If you started with Java you will find out that for Desktop it is also simply a gag. Even without Marketing. String Handling is slow, File Handling is slow. Xojo needs a bit of love on all edges
I must admit i’ve never noticed any obvious performance issues using String.
Do you have an example of where you think Xojo is slow?
I made Examples when testing Xojo performance against B4J, Java, C++ and Lazarus/Freepascal. It is the slowest with a big gap between xojo and the others. String handling, String comparsion, Counting, mathematical operations (multiplicating, dividing, adding, subtracting). Even optimized Code with threading was not rescuing it for Xojo. Windows, Linux and MAC where tested with the Result: xojo is much slower. Also tested: MYSQL adapter and Postgresql Adapter. Same Result. Only Ruby on Rails was slow as Xojo, Python was between all of them. Normally I would think that Xojo should have been at least with Java and Lazarus in one Place. But this is not the case.
Out of interest, can you share any of your examples?
Surprise: B4J is less fast compared to Java: 21 milliseconds for the operation. That means: XOJO is blaming slow.
This is probably because B4J has some object wrappers or does some casting. You could take a look at the generated Java.
1 Like
OK.
My gut feeling is that you haven’t tested what you think you have.
There is a high probability that the Java compiler will have optimised the code to avoid performing the loop since everything inside it is constant. The Xojo compiler more than likely won’t have optimised it (maybe the highest optimisation level does).
I could be wrong but it looks like you have actually compared 1 iteration using Java against 1000000001 iterations using Xojo.
1 Like