Greg, I have found it very noticeable (now that I have moved the majority of images out of Xojo and onto an HTTP server on the same box) that both the image load / render time has improved but more interestingly the actual speed of the Xojo web app has increased by a very visual amount. I wouldnt want to quote stats but it is the difference between clicking and waiting a couple of second to clicking and blinking and the page is displayed and rendered.
That doesn’t surprise me. There can be a real bottleneck at the app if it’s serving a lot of data.
Ok so what is Xojo Incs plan to address this because even you have to agree that this just isnt going to make it possible to developers to write any forms of web apps that are going to have real world usage?
Spreading the load out from the web application itself is always a smart architecture. The web application should be as tightly focused on the UI logic as it can be as you need to scale.
PHP, Rails, etc don’t have you push binary file or image data through their interpreters directly- they go through independent web server URLs. We offer things like built-in images for convenience, and it’s certainly good enough for vast majority of our users with real world apps. But once you’re concerned about scaling up past the point that feels like a bottleneck, delivering binary data outside of the web app is a very good idea.
We’re always working to improve the speed of our internal web app framework, but splitting out commonly served binary data like some images to the dedicated web server (as discussed here) is always a good idea to scale, not just in our framework but in general.
I fully understand that this helps scaling etc but it really does make it total pain in the backside to manage. What would be much cleaner for the developer is if you could embed the images within Xojo as you do now, but have an option in the app settings to specify that images will be held externally and then you can enter the URL to use for the external files, then when you do a build all of the embedded images should be output to an image folder under the build folder. This was you benefit in that Xojo can be used to manage changes to images etc and the developer can ensure that he is uploading to his server the correct image files that go with the project. This would make it far easier for moving from an “use embedded images” to having to use a separate sever and also makes it much easier when you decide to change the base URL for images when you have 100s or 1000s of images in the web app.
You should file this as a feature request and I’ll make sure it gets looked at- I quite like this idea to make the external resources easier to work with.
It might also be worth looking into spawning worker processes or using preemptive threads to deliver static content. I see this as separate from Nathan’s suggestion which would still be very valuable on its own. But you guys might be able to free up the web framework by simply employing concurrency under the hood when it comes to static images and JavaScript files, thereby raising the bar before someone needs to use external servers.