This is part 1 of the Series The Future of DNN Speaks Razor. In this post I'll explain why you have to migrate now.
You have to migrate to Razor now, because…
- …Microsoft is officially phasing out ASP.net WebForms and WebControls
…this is forcing DNN to also migrate towards Razor (see the Roadmap)
- ...this means cshtml! and cshtml means Razor.
- …so if you develop something that should still work in the near future, you have to learn Razor now!
You may believe that DNN will provide backward compatibility - and they might. But I hope they won't. Any system as mature as DNN also has loads of bad features that it picked up along the way - for example widgets - which are very expensive because they cause bugs, have to be supported, but are barely used at all. So here is an opportunity to say "We have very new stuff, and it's so different, that when you use it, you also have to adhere to modern standards". I hope they will do this - and the label "platform trimming" might just include this.
So: Yes, you have to learn Razor. ASAP. No kidding.
What Will be Developed in Razor?
- Menu-templates - this is already possible today with the DDR-Menu
- Skins - once DNN fully supports Razor, you will be able to write Razor skins
- Skin helpers - like tags which insert/handle a language changer - this can already be done today similar to how the DDR-Menu does it
- Module Output - I'm guessing that only Razor-style modules will work within a Razor skin since supporting WebControls inside a Razor would require an architecture defeating Razors advantages, and because it's a great opportunity to clean up.
- Admin-UIs for configuring your modules - will probably be Razor + WebAPI + AngularJS (my recommendation)
- Edit-UIs for entering data - also probably Razor + WebAPI + AngularJS (my recommendation)
- Customizable output templates which the web designer can adapt
This must be a joke, right?
Nope, this is serious. We (2sic) moved almost all our DNN-programming (except for skinning) to Razor about 2 years ago - and it's a huge blessing! Imagine things like:
- Module installs and updates which don't require DLLs, so no Server restarts…
- …and no risk that DNN will stop working. The template might fail, but not DNN
- If you had installed a third-party gallery and the customer needs this trivial change…you're usually forced to do loads of work including buying the module in source-edition, figuring out what approach that person used, extend the module, compile, install - and loose upgrade-compatibility…since we've moved to Razor-based Apps, this cycle is reduced to almost nothing.
- Since Razor is output-focused, we can easily create an alternate output-template for each portal (assuming your module supports this - which it will have to)
- The code is much cleaner, because Razor forces you to separate your concerns a bit more.
- The code is easy to read - and usually complete (not part of it hidden in a code-behind just because the programmer didn't know data-binding)
Here an example so you see how easy it is to read Razor-Code:
My Next Razor Posts
So Each of the Following Days, I'll release another post for this topic. This will be covered:
- You Have to Migrate Now! (this post)
- Just What is Razor?
- The Death of ASP.net WebForms
- The Death of ASP.net MVC
- ASP.net WebAPI is great for Apps…but not for Content
- Which technology to use for which part of the solution
- Getting started with Razor…
With love from Switzerland
PS: Want to get started before the entire Razor-series is out? For the impatient, try the DNN-Razor Host Module and watch this video or try packaged code apps by installing 2sxc and some of the Razor Apps like the Razor Basic Tutorials, List-Tutorials or the SQL and Peta-Poco Tutorials.