Saying goodbye to an old friend
We've decided to drop our plans of XSLT Support in v5 (it will be around forever in Umbraco 4!). For some this will cause some stir, so trust us that we didn't do this just for the fun of it.
XSLT has served us really well. In Umbraco 4 all published content is cached in one big XML document, making XSLT the obvious choice for manipulating the documents. For those who have mastered XSLT it's been a well-known and very powerful tool when making Umbraco sites. It's highly flexible, optimized for hierarchical content and blazingly fast.
XSLT in Umbraco has been there since the very start, in fact since version 1.0 that I made using classic ASP. Back then XML was all the rage, websites were simple and relatively small. And Microsoft loved XML. That was eight(!) years ago - remember those days?
Since then a lot of things has happened. We've learned that XML doesn't solves all problems, websites have become more sophisticated in their information architecture and new techniques have emerged. Sometimes you have to let go of your darlings to discover something new. And to be brutally honest, XSLT haven't been a happy marriage for most people. In fact, it repeatedly comes out as the number one disliked 'feature' of Umbraco whether you talk to front-end devs or .NET devs. It's time for a break-up from version 5. Here's why:
- It's tough to learn, hard to master
While powerful, XSLT is very complicated to master. There's simpler tools that does a better job in most cases and does a fine job in edge cases. XSLT only does a better job for the 1% who knows the very heart of it
- It's not in tune with modern website architectures
In the good ol' days, websites had a very strict IA. That was a perfect fit for Umbraco's hierarchical XML and XSLT templating. Times has changed. Today website structures are more fluent, more taxonomy based and more diversed (ground principles may be hierarchical but most content is tabular and relational). This doesn't make XML storage - thus XSLT processing - an obvious fit.
- It would be slow
Now that Umbraco 5 no longer stores data in a published XML, the core would need to simulate this in order for XSLT to work. It means converting data. And that means loosing the blazingly speed, that makes even haters accept XSLT today
- The support from the mothership is non existing
While we don't lay down flat when Microsoft change direction, it's no secret that the native XSLT processor in .NET is old and dated. It's many years since XSLT 2.0 saw the light of the day, but the .NET implementation is still based on 1.0 - which for instance doesn't know what a "date" is! We could grab a non-official XSLT implementation, but that would mean taking the responsibility for maintaining it and those resources could be used much, much better elsewhere.
- The alternatives are better now
The way we've implemented data access in v5 and combined with the razor view engine, means that making anything from basic navigations to complex taxonomy based lists is much simpler than even the most elegant XSLT. We'll be providing lots of guidance and examples in the editor to make it easy to get going fast.
Changing habits is never easy but even the most stubborn XSLT rebel alliance members I've talked to think the case is good. So do I, and remember that I liked XSLT so much that I added it to the core in the first place. The same joy I felt back then when the first result of XSLT processing inside Umbraco 1.0 appeared on my screen, I feel with Razor now. And when used together with the data wrapper called "Hive" in Umbraco 5, it's a thing of beauty and speed.