Client-Side pages in XSLT: Promising?

Comments

3 responses to “Client-Side pages in XSLT: Promising?”

1. 

   Ivan Pepelnjak

   11/16/2007

   See my XML/XSLT article at InformIT: http://www.informit.com/articles/article.aspx?p=677911&seqNum=1

2. 

   Frank Carver

   11/16/2007

   I have done some client-side XSLT processing in the past, but don’t find much use for it at the moment. Here are a few reasons and issues for your consideration:

   1. XSLT is generally mind-bending. It does not fit comfortably with the mental models of designers or programmers, and the way that XSLT instructions and literal XML output are mashed together in a typical XSLT stylesheet makes for a tough and fragile development workflow. One implication of this is that writing and maintaining XSLT stylesheets is a specific niche skill, and the XSLT guy(s) can often become a bottleneck preventing or slowing important look and feel changes from reaching a live platform. Maintaining subtly-different stylesheets for different browsers and ensuring that required changes are correctly implemented in all of them can become a version-control nightmare.

   2. Although XSLT /can/ deal with non-XML input, it is even more clumsy to do it than using XSLT to process XML. The implication of this is that the input documents to the great majority of XSLT processing are XML. A subsidiary implication is that whatever business process is producing the input to the XSLT must be able to produce XML, and in a stable and yet rich enough format to enable the XSLT to do its work. If the “natural” format of the input data is not XML then this adds an extra server-side processing step, which may negate the speed benefits of offloading styling to the client.

   3. The visual effect of transformations possible with XSLT overlap a lot with the kinds of transformations possible with CSS. If all that is needed for a particular style is covered by CSS, then CSS can work out a much simpler and cheaper way to make use of client-side processing. CSS tools aimed at designers are common and powerful. The create/deploy/test workflow for CSS is much more familiar, and the many “gotchas” of working with the quirks of multiple client versions are pretty well understood. XSLT tool support is much less familiar, and much less is understood about the individual behaviour of the different possible client software.

   4. In many modern applications, the static appearance of a page is of diminshing importance. More and more high-profile applications are using in-browser JavaScript to dynamically manage page appearance and contents using Ajax and associated technologies. In such applications, the need for transformation of whole pages is virtually non-existent. XSLT may have a niche for the transformation of dynamically loaded page elements or components, but in practice a development team which has already “bought in” to programming JavaScript in the browser is much more likely to be comfortable with describing any such transformations in JavaScript rather than a wholly new and different language.

   5. Finally, although distributed XSLT processing in-browser is fast compared to the same process on a shared server, both of these are slow compared with getting the page right in the first place and not needing any transformation at all. It is a general truism of web applications that a page is read many more times than it is written, so /any/ processing (client-side or server-side) which is done on a per-request basis may be seen as wasteful. Many high-volume applications take the approach of generating complete and fully static pages whenever the content changes, then making these static pages available over an efficient commodity file server such as Apache.

3. 

   Robert Nagle

   11/16/2007

   Thanks for your thoughts (better informed than mine!)

   Just one thing. XML/XSLT is an ideal solution when you have relatively static content to be translated to various formats. That’s what we’re struggling with in the ebook world.

   from the standpoint of documentation, xml to xslt (via DITA, docbook) seems a good single-source solution. But that is not the same thing as websites.

   I have to wonder though how much content out there is really dynamic. Yes, ads and rss change and comments, but there are many kinds of site which show basically a lot of static content after a month or so.

   I can imagine the browser issues though, especially with ajax thrown in.

   that’s interesting though. I never really knew that javascript could play a role in transforming. JS can do everything!

This site uses Akismet to reduce spam. Learn how your comment data is processed.