Any big sites using Client Side XSLT?

Question

Lately, I\'ve been pondering the somewhat non-mainstream architecture of building raw XML on the server side, and then using an XSLT stylesheet on the client to transform the XM

Answer 1

I agree with Elijah's answer. I think that using client side XSLT is a difficult job. You have to do a lot of QA for it. But whereas with server side, you don't that QA. You have to take care of all type of clients and possibilities while using client side. There may be a possibility that your code may break while using client side XSLT.

Answer 2

I couldn't tell you in detail how it's implemented, but World of Warcraft is pretty big and high traffic, and their web site is implemented as you describe.

Answer 3

I may be biased when I say this, but working on a web based app that does this, I hate it. The only reason it is even viable is because the clients are only IE6+. Even then, there are issues with it. I find XSLT to be very difficult and would suggest if you are going to do this to get a good tool for debugging and editing XSLT. Why not use JSON and jquery? Must more standard and less client side variability.

Answer 4

I am currently running a few minor pages with client side XSLT, all in swedish though (lillemanfestivalen.se, resihop.nu and beta projects). My biggest concern were that google did not index my pages content, just the XML without the transformation. However, since I launched resihop.nu a week ago, it shows up on google with transformation! :D

Now my other concern is facebook and other social sites, that do not understand how to handle it. I still, however, think the up sides are greater than the down sides. The fabulous speed and separation I get is awsome. And with resihop.nu, I dont even develop a separate API, I just point developers to the site itself. (More work will be needed there to make it good though)

Answer 5

I don't know any big public Websites that use client-side XSLT transform (well, except World of Warcraft mentioned by Joel :-). So I cannot answer your question directly.

However, from time to time I was pondering the same question myself, and I have a hypothesis that the number of such sites on Internet must be very close to zero. :-)

The short version of my theory behind this hypothesis is this: with the exception of some pretty exotic cases, provision of client-side XSLT option is simply not worth the trouble. :-)

Answer 6

Like other people have mentioned, Blizzard has many sites that are client side xsl. I would recommend avoiding client side xsl. It is a really cool idea, but there are many unusual bugs that you need to work around.

In Firefox, any javascript that uses document.write will destroy the DOM. Also, the noscript plug-in for firefox stops client side xsl. In both cases, the user will see nothing. There doesn't seem to be a way to detect this kind of error, so a fall back will not work.

In IE, if you have anything that does a 30x redirect to something of a different origin (going from http to https or crossing sub domains), you will get an error for violating the same origin policy. You did not really violate the same origin policy, but IE acts like you did. For example, if you go to http://foo.example.com/login and that does a 302 redirect to https://bar.example.com/login.xml, IE will treat the xsl as if it came from bar.example.com and it will treat the xml as if it came from foo.example.com. So you will need to revert to something like a meta refresh for your redirects.

These are the things that I came up with off the top of my head. It is a neat idea, but be aware of these issues.