Here there must be something fundamental very wrong on how this works!įrom here on I can only make an educated guess on the internal workings of Xojo Web 2.0 but this doesn’t seem right. Time to use the Chrome Dev Tools and look what is going on here… Not exuberantly slow but just off and well noticeable e.g. This is a very basic WebApp but it didn’t feel like it was loading very swiftly. Simple and you can immediately start testing your Webapp! But something felt not right. Your default browser fires up and the website is shown, as designed in the editor.
#Xojo loop through containercontrols code#
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. 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. Really feels like a missed opportunity to come up with something truly innovative. 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. I was especially interested in how they tackled the 12-columns system in a WYSIWYG designer. This could’ve easily just been a property of one input component. 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. For example there are three buttons (OK, Cancel, Standard), which are exactly the same HTML component, except some very basic styling. 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. On the right are the controls one knows from the desktop framework. I guess I was actually expecting to see the real deal, but no biggie. First thing one sees is some kind of mock-up browser. I fired up de tool and picked a Web Example: WebGrid Container. So given the development time span, they must have come up something extra ordinary. An overhaul was long overdue and as I recall, a first peek was given at XDC2017. released their first version of Web 2.0, a framework to create WebApps to replace their old one. There is little point in evaluating the other things in Web 2.0 without this being addressed first.
Anyhow, action will be needed from Xojo if they want Web 2.0 to succeed. 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. I can’t see an immediate fix for this problem. As demonstrated in my previous post, adding 100 components does 200+ roundtrips to the server, it even happens for events like shown and hidden. That is why the golden rule is: avoid many roundtrips to the server at all costs!īut here is the rub: this is exactly what Xojo’s event system does by design. You can not assume your users are living next door to your server. Well, of course that may be a variable in the equation! But, this is something EVERY web app builder has to take into account. 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.