I have an interest in XML based technologies best known for their use in web-based applications. Some time ago I wrote the following article collecting some opinions and ideas based on my experience in projects over the years where XSLT, XForms, SVG and XML Events were deployed.
The article dates from sometime around 2011; its theme was technologies which devolve processing overhead to the web browser with the goal of significantly reducing server overhead and network traffic. I’ve fixed a few typos and updated the links.
Finally, I was despairing about the lack of and apparent withdrawal of SVG support from browsers, a trend which happily reversed and for which good browser support is now available.
XML and Web Applications
Web applications are becoming increasingly popular but what about performance in the face of increasing demands on network infrastructure? I feel that the structure of most current web applications is all wrong with the result that applications transfer too much data, too frequently, suffer from network latency and are unusable on slow high-latency connections such as to mobile devices. Much of the work performed in the server could be done in the browser. This makes sense because we have a computer each to browse on but only one server between everyone. It doesn’t really matter if your computer has a fraction of the performance of the server or if the server is part of a farm, all your computer’s clock cycles are your own, DRM permitting.
I intensely dislike the PHP/ASP/JSP approach found in most web applications, the technologies themselves are not without merit, but in practice they must be deployed such that an application’s entire content is dynamically generated, skillfully avoiding many of the benefits browsers actually do offer.
My interest in XML technologies for web-based applications came about because, used in conjunction, these have the potential to significantly reduce server overhead, network traffic and the number of network interactions for a given task. Unfortunately things aren’t as simple as they might be, but what do you expect? We’re talking about browsers here, they are hardly a coherent design.
A fringe benefit of this approach is, by having the HTTP server supply variations of the XSLT to different browsers, differences in HTML and browsers can be compensated for in XSLT, allowing the application to use consistent platform-independent XML for all its interaction with the browser. The most frustrating aspect of web development is having to rewrite working code because browser X chose to be full of bugs, implement something that fails to comply with standards, not implement something at all or relies on proprietary enhancements.
Round Trips and Server Interaction
So far we can reduce bandwidth requirements for a web application but is it possible to do better? Well, yes. A qualified yes though because this is where the web browser model really cocks up though, to be fair, it was never designed for this sort of thing in the first place.
A solution …
… and the rub
Sadly, current browser support for XForms lies somewhere between non-existent and pathetic and that is a shame. XForms - the one thing other than scripting that really can interact autonomously with users - is a great technology. Once the penny drops, you will never think of web application development the same again. Browsers should support it - they really should, it would be lovely if they did. Surely the lawyers who design software can’t object to this?
Not having XForms implemented directly in the browser also screws up application of CSS properties on form elements. Sigh!
Another nice standard is SVG. SVG is an XML based vector graphics format which supports animation and scripting among other things. Because it is an XML structure it can be edited on-the-fly by either scripts or XForms. Imagine how much easier something like on line map services would be if SVG support was universal. Naturally, one browser does not support SVG. Naturally this blocks universal acceptance. Formerly there was a plugin from a well known graphics and publishing software house that could be used by the one browser to make SVG work. But they were merged with another graphics company, hostile to open standards, who stopped all further development of the SVG plugin and amended the licence to withdraw permission for use beyond its end-of-life date (which has now passed). So much for a level playing field.