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
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
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:
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
To help with the transitioning, we've decided to
tutorials on Umbraco.TV free. So what are you waiting
for, really - go on, learn something new and build better websites
Sad to see XSLT go, it was how I got introduced to Umbraco in the first place.
On the other hand, Razor is a better language in many aspects, and will strengthen Umbraco going forward.
#h5yr - Looking forward to a better future with Umbraco 5
Wooow that is some big news.
Now Im forced to learn Razor. But maybe it is for the better :)
Is it still possible to make my own libraries like I can in the XSLT? :)
Thumbs up :)
Already loving razor cant wait to see what is in store for v5 :)
I will not miss XSLT.
Razor for the win.
As a .NET dev I love the Razor only approach and it certainly will make it easier to develop packages for Umbraco as we don't have to support two APIs going forward.
Having played with v5 a bit this makes perfect sense. As a .NET developer I want to be manipulating strongly typed data where possible, not dealing with data that is basically text. Another huge plus with this approach is better support for unit testing.
Keep up the good work!
Great Decision of moving to Razor..
Yet one more thing that makes me really look forward to getting to use Umbraco 5 in production environments. :)
Good work, i can manage without XSLT!
LOL! Hope I didn't come across to stubborn. ;-)
Having used XSLT since it's initial release - way back in the winter of '99! It was this that brought me to using Umbraco. Gave me a massive advantage in developing with the CMS and getting involved with the community / helping on the forums ... and I agree, a LOT of people don't "get" XSLT at all!
Am I sad that there'll be no XSLT support in Umbraco v5 - nope! All the points that Niels raises are absolutely true. If anything the old friend isn't XSLT, but rather XML that we are saying goodbye to.
Looking forwards, very excited about Umbraco v5 - can't wait for the beta!
I couldn't possibly agree more.
This must have been a really tough decision for the core team to make, knowing that XSLT
has been a big part of Umbraco for so many years. XSLT is powerful and fast, and it has been
the perfect tool for Umbraco when you look at how the Umbraco caching mechanism works.
Personally I think the major drawback of XSLT has always been its steep learning curve.
When written poorly XSLT is hard to read and comprehend and it quickly becomes hard to maintain.
That doesn't take away its power and flexibility but it does frighten a lot of developers
that are new to the language, making it really hard for XSLT to become "mainstream".
Software evolves rapidly and I would actually hate to see a great tool like Umbraco stick to old
habits and existing conventions rather than looking at new possibilities, new technologies and
conventions that are generally well anticipated by the community.
Much like we have witnessed ASP.NET MVC grow by community feedback, the introduction of NuGet and
all other efforts and technologies supported by Microsoft to ease software development I am 100%
convinced that Umbraco embracing these technologies in version 5 can only make it stronger,
more powerful and bigger then ever before.
Fully support this decision.
Viewing Razor simply as an "XSLT replacement" glosses over some very important differences.
Yes, Razor is much easier to pick up for .NET programmers versed in procedural programming.
XSLT, on the other hand, is fairly unique in its declarative style with elements of functional programming, which can make it difficult for "procedural programmers" to grok. But by the same token, it often clicks with frontend developers who are used to working with HTML and CSS, since it shares many concepts with that rendering model (the S in XSLT stands for Stylesheet, after all).
It certainly clicked for me, and I find it an incredibly powerful and elegant technology, which is perfectly suited for transforming structured data into webpages. What I love about Umbraco is that it allows me as a frontend developer to build entire websites without writing a single line of "backend" code, because XSLT is so powerful compared to the proprietary and simplistic templating languages found on other platforms.
It also supports a perfect separation of concerns. Anything that extends beyond the capabilities of XSLT is easily supported by an extension, which either already exsists (uComponents team, we salute you), or which I can entrust to a C#-knowledgeable colleague.
Supporting Razor by default means allowing backend developers to move further towards the frontend. Supporting XSLT by default meant allowing frontend developers to move further towards the backend. There is an important difference there.
I have also enjoyed working with a .NET-based CMS that never required me to fire up Visual Studio. All the work I do is based on open web standards that are applicable across a wide range of platforms. XSLT is a solid and open web standard that has been in use for over ten years. Razor is a proprietary templating language that was first released just over a year ago.
I'm as intrigued by new technologies as everyone else in this community, so of course I'll dive into Razor head first and explore what it can do. But I love XSLT and sincerely hope that someone smarter than me can build a solid, unofficial XSLT "view engine" into Umbraco 5.
...and if this decision was made based on the Razor Empire vs. XSLT Rebel Alliance pillowfight at Codegarden '11, I'd like to state for the record that it was very unfair to appoint a heavy metal band as judges.
Of course they were going to pick the team with the black pillows, regardless of the merits of their chosen technology ;-)
I still think,using XML+XSLT to finishing the content render is a good way. Microsoft still using the XML+XSLT to do some site. But update to razor is best good news for modern .net developer. I will learn asp.net mvc as soon as possible.
When are you making the videos free? I am still getting the example text and Register button at the top of the videos
I would have to agree with Dan a bit as well.
As a front end developer, learning another proprietary language is going to be a hard sell with some people. .Net developers, possibly not, I know very little .Net. XSLT seemed like a good fit for me because it followed some semantics of XHTML and HTML5, and of course XML.
Just like learning Wordpress with it's proprietary functions and calls, Umbraco is moving towards that as well.
Too bad XSLT wasn't more supported. As a front end developer I guess another proprietary language to learn is a good thing. Or bad depending on how you look at it. Personally, I just don't like learning another proprietary language when the base of the languages already exist.
I get it, I know MVC is VERY powerful, and am a bit sad to see XSLT go, but who knows. things move on for the better right. Let's hope.
@Dan and @Carlos While fair concerns, it does sounds like you have a bit of prejudgement and - dare I say - a little stubbornness.
Razor does *not* require Visual Studio.
You can edit them inside the Umbraco back office, in the free WebMatrix tool and in any text editor (even on OSX like Textmate or Coda), just like XSLT. We'll provide loads of contextual help inside the Umbraco back office and we're also looking at providing bundles for Textmate and plug-ins for Coda.
XSLT is great because it looks like HTML/XML
I really don't buy that as an argument - you don't become good at XSLT because it have angle brackets. It's not just a markup language. It's a very complex (and different) programming model that's disguised as XML. It neither qualifies nor disqualifies it. But from the XSLT I've seen the past eight years - and trust me, I've seen *a lot* - 95 out of a 100 that goes beyond basics are done wrong.
Razor is very easy to read (and write).
Over the past year we've been experimenting with teaching Razor side-by-side with XSLT at our level 1 courses where there's usually a 50/50 split of .net devs and front-end devs. With no - 0, zero, nada - exception Razor have been picked up easier than XSLT. In fact when we switched to pure Razor at the last course we had to add extra exercises to make up for the time won.
You can also use the exact same helpers from XSLT that you're used to (in fact about 90% of uComponents helpers work out-of-the-box) in addition to the increasing number of helpers made by the fastly growing razor community.
So take a deep breath. Then give it a shot when you feel ready - you won't have success if you by default believe that Razor is the spawn of viewstate satan. When you've done that, I'm quite certain that you'll see that it isn't that evil and it'll remind you more of js/jQuery than c#.
Thanks for the reply.
Yes I have a slight stubborness. Oh well. I am actually really excited to start some Razor training.
From what I understand, it is very powerful and pretty cool to use.
Are the videos going to be free anytime soon? It says in the post that they will be. I tried earlier today and the subscription message.
XSLT was a kind of easy yet a bit of a pain to use, sometimes. If it is like js/jQuery as you state than that would be great. From the demo vids, it looks like you stub out the calls.
Is there a intellisense tool for Razor out there for VS, Coda, or Textmate? Or even built into Umbraco would be a definite bonus. I would donate for that.
That is what I kind of wished there was for XSLT.
Thanks guys, keep up the good work. Look forward to the future of the Umbraco CMS.
In regards to the free Razor videos, yes they are currently free and in full length. To remove the message from the video simply login to your umbraco.com account for it to be removed a TV subscriptions is not needed to remove the banner for the FREE videos.
As paid for videos has the banner message and is limited to the first 2minutes of the video before it stops.
However Umbraco.TV is so reasonably priced that if your looking to get some more knowledge it is worth thinking about subscribing to.
"The spawn of viewstate satan". Well put, Niels! :)
Razor may not require Visual Studio, but as you imply, it is based on a "hidden" data model, and thus requires contextual help and IDE support, at least the way it is used in Umbraco.
I would enthusiastically support a TextMate bundle or a Coda plugin, but neither will help me much in Vim. And that's the point. Build all the plugins you want, but you will never support everyone's preferred development environment. And so the platform ends up dictating the text editor.
Right now, I have my XML, which is plain text, and my XSLT, which is plain text, and I can stick them in any text editor I want. I don't have to be wired into a full .NET stack to do anything productive. And for the love of all that is sacred, don't ask me to spend eight hours a day writing code in a textarea on a webpage. I doubt that is how the Umbraco core is developed.
And my love for XSLT has nothing to do with angle brackets. I find XSLT just as verbose as everyone else, but I also find it to be a (potentially) very elegant way to write non-linear, non-procedural data transformations.
Maybe you're right and 95% of XSLT transformations in Umbraco projects are choking a declarative programming language in misapplied imperative for-each statements. But if the remaining 5% are building pure awesomeness on your platform, is it fair to take that option away from them? ;)
I get it, Razor is a programming model and a syntax that is more familiar to .NET developers. Fair enough. But if I were to trade in XSLT for anything, it'd be the ability to wield greater power and build cooler things, not simply for familiarity or prettiness or ease of adoption.
Both languages have their place, and both languages clearly have their devotees and their target audiences. And that's why we were all happy to be told at this year's Codegarden that Razor and XSLT would be equal citizens in Umbraco 5. So forgive me my disappointment.
@Dan: You can't make everyone happy. But if sacrificing 5% in order to ensure that the 95% others (*including* most web devs) make better solutions, it's by far the best choice.
It's not that Razor is a programming model that's more familiar to .NET devs. It's that XSLT - based on interviews, training and the recent survey - is familiar to pretty much none.
It's fair to be disapointed - but I'm convinced that it's better long term to dare to change ones mind as it becomes clear that something you believed no longer make sense, than to be scared that a minority will run away because you want to keep a promise for the sake of doing so.
@Warren: Maybe we should do something about that message for the free videos then and tell that it's more subtle if you login. It *is* quite annoying ;)
I personally think change is a good thing and is to be embraced.
My experience with XSLT goes way back to 2000 on a different CMS at the time that used it for media libraries, and if I'm honest I never quite got my head round it and recursion and all the other quirks.
On the other hand, if Razor had been around at that time, I would probably be a better programmer than I am now :)
All the developers I have spoken to so far have embraced Razor and pretty much stopped using XSLT, so a sensible decision to drop XSLT support as far as I am concerned.
There is no point wasting valuable developer resource supporting 2 competing technologies, when one of them is obviously going to win in the end anyway.
It will make Umbraco V5 stronger and I for one can't wait to see how far we can push it :)
@Niels: Promises should certainly never be kept just for the sake of keeping them.
I just don't agree that XSLT "no longer makes sense", and I hate to see power traded for ease-of-adoption. But if I stand alone with that viewpoint, or if I only stand with 5%, then I will bow to the tyranny of the majority and be run off the reservation.
I just hoped that the two languages could co-exist, as you probably once did too.
In case you missed my tweet before.
XSLT Fans: you will still most likely get XSLT support in v5 based on the Umbraco Contrib project. There are a few people who have been active to make this work already. It might not be ready for 5.0 launch but at some stage it should be. It however will not be officially supported by Umbraco HQ.
@Shannon: That does indeed sound promising.
As I wrote earlier, "I sincerely hope that someone smarter than me can build a solid, unofficial XSLT 'view engine' into Umbraco 5".
Thankfully this community is chock full of people smarter than me ;)
I don't necessarely see Razor as a replacement for XSLT in v5 as the platform was built from scratch and no longer functions around an XML cache. Although I am sure XSLT can be supported it would require a bigger effort to do so while it is no longer a crucial feature, especially when you look at what Razor has to offer.
You won't hear me say that XSLT is not an elegant nor powerful way of writing data transformations but you cannot take away its learning curve and from my experience many (excellent) frontend developers do tend to struggle with it.
Seperation of concerns is exactly what MVC and Razor are contributing to ASP.NET (for example frontend developers are no longer struggling with server-side ASP.NET controls) and even though Razor seems mostly benificial to backend developers it has a very intuitive syntax which should be quickly adapted by frontend developers (be it procedural).
I believe moving to Razor will be full of joy and excitement. I love to learn new things.
@Dan Brendstrup You state, "Razor may not require Visual Studio, but as you imply, it is based on a "hidden" data model, and thus requires contextual help and IDE support".
This really isn't true. In Umbraco @Model is a dynamic type and thus doesn't give you any intellisense. I would actually say it is easier to write Razor script without IDE help than it is XSLT as it's far more concise.
Imagine all you had was notepad and an empty text file. Would you be able to write an XSLT script from scratch? Think of all the includes and declerations you need to add to even get started. Let's compare an XSLT script that outputs a page name to it's Razor equivalent:
See the difference? Now tell me honestly which is simpler? :)
Mmm, guess all those angle-brackets in the XSLT weren't escaped! I guess you'll have to use your imagination - but it requires a lot of XSLT :)
@Diplo: Too bad the XSLT was stripped, but I'm guessing you're referring to the doctype and namespace "boilerplate" that goes along with XSLT files. I agree that it adds to the verbosity, but it is easily autogenerated, either by Umbraco or your preferred text editor. So I don't buy that as an argument against XSLT.
And this is not about syntax. I don't find the Razor-and-HTML mix to be very elegant, but I realize that .NET developers do. Fair deal.
This is about the ability to look at a physical XML file and know exactly what to do to transform it with XSLT. For that, I need to memorize (or look up) a handfuld of commonly used XSLT elements and XPath axes. If I want to use Razor without Intellisense support, I'll need to memorize an evergrowing list of methods (http://umbra.co/RazorCheatSheet), most of which are simply reimplementations of standard XPath.
Once you know position(), last() and the mod operator, you can figure out all you need to know about positions in XPath. In Umbraco's Razor implementation, this is ridiculously reimplemented as IsFirst(), .IsNotFirst(), .IsLast(), .IsNotLast(), .IsPosition(), .IsNotPosition(), .IsModZero(), .IsNotModZero(), .IsEven(), .IsOdd().
Tell me again which is easiest. I'm waiting for .IsNextToLast(), .IsNextToNextToLast() and .IsSomewhereInTheMiddle().
@Dan: The Razor implementation in v4 is indeed very simular to XSLT as you are still working against an XML and I admit we still often write XPath expressions in Razor to do some advanced stuff.
For one, XPath exists as a language of its own (even though it was designed for XSLT to begin with) and it has been long supported by many other programming languages (besides .NET) as it provides an powerful way of making advanced queries over XML trees. Razor in v4 basically provides an abstraction which hides the XPath implementation, making it much easier for developers that are familiar with LINQ expressions or method chaining (for example JQuery) to get started with data manipulation without having to learn XSLT.
Secondly, the Razor features in v5 will become much more powerful as the engine behind it (MVC) is actually designed for it (rather than the v4 implementation which does a great job in providing Razor, but basically is not a standard feature of web forms)
@Lennart: Point taken. I imagine the Razor methods in v5 will be considerably less XPathy (and therefore probably not backwards compatible with the current implementation).
And yes, this whole thing is an exercise in tailoring the CMS to LINQ'ers rather than HTML'ers, and moving towards proprietary, "enterprise-ready" technologies rather than open W3C standards. Fair choice to make, I just think it's a shame.
Regardless if Razor is the new black and XSLT a now demoted-to-dinosaur status tech or not...
FWIW and IMHO...
Umbraco to me has always been about an available and stable multitude in choice between technologies - ie. It has so far been up to me to choose between XSLT, XSLT Extensions, C#, Python or Razor in a manner best suited for each serverside subtask, display granule generation or integration subtask. Now my primary choice is overnight declared obsolete more or less without warning and I find myself grasping for easy ways to explain to people around me that suddenly Jupiter will not be on their roadmap because we used XSLT to large extents (because this was common practice) and eg. Razor (because we could choose on a task to task basis what seemed "best")
As much as I understand the reasoning, and accept the reality of it (since Jupiter must rock stably on all levels from the first moment it is released) I cannot but lament the fact that suddenly (at least unless someones builds an Umbraco compatible XSLT engine plugin outside of the HQ) my (and my clients) choices has suddenly narrowed overnight.
You'll see me advocating Jupiter as well of course (unless heavens forbid it turns out badly in the end) and ai still wave the #h5yr flag for the core team for giving us the Jupiter tech transition.
I just can't get over the feeling of having been played for trusting the "no worries we'll give you both" message I guess - mainly because of the way the desicion was communicated tome - but FWIW I will eventually unless the "people don't use XSLT cause it sucks" argument keeps being waved around in the community more than it has to...
Best of luck to us all when we handle this (at least for some of us with an XSLT investment in place one way or another) painful transition - let's elevate the community around u5 in a respectful way and set an even better example of how a community can be friendly in action as well as in words :)
Like I Said: IMHO and FWIW.
@Jarvklo: Amen to that. "Narrowing the choices overnight" hits the nail on the head.
It's not that I hate Razor. It's that I love XSLT. And I don't like XSLT because I like Umbraco; I like Umbraco because I like XSLT.
@Dan: Luckily there's plenty of CMSes out there that still embraces XSLT, if that was what made you like Umbraco.
@Jarvklo: A message will always be over night if you measure time from the day before the message was given to the day it was received.
Reality here is that we were open about the choice within a week after it was clear that it was the best choice for the project.
It's doesn't disappear over night. In what you know and have been able to use so far - Umbraco 4 - it stays. In the future Umbraco version - which still *isn't* released - we told the eco-system about this even before hitting the beta stage. It would have been over night if we pulled it on the release day.
So XSLT is gone. Even with a 3rd party community add-in it'll never be a first-class citizen nor the optimized experience you're used to. Move on.
Finally, you can't blame us from how some in the community choose to bash Razor. Anyone who were at the UK festival, knows that I communicated this message with pretty much the same arguments as above; honest, well-reasoned and balanced.
What more do you really expect (a part from supporting a legacy for the sake of supporting legacy)?
@Niels i won't move on. I'll stay with Umbraco whenever appropriate for the job at hand (read my piece again!) :P
Also I fail to see any blaming you in my personal reflection? What part of the #h5yr and my intention to keep advocating Jupiter even after this news was unclear ?
I reached out to the parts of the community that started throwing code at each others in this thread and judging other peoples choice AFAIK since *that* to me seems pretty pointless (calm down and read it again - you'll see :P )
@Jarvklo: Didn't meant 'move on' as go away - just that the conversation was going round in circles in regards to hopes of XSLT support, so time could be spend on more constructive things to discuss (again aimed more broad than just a reply to you!).
Great idea! XSLT was really the part about Umbraco that I liked the least, so I'm glad to see it go and the resources being spent in a better way. It was way too verbose and complicated, anyway.
I have already switched exclusively to Razor, so I won't miss XSLT.
So is there an equivalent of the umbraco.config file in v5 or is that gone too?
XSLT was the one and only thing in Umbraco I've always hated. It always felt like a square peg in a round hole, having to escape escape sequences. Good riddance to it.
I wish you could release 4.7.2 at this month.
You comment is being submitted... please wait...
Your comment has been posted on umbraco in reply to: Saying goodbye to an old friend
Something horrible happened. and your comment could not be posted. Please ensure that all fields have correct values, and that yourEmail address is valid.
Get started with the the friendliest CMS on the planet Download Umbraco