Saying goodbye to an old friend

Thursday, November 10, 2011 by Niels Hartvig

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:

  1. 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
  2. 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.
  3. 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
  4. 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.
  5. 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!

46 comment(s) for “Saying goodbye to an old friend”

  1. Gravatar ImageOve Andersen Says:

    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

  2. Gravatar Imagekipusoep Says:

    Great decision!

  3. Gravatar ImagePeter NIelsen Says:

    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? :)

  4. Gravatar ImageRasmus Fjord Says:

    Thumbs up :)

    Already loving razor cant wait to see what is in store for v5 :)

  5. Gravatar ImageSøren Reinke Says:

    I will not miss XSLT.

    Razor for the win.

  6. Gravatar ImageSøren Spelling Lund Says:

    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.

  7. Gravatar ImageDavid Conlisk Says:

    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!


  8. Gravatar ImageMuhammad Awais Says:

    Great Decision of moving to Razor..

  9. Gravatar ImageAndrei Canef Says:

    Yet one more thing that makes me really look forward to getting to use Umbraco 5 in production environments. :)

  10. Gravatar ImagePatrik Says:

    Good work, i can manage without XSLT!

  11. Gravatar ImageLee Kelleher Says:

    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.

    Fortunately the majority of the developers I know in the "Rebel Alliance" aren't one-trick ponies, and are well versed in other C-derived languages - whether that is C#, JavaScript or even PHP. I'd see no problems in them picking up Razor syntax.

    Looking forwards, very excited about Umbraco v5 - can't wait for the beta!

    Cheers, Lee.

  12. Gravatar ImageOve Andersen Says:

    @Lee Kelleher
    Hear, hear.
    I couldn't possibly agree more.

  13. Gravatar ImageLennart Stoop Says:

    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.


  14. Gravatar ImageDan Brendstrup Says:

    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.

  15. Gravatar ImageDan Brendstrup Says:

    ...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 ;-)

  16. Gravatar Imagelee li Says:

    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 mvc as soon as possible.

  17. Gravatar ImageCarlos Says:

    When are you making the videos free? I am still getting the example text and Register button at the top of the videos

  18. Gravatar ImageCarlos Says:

    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.

  19. Gravatar ImageHartvig Says:

    @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#.

  20. Gravatar ImageCarlos Says:

    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.

  21. Gravatar ImageWarren Buckley Says:


    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 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.

    Warren :)

  22. Gravatar ImageDan Brendstrup Says:

    "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.

  23. Gravatar ImageHartvig Says:

    @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.

  24. Gravatar ImageHartvig Says:

    @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 ;)

  25. Gravatar ImageAdam Shallcross Says:

    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 :)


  26. Gravatar ImageDan Brendstrup Says:

    @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.

  27. Gravatar ImageShannon Deminick Says:

    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.

  28. Gravatar ImageDan Brendstrup Says:

    @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 ;)

  29. Gravatar ImageLennart Stoop Says:


    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).

  30. Gravatar ImageIndrakumar Says:

    I believe moving to Razor will be full of joy and excitement. I love to learn new things.

  31. Gravatar ImageDan Diplo Says:

    @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? :)

  32. Gravatar ImageDan Diplo Says:

    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 :)

  33. Gravatar ImageDan Brendstrup Says:

    @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 (, 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().

  34. Gravatar ImageLennart Stoop Says:

    @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)

  35. Gravatar ImageDan Brendstrup Says:

    @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.

  36. Gravatar ImageJarvklo Says:

    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.

  37. Gravatar ImageDan Brendstrup Says:

    @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.

  38. Gravatar ImageNiels Hartvig Says:

    @Dan: Luckily there's plenty of CMSes out there that still embraces XSLT, if that was what made you like Umbraco.

  39. Gravatar ImageNiels Hartvig Says:

    @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)?

  40. Gravatar ImageJarvklo Says:

    @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 )

  41. Gravatar ImageNiels Hartvig Says:

    @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!).

    Peace :-)

  42. Gravatar ImageJarvklo Says:

    @Niels :-)

  43. Gravatar ImageAsbjørn Says:

    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.

  44. Gravatar ImagePat Says:

    So is there an equivalent of the umbraco.config file in v5 or is that gone too?

  45. Gravatar ImageJon Webb Says:

    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.

  46. Gravatar Imageesunxray Says:

    I wish you could release 4.7.2 at this month.

Leave a comment