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’).
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… 😉
Until next time and happy programming!
Alwaysbusy
Alwaysbusy's Corner 