Might be throwing in a curve ball here....Thoughts on the way forward for Umbraco
I have been thinking a little bit about what makes Umbraco great since it was announced that Umbraco 5 would be discontinued. I still think this can be summed up in much the way the core team has traditionally marketed its product...ie.
Umbraco is great for
Site Owners (content owners) Designers Developers
I am someone who has worked (and continues to work) on a good sized Umbraco project which originally involved a design agency and was delivered to the in-house IT team. We have a strong design and development background with all off us benefitting from cross discipline knowledge of web techniques old and new.
My experiences with our content owners has been a revelation since we launched our Umbraco site. They embraced the product quickly and really quite enjoy using it. They complain about Courier and Contour more than the core product! Once we made the commitment to upgrade our site from 4.0 to 4.7 we actually rolled back to Courier 1.3 after experiencing too many issues with Courier 2. Unfortunately I had to tweak the Umbraco core slightly to get Courier 1.3 working in Umbraco 4.7. My only real cristicism of the core (backoffice) UI is that it desperately needs and draggable divider between the left and right panes and the content/media tree views need drag and drop functionality. I've seen many requests for these UI functions but nothings ever materialised.
As a designer/developer I personally already had a lot of experience of XSLT/XML prior to Umbraco and was very impressed at Umbraco's ability to work on it's XML cache with incredible speed. I've also read many a report of this continuing with web sites far bigger than our own. From a designer/developer perspective i've at times found XSLT cumbersome due to it's limitations, but it's very easy to learn and it's implementation in Umbraco is simple and quite superb. Crucially I think XSLT's strength is that it's very easy to read by people familiar with HTML (web designers and developers alike) and this is down to XML/HTML/XSLT all sharing the same mark-up heritage.
So when it comes to choosing the right development direction for Umbraco history dictates that MVC/Razor was heralded as the "answer" especially in view of Microsofts neglect?!? But the fact remains we have a product that works (extremely well) on a technology that most of its userbase is comfortable with (part of which makes Umbraco great!)
Fast forward to today and we now have the team admitting it had made a mistake, v4 lives again hurrah! (with its XSLT/XL engine) but Razor very much tacked on....remember it was added with the intention of providing an upgrade path to v5! Woops!
This is where I chip in my 10 pence worth....
Long live XML and long live XSLT! It's convenient, fast, flexible and very well supported (in third party packages too).
Why doesnt the core team approach Microsoft with the intention of obtaining and on-developing the .net XSLT/XPath codebase? The benefits for both sides here are obvious... The Umbraco core team can continue Umbracos superior use of this wonderful technology whilst passing back the benefits to Microsoft for use in the .net framework? This means W3 recommendations can continue to feature in .net!
That doesnt mean of course that MVC and razor support should stop, but instead complement v4 going forward, particularly for those developers who want to hit the APIs much harder.
- Last year we experimented with mixing Razor and XSLT exercises at the courses. It was clear that people new to Umbraco found Razor easier than XSLT (and most people on Level 1 are web designers or web devs - not .NET devs)
- Microsoft haven't updated the XSLT engine in .NET in eight years and they won't in the future (which basically means that we're still on XSLT 1.0 and most tutorials and books you can find are invalid)
- Maintaining our own XSLT 2.0 engine is a bigger task than Umbraco CMS as a whole. There's no way we can - or want to - take the challenge
- I didn't add Razor as an upgrade path to v5, that was just a side effect. I added it because I could see the immediate benefits of a simpler and cleaner scripting engine. With great work from Elijah Glover and Gareth Evans my original work has been dramatically improved the past year.
I flicked through the video, 9 minutes in XSLT is discussed suggesting your biggest problem is the fact the MS havent updated XSLT for years and that people on your courses criticised XSLT, stating Razor syntax as "being simpler to write". What I found interesting is that before the comment is made about your course findings there's a resounding clap from the audience when it was announced that XSLT and XML would very much stay in Umbraco!
I agree its a huge problem for you that MS has shelved XSLT, but there are third party implementations (I found three on a quick search). Has there been a community survey anywhere about XSLT vs Razor and XSLT use? Microsoft are just as capable (and do regularly) make bad decisions with regards to technology directions and if the community feels that XSLT is the best use of the technology I think it should continue.
I've read lots of criticism of the speed of Razor in v4 which seems to mirror the criticism of the speed in v5. Regardless of whether its was added as a side effect or demonstration/upgrade path to MVC there's clearly still problems with using Razor in Umbraco.
Another point I'd like to make is that Razor in my view is far more developer centric than XSLT is, an understanding of how best to work with the API to get it to run optimally (fast!) is required and the API seems to have changed a few times too. Generally i've not needed to concern myself with in-depth API knowledge or code optimisation techniques with XSLT. This worries me and it's this simplicity in using XSLT that I think is being missed. This is outlined by a commentor 41 minutes into your video too. ie. XSLT keeps the focus on front end design rather than back end design and Umbraco APIs.
Is Razor also seen as "easier" because it debugs properly? I've always found debugging XSLT in Umbraco to be a pain in the arse, attaching the debugger in Visual Studio can be a hit and miss affair!
Just for the record - we're *not* removing XSLT support in Umbraco v4. We aren't even thinking about it :)
Also, I'm not saying that Razor is the ultimate silverbullet and that we can't improve our implementation. It's just the best of both worlds we've encountered so far.
Here's my comments to your reply:
> there's a resounding clap from the audience when it was announced that XSLT and XML would very much stay in Umbraco People will always applaud when they can work as they used to and use the tools they know and love - nothing new here
> Microsoft are just as capable (and do regularly) make bad decisions with regards to technology directions Agreed - but whether we like it or not, we're based on their technology stack!
> but there are third party implementations (I found three on a quick search) Can you post link to them. Those I've seen so far - but it's been two years since I last looked around - were either not open source (or not MIT license compatible), based on un-safe calls to COM-objects or only proof of concepts so far. I'd *love* to be wrong on this one, though!
> I've read lots of criticism of the speed of Razor in v4 which seems to mirror the criticism of the speed in v5 The speed issues in Razor is a combo of performance enhancements we can - and will - do and 'wrong' usage of razor queries (just like when people do // in xpath). Razor runs off the same XML cache as our XSLT implementation and as such shouldn't in any way be compared to the issues of v5
> Another point I'd like to make is that Razor in my view is far more developer centric than XSLT is, > an understanding of how best to work with the API to get it to run optimally (fast!) is required and the API seems to have changed a few times too The API have been changed to make it easier and faster to work with. Unlike XSLT, our Razor implementation isn't a set 'standard' from a 3rd party library, but one we can optimize to be easier and faster to use. In the long run this will definitely give us (as in people who implement Umbraco sites) a lot of benefits, but obviously also mean that it'll take some iterations before we get it completely right
> XSLT keeps the focus on front end design rather than back end design and Umbraco APIs I think this is a common misunderstanding which we've definitely seen proved wrong in the courses. Clean Razor is more readable than clean XSLT. Just because you wrap syntax as markup, doesn't mean you don't "code". And XSLT is a functional programming language which is very hard to master (though wonderful when you do!).
> Is Razor also seen as "easier" because it debugs properly? In the level 1 course we don't even use Visual Studio, so the "easier" is solely based on implementing a simple site (navigation, sitemaps, news, faq, multi-language, etc)
Might be throwing in a curve ball here....Thoughts on the way forward for Umbraco
I have been thinking a little bit about what makes Umbraco great since it was announced that Umbraco 5 would be discontinued. I still think this can be summed up in much the way the core team has traditionally marketed its product...ie.
Umbraco is great for
Site Owners (content owners)
Designers
Developers
I am someone who has worked (and continues to work) on a good sized Umbraco project which originally involved a design agency and was delivered to the in-house IT team. We have a strong design and development background with all off us benefitting from cross discipline knowledge of web techniques old and new.
My experiences with our content owners has been a revelation since we launched our Umbraco site. They embraced the product quickly and really quite enjoy using it. They complain about Courier and Contour more than the core product! Once we made the commitment to upgrade our site from 4.0 to 4.7 we actually rolled back to Courier 1.3 after experiencing too many issues with Courier 2. Unfortunately I had to tweak the Umbraco core slightly to get Courier 1.3 working in Umbraco 4.7. My only real cristicism of the core (backoffice) UI is that it desperately needs and draggable divider between the left and right panes and the content/media tree views need drag and drop functionality. I've seen many requests for these UI functions but nothings ever materialised.
As a designer/developer I personally already had a lot of experience of XSLT/XML prior to Umbraco and was very impressed at Umbraco's ability to work on it's XML cache with incredible speed. I've also read many a report of this continuing with web sites far bigger than our own. From a designer/developer perspective i've at times found XSLT cumbersome due to it's limitations, but it's very easy to learn and it's implementation in Umbraco is simple and quite superb. Crucially I think XSLT's strength is that it's very easy to read by people familiar with HTML (web designers and developers alike) and this is down to XML/HTML/XSLT all sharing the same mark-up heritage.
So when it comes to choosing the right development direction for Umbraco history dictates that MVC/Razor was heralded as the "answer" especially in view of Microsofts neglect?!? But the fact remains we have a product that works (extremely well) on a technology that most of its userbase is comfortable with (part of which makes Umbraco great!)
Fast forward to today and we now have the team admitting it had made a mistake, v4 lives again hurrah! (with its XSLT/XL engine) but Razor very much tacked on....remember it was added with the intention of providing an upgrade path to v5! Woops!
This is where I chip in my 10 pence worth....
Long live XML and long live XSLT! It's convenient, fast, flexible and very well supported (in third party packages too).
Why doesnt the core team approach Microsoft with the intention of obtaining and on-developing the .net XSLT/XPath codebase? The benefits for both sides here are obvious... The Umbraco core team can continue Umbracos superior use of this wonderful technology whilst passing back the benefits to Microsoft for use in the .net framework? This means W3 recommendations can continue to feature in .net!
That doesnt mean of course that MVC and razor support should stop, but instead complement v4 going forward, particularly for those developers who want to hit the APIs much harder.
Comments and opinions much appreciated!
Hi Martin!
In the panel debate at CG12 on why we stopped the dev of v5, the topic was raised (video here: http://stream.umbraco.org/video/6425174/panel-why-did-we-decide-to) and basically here's some good reasons on Razor vs XSLT:
- Last year we experimented with mixing Razor and XSLT exercises at the courses. It was clear that people new to Umbraco found Razor easier than XSLT (and most people on Level 1 are web designers or web devs - not .NET devs)
- Microsoft haven't updated the XSLT engine in .NET in eight years and they won't in the future (which basically means that we're still on XSLT 1.0 and most tutorials and books you can find are invalid)
- Maintaining our own XSLT 2.0 engine is a bigger task than Umbraco CMS as a whole. There's no way we can - or want to - take the challenge
- I didn't add Razor as an upgrade path to v5, that was just a side effect. I added it because I could see the immediate benefits of a simpler and cleaner scripting engine. With great work from Elijah Glover and Gareth Evans my original work has been dramatically improved the past year.
Hope this helps - keep the input coming!
Hi Niels
I flicked through the video, 9 minutes in XSLT is discussed suggesting your biggest problem is the fact the MS havent updated XSLT for years and that people on your courses criticised XSLT, stating Razor syntax as "being simpler to write". What I found interesting is that before the comment is made about your course findings there's a resounding clap from the audience when it was announced that XSLT and XML would very much stay in Umbraco!
I agree its a huge problem for you that MS has shelved XSLT, but there are third party implementations (I found three on a quick search). Has there been a community survey anywhere about XSLT vs Razor and XSLT use? Microsoft are just as capable (and do regularly) make bad decisions with regards to technology directions and if the community feels that XSLT is the best use of the technology I think it should continue.
I've read lots of criticism of the speed of Razor in v4 which seems to mirror the criticism of the speed in v5. Regardless of whether its was added as a side effect or demonstration/upgrade path to MVC there's clearly still problems with using Razor in Umbraco.
Another point I'd like to make is that Razor in my view is far more developer centric than XSLT is, an understanding of how best to work with the API to get it to run optimally (fast!) is required and the API seems to have changed a few times too. Generally i've not needed to concern myself with in-depth API knowledge or code optimisation techniques with XSLT. This worries me and it's this simplicity in using XSLT that I think is being missed. This is outlined by a commentor 41 minutes into your video too. ie. XSLT keeps the focus on front end design rather than back end design and Umbraco APIs.
Is Razor also seen as "easier" because it debugs properly? I've always found debugging XSLT in Umbraco to be a pain in the arse, attaching the debugger in Visual Studio can be a hit and miss affair!
M.
Just for the record - we're *not* removing XSLT support in Umbraco v4. We aren't even thinking about it :)
Also, I'm not saying that Razor is the ultimate silverbullet and that we can't improve our implementation. It's just the best of both worlds we've encountered so far.
Here's my comments to your reply:
> there's a resounding clap from the audience when it was announced that XSLT and XML would very much stay in Umbraco
People will always applaud when they can work as they used to and use the tools they know and love - nothing new here
> Microsoft are just as capable (and do regularly) make bad decisions with regards to technology directions
Agreed - but whether we like it or not, we're based on their technology stack!
> but there are third party implementations (I found three on a quick search)
Can you post link to them. Those I've seen so far - but it's been two years since I last looked around - were either not open source (or not MIT license compatible), based on un-safe calls to COM-objects or only proof of concepts so far. I'd *love* to be wrong on this one, though!
> I've read lots of criticism of the speed of Razor in v4 which seems to mirror the criticism of the speed in v5
The speed issues in Razor is a combo of performance enhancements we can - and will - do and 'wrong' usage of razor queries (just like when people do // in xpath). Razor runs off the same XML cache as our XSLT implementation and as such shouldn't in any way be compared to the issues of v5
> Another point I'd like to make is that Razor in my view is far more developer centric than XSLT is,
> an understanding of how best to work with the API to get it to run optimally (fast!) is required and the API seems to have changed a few times too
The API have been changed to make it easier and faster to work with. Unlike XSLT, our Razor implementation isn't a set 'standard' from a 3rd party library, but one we can optimize to be easier and faster to use. In the long run this will definitely give us (as in people who implement Umbraco sites) a lot of benefits, but obviously also mean that it'll take some iterations before we get it completely right
> XSLT keeps the focus on front end design rather than back end design and Umbraco APIs
I think this is a common misunderstanding which we've definitely seen proved wrong in the courses. Clean Razor is more readable than clean XSLT. Just because you wrap syntax as markup, doesn't mean you don't "code". And XSLT is a functional programming language which is very hard to master (though wonderful when you do!).
> Is Razor also seen as "easier" because it debugs properly?
In the level 1 course we don't even use Visual Studio, so the "easier" is solely based on implementing a simple site (navigation, sitemaps, news, faq, multi-language, etc)
Hi Niels
All strong arguments! lol
The only open source stack left is http://saxon.sourceforge.net/ but they offer commercial versions as well.
is working on a reply...