![]() ![]() 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. 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. this is some kind of public ‘pre-alpha’ release and by the end of the year I can re-test this with better results. It always surprises me how freaking fast JavaScript and a browser actually is! IF you do it right… 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. A WebApp is expected to be swift and behave just like a native app. No way I could present such a demo to a client and still hope to get the job. ![]() I consider a response from a user’s action under 300ms as reasonable. I can’t explain the delay before the adding of the controls starts (about 12 seconds). 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. 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). 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 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. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |