by Hew Wolff
One of our clients asked us to develop a device user interface that could easily be adapted for several other devices. Based on our experience in the field and some research into emerging technologies, we decided that we should consider three different approaches and do a small trial project with each. I was charged with examining the three approaches: (1) JavaScript and Cascading Style Sheets, (2) XML with XSL style sheets, and (3) generating the HTML at development using a scripting language such as Perl.
I'll describe each in turn and then explain the test methodology and finally the results, which became our recommendation to the client. The final product is targeted to Wind River's RapidControl, which has some affect on the analysis.
(1) JavaScript and Cascading Style Sheets (CSS) are well- tested technologies which we have used effectively before. JavaScript can be used for intelligent dynamic updating of the web pages, client-side form validation, and will ease the implementation of the extreme separation of data and presentation needed for this project. CSS, although useful for controlling features such as font style and background color, will not help in moving data from the bottom to the top of the page, or changing from a matrix to a list design, for example.
(2) XML (Extensible Markup Language) and XSL (Extensible Stylesheet Language) are newer web technologies, designed for the problem of separating data from presentation. XML is a language for the data, and XSL is a language for converting that data into a display format such as the HTML that we want. This conversion process is called XSL Transformations (XSLT).
Unfortunately, browser support for XSL is just beginning: IE supports XSL from version 5.5, and Netscape Navigator from version 6. We could not limit our support to these versions.
An alternate way to use XSL is to add our own XSL at the web server, hooking it up to RapidControl. The advantage is that on the server the XSLT processing can respond more dynamically to the data. We believe there will be an unacceptable performance hit with this technique.
XSLT can instead be used at development time. Rather than the browser producing the HTML from the XML data and XSL style sheets, we can use XSLT to produce the HTML during development, while maintaining the separation between data and presentation. The XML documents, rather than containing actual data, contain markups which are formatted into the HTML pages. Those pages will later be served by RapidControl, and the actual data will be substituted at that point.
(3) A general-purpose scripting language (such as Perl), although powerful, does not seem to lend itself to this project. Such a language could be used to produce HTML in many different ways by changing some template, but what we want is a framework designed specifically for generating HTML; it doesn't make much sense to develop a new framework from scratch.
We have narrowed our test to just two techniques: pervasive use of JavaScript for formatting data into HTML, and XSLT used to generate HTML at development time.
The Experiment
I tested the techniques by implementing three small web interfaces of differing complexity (I'll call them "styles") with each technique. For each style I created an HTML version first and then adapted the HTML version to the XSLT or JavaScript technique.
For each technique, we wanted to estimate the cost in various resources: time to develop, time to maintain, disk space, memory, and display performance.
Effect of Abstraction
The abstraction introduced by both the JavaScript and XSLT techniques has some common effects, both good and bad.
One good feature of this abstraction is that it breaks the HTML production into manageable pieces. A carefully-written HTML page often has a complex and deeply nested structure. Rewriting it in JavaScript allows us to divide it into smaller functions which are easier to understand. Similarly for XSLT code, which naturally breaks into smaller chunks called "templates".
The drawback is that both techniques add an extra barrier between the developer and the HTML code. The developer must wait for the JavaScript code to be interpreted by the browser, or for the XSLT to be processed, before seeing the output. In this environment it is most efficient if web designer and the developer are the same person.
As in adding any layer of abstraction, the benefits are negligible or negative for the smallest projects. Only when we need to deal with many pages or many styles does it become worthwhile.
Maintenance Issues
We can use the total file size as a pretty good measure of how hard it will be to maintain a web interface. More code means more code to change. My experiment showed that the simple interface is easier to maintain in straight HTML than in JavaScript or XSLT. For the more complex styles the advanced techniques pay off in smaller files.
Implementing the styles with the two techniques suggests that JavaScript and XSLT will have about the same ease of maintenance, but either one is much better than straight HTML.
XSLT Pluses
I really liked the way I can separate the data from the presentation with XSLT. I set up a single XML data file containing all the data for the web interface, and a subdirectory of stylesheets for each style. So each stylesheet represents a different view of the exact same data. Eventually this XML file would contain a complete list of the markups in the interface, which would be a great reference document (and could be formatted by another stylesheet into web documentation).
XSLT is well supported by software tools, with a lot of free, high-quality XML/XSL processors available on various platforms. Some have open source in your favorite language. I used an XSLT processor called Sablotron (with an XML processor called Expat), which is popular, reliable, fast, and lightweight.
The XLST learning curve is short. My experiment showed that although I spent a lot of time learning about XSLT initially, I was pretty fluent after about a week or so.
Comparing the Two
XSLT is tightly integrated with XML, which is a close cousin of HTML. This means that it's very difficult to generate invalid HTML with XSLT -- the XSLT processor will catch structural mistakes during development (unlike JavaScript), and will provide helpful error messages (unlike the browser). Since the resulting HTML is very explicit and well-structured, it should be reliable across platforms and browsers.
As another example, converting HTML code into XSL is generally a matter of adding some extra markup tags. Converting HTML code into JavaScript is a more tedious process of concatenating long strings together. JavaScript is a general-purpose language, so it's just not as well adapted for the problem.
I believe this is why JavaScript takes about 40% longer to implement than XSLT, according to my experiment.
One nice feature of XSLT is that the stylesheets can display the same data in many places, but you only have to maintain the data in one place. For example, the XML file contains a system name which should be displayed on every page. JavaScript can do the same thing by including a single file into many HTML pages, but if the JavaScript contains markups, there will be problems from the caching in the browser, forcing us to duplicate the required markups in every HTML page.
Finally, the XSLT development process makes it very easy to examine the HTML output. With JavaScript, this can be tricky, depending on the browser.
Because we're using the stylesheets to generate the HTML at development time, they can't adapt dynamically to the content. For example, you might want to display a parameter's typical value in black, but an error value in red. Since the stylesheet doesn't know what value is going to be substituted for the markup on the server, it can't make this choice.
We could add some simple JavaScript code to make this decision on the client side. JavaScript and XSLT can certainly work together happily, but it takes a little extra care. JavaScript might also be a better choice for complex mathematical processing and is still required for client- side validation or dynamic updating.
On the other hand, the stylesheets can make some important decisions. For example, the menu should be displayed differently depending on the currently selected page, but we'd like to maintain just one master version of the menu in an XML file. The stylesheet responsible for that page knows where the page is in the menu, so it can adapt the menu appropriately.
Performance Comparison
Remember that for our XSLT technique, what gets stored on the server is the generated HTML. The file size comparison suggests that the JavaScript, which contains the instructions for generating the HTML on the client side, is more compact (perhaps as little as half the size).
This means that JavaScript may be a better approach if there's a real shortage of disk space on the server. The JavaScript pages will probably download faster, although they must be "unpacked" after they arrive. In practice I have not found any difference in performance.
Summary
I examined three techniques for implementing easy web page adaptation: (1) JavaScript and Cascading Style Sheets, (2) XML with XSL style sheets, and (3) generating the HTML at development using a scripting language such as Perl.
We chose XSL at development time to keep the interface flexible, adding JavaScript to help with dynamic content in the usual way. XSL is a powerful tool that's well adapted to our problem.
Based on the 80% complete skeleton, we expect that producing one page with XSLT takes about an hour. I would expect that number to decrease for a larger project.
The experiment suggests that the JavaScript approach will take about 50% longer for a medium-size project.
Comparing this to a straight-HTML implementation, either technique will offer significant time savings.