Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Context

Working as a freelance developer, I often made websites completely based on XSLT. In other words, on every request, an XML file is generated, containing everything we need to know about the page content: the name of the user currently logged in, the top menu entries, if this menu is dynamic/configurable, the text to display in a specific area of the page, etc. Then XSL process (caches, etc.) it to HTML/XHTML page to send to the browser.

It has a good point to make it easier to create small-scale websites, especially with PHP. It is a sort of template engine, but which I prefer to other template engines because it's much more powerful than most of template engines, and because I know it better and like it. It is also possible, when need, to give an access to raw XML data on demand for an automated access, without the need to create separate APIs.

Of course, it will fail completely on any medium-scale or large-scale website, since, even with good caching techniques, XSL still degrades overall website performance and requires more CPU serverside.

Question

Modern browsers have the ability to take an XML file and to transform it with an associated XSL file declared in XML like <?xml-stylesheet href="demo.xslt" type="text/xsl"?>. Firefox 3 can do it. Internet Explorer 8 can do it too.

It means that it is possible to migrate XSL processing from the server to the client side for 50% of users (according on browser statistics on several websites where I may want to implement this). It means that those 50% of users will receive only the XML file at each request, thus reducing their and server's bandwidth (XML file being much shorter than its processed HTML analog), and reducing server's CPU usage.

What are the drawbacks of this technique?

I thought about several ones, but it doesn't apply in this situation:

  • Difficult implementation and the need to choose, based on the browser request, when to send raw XML and when to transform it to HTML instead. Obviously, the system will not be much more difficult then the actual one. The only change to make is to add XSL file link to every XML, and to add a browser check.
  • More IO and bandwidth usage, since the XSLT file will be downloaded by the browsers, instead of being cached by the server. I don't think it will be a problem, since XSLT file will be cached by the browsers (like images, or CSS, or JavaScript files are cached actually).
  • Possibly some problems on client side, like maybe problems when saving a page in some browsers.
  • Difficulty to debug code: it is impossible to obtain an HTML source the browser is actually using, since the only displayed source is the downloaded XML. On the other hand, I rarely go look at HTML code on client side, and in most cases, it is unusable directly (whitespace being removed).
share|improve this question
1  
It doesn't matter what the raw HTML looks like. Tools like Firebug format it for you. –  Jeremy Heiler Dec 27 '10 at 12:38
    
If your website is more content driven, you may want to look into Umbraco CMS, which makes heavy use of XSLT. –  Kevin Wiskia Dec 27 '10 at 17:05
    
Do any browsers have XSLT 2.0 yet? Personally, I wouldn’t want to go back to XSLT 1. –  Christopher Creutzig Jan 4 at 12:39
    
@ChristopherCreutzig: I remember server-side XSLT 2.0 support being very limited (although I don't remember precisely whether the issue was with C#, Python, PHP, nginx ngx_http_xslt_module or all four). I highly doubt client-side support of XSLT 2.0 is better. –  MainMa Jan 4 at 14:18
    
@MainMa What stops me from using, e.g., saxon on the server, completely ignoring whether my server is written in Ruby, PHP, Java, C#, or x86 assembly? The server is a place where I can freely mix code from all the languages and environments I want to – assuming I don’t have some crippled hosting solution where I cannot call external programs, of course. –  Christopher Creutzig Jan 5 at 9:50
show 1 more comment

4 Answers

up vote 21 down vote accepted

Browsers can't progressively render XSLT

This means that nothing else loads and nothing is displayed until all data and whole stylesheet is loaded and processed.

You're missing out on progressive rendering, early fetching of CSS & JS.

Initial load is delayed by another request

For small-ish files (<20kb) number of requests, not bandwidth, is the bottleneck for front-end performance, and most pages and stylesheets will fall into this category.

If you have large pages, then it's even worse — see first point.

You probably aren't saving any bandwidth

XSLT itself is quite verbose and might need to contain templates for whole site and logic for all rare cases, not only things used on current page.

You still have to include all data with some markup in the main XML file you're sending, e.g. if you're sending a blog post, then there's no magic that XSLT can do to make it substantially smaller. If you're sending complex data, then it'll have lots of markup anyway.

Caches are overrated

Browser caches are not that great:

40-60% of Yahoo!’s users have an empty cache experience and ~20% of all page views are done with an empty cache.

and on mobiles, where latency makes extra requests most expensive, caches are even worse.

Check your bounce rate — those are users who don't benefit from cached XSLT, and even pay extra price to download stylesheet and wait for it to be processed.

gzip is a reverse XSLT

Most transformations done via XSLT come down to changing terse markup to more verbose one and adding repetition. But gzip is great at removing repetition/redundancy from files!

You should be using gzip anyway (it's crazy to send XML uncompressed). It's very likely that gzipped size of processed document will be about the same as gzipped size of unprocessed XML — but you won't have to send extra XSLT, and browsers will be able to start rendering as soon as first packets arrive.

Client might be slow

Even assuming best case of loading from cache, XSLT processing on client-side is faster only if user's CPU is faster, and his XSLT engine is faster.

On server-side you can do all kinds of optimisation tricks (e.g., cache processed fragments or even whole pages). You can use latest, fastest XSLT processor (browsers have only XSLT 1.0 and likely not very optimized). And your server probably has beefier CPU than many cheap office computers, mobiles, etc.

share|improve this answer
    
Excellent Answer! I wish I could up-vote it multiple times. –  Gaurav Dec 27 '10 at 13:36
1  
+1 especially for gzip point –  NickC Dec 27 '10 at 15:28
add comment

Sending compact XML and having a cached XSLT on client may even save your bandwidth.

You leave out any browsers that don't support XSLT, like smartphones. But you should create a speialized version for these anyway.

share|improve this answer
1  
There is no specialized version for the browsers that don't support XSLT (IE6, smartphone browsers, etc.). For those browsers, XSL transformation is done by the server, based on the same XSLT file, and the final HTML is sent instead. –  MainMa Dec 27 '10 at 12:43
1  
MainMa: yes, but you usually apply a different XSL for smartphones, because screen size is quite different, you can't use :hover. etc. –  9000 Dec 27 '10 at 13:14
add comment

There's no reason why doing this serverside should not scale as well as generating HTML directly. There's also not much reason for a big constant overhead in comparison to PHP. Appearently there are XSLT > JVM / CLR compilers and I suppose you could even translate it to native code.

However the idea of transporting data and presentation structure seperately is good as such.
It can save a lot of bandwidth and even server performance. But pomeL has mentioned a number of points.

For proper support accross browsers, xslt.js could help.

Personally, I am no fan of XML, so I would use JSON instead and a JS template engine, that will execute in the browser. Or some sort of template engine, that converts template markup into executable js on the server side, which is used for rendering on the client side.
JavaScript is reasonably fast and available virtually everywhere. JSON and JS are far more compact than XML and XSLT.

share|improve this answer
add comment

The primary problem used to be that only a few browsers supported this well, so it was not worth the trouble essentially creating a new platform to support. Additionally older versions of IE did not support this well, and if I recall correctly at least one IE had a different XSLT dialect giving all sorts of fun problems.

share|improve this answer
    
If those few browsers are the ones used by a majority of users, it might be worth the trouble. –  user281377 Dec 27 '10 at 13:31
    
Plus, you have no control over what level of support the client systems offer for XSLT. If they're using some non-standard-compliant plug-in or something (I know, that almost never happens...), then your site won't work and it'll be almost impossible to support. –  TMN Dec 27 '10 at 14:21
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.