A month after the first release of Web 2.0, Xojo has released a maintenance update. Unfortunately, the slow workings of a Web 2.0 App have not been addressed.
I understand it will not be a small feat to fix this one. As described in my previous post, the problem is in the core design of their framework (especially the event system) and I can not believe anybody at Xojo hasn’t been able to predict this would cause problems, especially when bigger Web apps with lots of dynamically created components will be build. All we have seen now is very small ones and even there the problem already shows.
For example here is a run of such a new small app named Showcase. Note that I have a 200Mbps broadband internet connection and speed has never been an issue.
Xojo is giving as the main reasons for such slow behavior the distance from the server, latency, number of hops and the quality of your network connection. Well, of course that may be a variable in the equation! But, this is something EVERY web app builder has to take into account. You can not assume your users are living next door to your server. That is why the golden rule is: avoid many roundtrips to the server at all costs!
But here is the rub: this is exactly what Xojo’s event system does by design. As demonstrated in my previous post, adding 100 components does 200+ roundtrips to the server, it even happens for events like shown and hidden.
I can’t see an immediate fix for this problem. Maybe HTTP/2 could help a bit, or WebSockets, or doing stuff in batch making less requests? Or maybe there just isn’t one quick fix and going back to the whiteboard and rethink the whole event system is the only right decision in the long run. Anyhow, action will be needed from Xojo if they want Web 2.0 to succeed. There is little point in evaluating the other things in Web 2.0 without this being addressed first.
Last week, Xojo Inc. released their first version of Web 2.0, a framework to create WebApps to replace their old one. An overhaul was long overdue and as I recall, a first peek was given at XDC2017. So given the development time span, they must have come up something extra ordinary. I was eager to give it a try!
I fired up de tool and picked a Web Example: WebGrid Container. First thing one sees is some kind of mock-up browser. I guess I was actually expecting to see the real deal, but no biggie. On the right are the controls one knows from the desktop framework. There aren’t that to many to pick from and I couldn’t help but thinking they had to split up controls just to fill the library. For example there are three buttons (OK, Cancel, Standard), which are exactly the same HTML component, except some very basic styling. Same goes for the inputs (normal, password, email, number, phone and url) which are in HTML just one input tag, with a different type attribute. This could’ve easily just been a property of one input component. But alright, it’s eye candy 😉
I was especially interested in how they tackled the 12-columns system in a WYSIWYG designer. This is the most widely used system in nowadays responsive web design and as Bootstrap (the CSS framework that is behind Xojo Web) was one of the pioneers of this system, they must have come up with something special, no? Well, for the love of God, I could not find it! After some digging in the forum, it looks like they picked flex and it is currently only available on a WebContainer. Really feels like a missed opportunity to come up with something truly innovative.
Time to hit the run button! Because you always have to compile a Xojo app every time you want to test the result, this can take take quite some time if you are working on a big project. Xojo has no live code swapping so this is something you have to do even for a minor change, like changing the color of a label. But that is just the way the tool works.
Your default browser fires up and the website is shown, as designed in the editor. Simple and you can immediately start testing your Webapp! But something felt not right. This is a very basic WebApp but it didn’t feel like it was loading very swiftly. Not exuberantly slow but just off and well noticeable e.g. when you are on 3G for such a small app. Time to use the Chrome Dev Tools and look what is going on here…
The Network tab immediately revealed this WebApp loaded A LOT of CSS and JavaScript files! Some of them had nothing to do with the app I was running (charts?, summernote (their web editor)?, datepicker?, …). In fact, Chrome Coverage showed about 9 CSS/JavaScript files were never used. Or there is a bug, or they don’t look how they can optimize the WebApp at all. This ‘little’ app loads 1.7MB of resources and does 44 requests to the server, just to load.
Still, somewhat forgivable, as nowadays we all have fiber internet and caching will help on future reloads. And I can’t imagine there isn’t a future plan from Xojo to put in some serious time to optimize this because they really should: running some quick speed tests show that the numbers are really bad (on Xojo’s ‘Eddie’s Electronics Demo’).
Google PageSpeed Insights (but similar results with tools like GTMatrix)
I know, I know… Some will argument that this is for Websites not WebApps. But is there really a difference these days? And why do my (very big) WebApps get scores of 98+? I take real pride in this and it is really fun if you can show this to your client:
Not everyone is so obsessed with speed like me and looking to squeeze out every millisecond possible, but a RAD tool like Xojo should definitely not neglect this, especially since they have full control over the end result. Luckily, there is plenty of things they can do to get these numbers up and give the user a much better experience firing up a Xojo WebApp.
But then I actually used the app. I’ve put in ‘100’ and hit Set. This is a real time recording:
Here there must be something fundamental very wrong on how this works!
From here on I can only make an educated guess on the internal workings of Xojo Web 2.0 but this doesn’t seem right. It looks like every control is added individually instead of in batch, doing way to many requests to the server (my ‘100’ added 200+ requests). One can see on the right a lot of xhr calls (which looks like some workaround Xojo uses as they do not support bidirectional WebSockets) and the browsers somehow ‘polls’ for events, saved as a file on the server. I can’t explain the delay before the adding of the controls starts (about 12 seconds). It just feels like the app ‘hangs’. I consider a response from a user’s action under 300ms as reasonable.
However it is done, it doesn’t work. No way I could present such a demo to a client and still hope to get the job. A WebApp is expected to be swift and behave just like a native app. I have written WebApps that load heavy lists, animate pages, require quick MySQL access through REST APIs, etc… and are just as fast as their native counterpart so I know it can be done. It always surprises me how freaking fast JavaScript and a browser actually is! IF you do it right…
Conclusion
I really hope for Xojo Inc. this is some kind of public ‘pre-alpha’ release and by the end of the year I can re-test this with better results. A quick look at the forum shows other basic bugs that could’ve been prevented with proper testing and Web 2.0 is missing some deal breaking features and events. But more troubling for me is the missed opportunity to design truly responsive WebApps using the 12-column system and the speed issues it has.
Given the time they spend on it, and that it is not cheap ($699), my overall feeling is a bit of a disappointment. Sure, for someone who does not program as their day to day job, it is a nice-to-have. If you want to impress your local bridge club with the WebApp you wrote last week to keep scores, that will work. But for prime-time-real-world-production WebApps, no, Xojo’s Web 2.0 is far from ready.
Still, looking into their JavaScript code, someone within Xojo Inc. must really, really, really love XojoWeb so there is some hope development won’t stop like it did with iOS… 😉
And I mean this in an very friendly way, referring to one of their latest campaigns 🙂
I was doing some early spring cleaning on the dusty attic of this blog and came across some old projects I did.
Some of you long time followers of my blog may remember I wrote several posts programming in Xojo (previously RealStudio or even RealBasic before that). When I first started this blog, I was a huge fan of RB. The familiar VB6 syntax was what me attracted to it in the first place. I had a VB6 background, and with Microsoft abandoning it, RB was a nice alternative. I really didn’t care much for it being able to cross compile back then as Windows was my thing. But it was nice that it could.
Back then, many years ago, I used this place to write articles mainly on the Canvas (an 11 episode series!) and vintage games.
But also some frameworks like ABXVision that had OpenCV like capabilities (Augmented Reality in its early stages!) and a full blown physics engine ABPE.
The robotics series was a very fun project to do. I was doing a course on Artificial Intelligence at the time and I could use this new knowledge in the tutorials.
But because of Xojos decision a couple of years ago to start using a new syntax framework, most of these projects won’t work anymore without a major overhaul. So I feel it is time to let them go. I recently noticed Xojo had removed this blog from their resource list too, so they must’ve had the same feeling. Honestly, no hard feelings about that! I would too when a blog doesn’t write anything on me anymore.
But what is there currently to write about Xojo? The Web part hasn’t changed in many years and still looks like it is 1995. iOS still feels like it is only partly finished and is missing to many out-of-the-box features to be useful (will the new upcoming android suffer from the same problem?). Should I write about the many bugs and workarounds one has to do?
It must be said many of this remarks have to do with Xojo being a small team, and some stuff (like 64bit or Apples decisions) has been forced upon them. Luckily they have a small but enthusiastic community which is willing to take over the many shortcomings by writing frameworks like Aloe or iOSKit.
So, time to put those fond memories into a box and leave memory lane. Back to the real harsh world ;-).
I will leave the RB/Xojo projects on this blog until the end of the month (March). Maybe, one day, I will find the time to revamp them in Xojo or put them all up on GitHub and they will reappear.
Until then, this blog will mainly report on B4X and my own framework ABMaterial.
Godspeed old friend(s). Until we meet again…
UPDATE: I was planning to make a separate blog section for my old RB/Xojo projects, but I just can’t find the time to do so. I created a raw FTP dump of everything RB/Xojo related today that you can download from here. It is a bit messy so you will have to browse through it yourself. A lot of it will probably be outdated (the main reason I removed everything from my blog) and will need some re-work, but some of it may still be useful for someone.
I Wish I Knew How To… Program the Canvas Control with Xojo Desktop is the latest book of Eugene Dakin in his excellent I Wish I Knew How To… series.
If you ever wondered how stuff is done with the canvas control in Xojo, this is the book you need to have on your virtual shelf. In his well known swift (no pun intended) style, Eugene has written the reference manual for you. Alwaysbusy’s Corner did some humble contributions to the more advanced topics.
For the novice Xojo user, you quickly can get started and learn about the basics of graphics. Step by step you learn more and more when you move through the more advanced topics. This 400 page volume covers a lot of interesting chapters and includes a lot of useful examples with source code:
Topics included in the book:
Text
Chart Fundamentals
Objects
2D Objects
Graphics
Blurring
Cropping
Gaussian Blur
Building basic controls
Animation
and there are two games with step-by-step code explanations to help you build your own.
So head over to Eugene’s Personal Website and get your copy. Also check out his other books in the series on topics like SQLite, XML, PostgreSQL, Office etc…
and support ABMaterial
Alwaysbusy's Corner 