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.
To help with the transitioning, we've decided to
make the
razor
tutorials on Umbraco.TV free. So what are you waiting
for, really - go on, learn something new and build better websites
tomorrow!