Current state of client-side XSLT

Last I heard, Blizzard was one of the few companies to put client-side XSLT into practice (2008). Is this still the case in 2011, or are more people now exploring this technique in production? 

It seems that modern browsers (IE9, FF4, Chrome) and client processing power are primed to exploit this standard for tangible savings in server CPU power and bandwidth on large scale properties. Am I missing something?

The negative aspects I'm aware of include

• additional rendering time
• additional assets required on uncached page load
• additional layer of complexity
• noticably less developer experience than server-side template techniques

The benefits I perceive include

• template composition offloaded on the client
• caching of common template fragments offloaded on the client
• logical separation of document structure and data
• well-documented web standard supported by all modern browsers

Finally, although I know it's impossible to predict the future, I am curious to know opinions on whether or not client-side XSLT's day will come. With interest in HTML5 driving users to upgrade their browsers and developers to explore new techniques, I'm eage开发者_运维百科r to see what develops.

Thanks in advance,

Casey

Edit:

Any insight into how transformed XML is viewed by Google and the ramifications it has on SEO is appreciated too.

I use client-side XSLT on kulesh.info. I haven't found any differences in IE 6–9, Chrome, Safari, and Firefox. XSLT transformation happens very fast. I haven't done any speed measurement, but I don't see any differences comparing to pure HTML version (even on first generation of iPod Touch).

mail.yandex.ru (big mail provider in Russia) is also using XSLT on client-side.

Last I heard, Blizzard was one of the few companies to put client-side XSLT into practice (2008). Is this still the case in 2011, or are more people now exploring this technique in production?

Here are some examples:

1. Jenni Tennison's site is completely XSLT-client-site driven and has been so for years.

2. This commercial website is totally client-side XSLT driven: http://www.skechers.com/

3. We already have an implementation of XQuery in the browser: XQIB

4. Michael Kay has blogged about his attempt to produce XSLT 2.0 in the browser and there would be something working soon.

Some people argue that XSLT isn't designed for "programming in the large" -- for example it lacks any separate compilation capabilities. Let's hope that the coming XSLT 3.0 will change this.

I may be somehow lost in translation, but I guess SEO issues is the main reason, preventing a lot of people of using client-side XSLT.

I'm not aware of search robots, capable of parsing application/xml instead of plain html or even flash.

Still it's a good practice (mail.yandex.ru is a notable example indeed) for highly loaded web-apps to use XSLT partially on the client, because traffic is large and SEO-friendliness isn't necessary.

The problem with the XSLT stuff on the web is there are so many other things out there that can be used in place of it that are easier on the developers. I can never really see XSLT taking hold on the web in the form you are describing, in fact I believe Blizzard actually pulled the client side XSLT translations from their sites when they recently did some redesigns to consolidate their brands.

Trust me though, I wish it would, I wrote a solution for a company I worked for in the past that used XSLT translations for all their front end templating. It didn't use client side translations because this was in 2005, when there was still a large market share of browsers that didn't support client side XSLT. One of the biggest issues we had when working with that system was finding developers that could help work on it. And when you found someone who could work with it they'd butcher a lot of the templating because XSLT development is a different beast than any other templating language out there.

While the benefits of using XSLT are tremendous ( do a google search for symphony, a great cms that utilizes xslt as it's templating system ) I don't see it taking much more hold for front end development.

When making a decision about XSLT usage, it usually comes down to a cost of developer time vs perceived benefit in CPU cycles. For a little customer it almost universally means: XSLT, if it exists, goes on a server side. There is simply not enough benefit in figuring out all the client issues.

If a breakthrough is coming, it will be on the big sites, such as: facebook, or google. On those, the CPU cycles offloaded to a client will make up a significant $$$ figure, enough to justify hiring developer(s), who will iron out the client problems. I would be watching those players to see if a change is going to happen

I made a XML - XSLT website a couple of years ago for a project in school and noticed a bug: Firefox doesn't support disable-output-escaping.

https://bugzilla.mozilla.org/show_bug.cgi?id=98168