Introduction

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.

It’s interesting to reflect on how some of this has dated since then, especially with the recent trend for statically served web sites using recent CSS capabilities and Javascript frameworks.

Although modern browsers have good support for some of the XML technologies I talk about, in particular XSL-T, these would seem to be rarely used nowadays, most web developers preferring Javascript. I think this is largely because Javascript has been around longer and is much better known, but I also feel the declarative approach of the XML technologies is harder to work with than the algorithmic approach of Javascript. Nevertheless, I feel the declarative approach is more secure and easier to place in a sandbox on the client.

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.

Bandwidth Requirements

Reducing network traffic is relatively simple. A good start is to use XML, XSLT and maybe a smidgin of Javascript (I should really say ECMAScript nowadays). Complete pages can be coded in XML, either statically or dynamically, and then transformed into HTML on the browser. The advantage of doing this is that the XML schema can be designed to be application-specific and consequently made much more compact compared to HTML which can be terribly verbose. The down-side is that the XSLT files must be requested by the browser. However, this can be served statically and cached by the browser. Furthermore modern HTTP servers can pipeline the request along with other static content such as images. The cost of the XSLT transfer is amortised over many page loads and the more compact XML data reduces network overhead per interaction. Already things are improved.

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.

Implementing incremental changes to a page is a little more tricky, mainly because it’s necessary to jump through a few hoops in Javascript whereas the browser will automatically apply the XSLT stylesheet when loading a complete page. The basic approach is the same except that the request to the server is performed within Javascript which then processes the response and grafts the result into the document. As with the static case, the XML transferred over the network can be made more compact than the equivalent HTML and the XSLT and Javascript can be served statically. Astonishingly, all the major browsers manage to implement XSLT correctly. Naturally, one browser has a different Javascript API…

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.

The basic action of a web application is to present a screen, take some user interaction and modify or replace that screen in response. This sequence repeats until the browser crashes. Only some of the interactions affect server state. Obviously each interaction represents a round trip on the network, so the user has to wait for the server’s response on each and every interaction. Round trips are no biggy when the internet is lightly loaded but what about early evening when, around the nation, kids are watch on-line video when they’re supposed to be doing their homework? The network is busy, the contention ratio is dire. This is when your web-app is really hammered - the worst case is when the app validates every character you type and you have to wait for the network round trip before the character appears. Touch typists get really hacked off at this sort of thing. Round trips are really only necessary when the server’s state must be updated, so the question becomes ‘can the number of round trips be reduced?’ One could use Javascript to script some interactions in the browser but scripting that means you have to design algorithms and most people struggle to engineer software as far as I can tell. Besides, having to write algorithms to do stuff the browser should be able to do anyway is just wrong.

A solution …

Fortunately, there is a technology that addresses this problem, possibly unintentionally: XForms. In reality XForms is so much more than just a method for filling in forms on a web page more flexibly than HTML forms (which are a form of crippleware by comparison). XForms should be thought of as a generic XML structure editor which can be driven by either the user or the server. It has the ability to perform data validation without interacting with the server or the server can interact with the browser without reloading a new page. With another dash of Javascript, user and server can build some XML structures in-place on the browser, use one of them through XSLT to update the application and others to update the server state. All without unnecessary server interaction! So all those processor cycles on your PC get to do something useful for once and the server is more lightly loaded which has got to be good.

… 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?

There are a few projects to be found on the net which effectively add XForms support but mostly they proxy the web-app server-side to emulate XForms with HTML and Javascript. So we’re back to square one. Developers benefit but the poor punter still suffers. Having deployed a framework which eliminates excessive network traffic and round trips we now have to put it all back because the browsers don’t support XForms and show no sign of acquiring it any time soon. A phyrric victory. The touch-typists will be out with pitchforks and torches.

Not having XForms implemented directly in the browser also screws up application of CSS properties on form elements. Sigh!

The Point

The good thing about XML standards is they provide a formal framework to do good stuff and, taken together, substantially avoid the need to write scripts. This is good because you don’t have to design the same script algorithm over and over again each time you design a new web application. It’s not possible to totally escape the clutches of Javascript but at least it can be minimised. XML standards, intelligently deployed, really do provide the means to simplify application development on the web and users benefit from increased performance.

A Footnote

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.