The Community Blog is a personal opinion of community members and by no means the official standpoint of DNN Corp or DNN Platform. This is a place to express personal thoughts about DNNPlatform, the community and its ecosystem. Do you have useful information that you would like to share with the DNN Community in a featured article or blog? If so, please contact [email protected].

The Future of DNN Speaks Razor - #1 You have to migrate now!

If you're an old-school DNN developer you're used to using ASP.net Forms - and you've developed tricks and techniques to compensate for various issues like clean SEO-HTML, JavaScript-Control-IDs and more. You've also implemented 3rd party controls (like a Telerik Grid) and spent hours of your time trying to compensate for certain shortcomings. Well, it turns out that this is not necessary any more - but most DNN-dudes don't realize this yet. Because the future is in absolute HTML control - using Razor. Let me tell you why, and how to get started.

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…

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

What Will be Developed in Razor?

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.

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:

Daniel Mettler grew up in the jungles of Indonesia and is founder and CEO of 2sic internet solutions in Switzerland and Liechtenstein, an 20-head web specialist with over 600 DNN projects since 1999. He is also chief architect of 2sxc (2SexyContent - see forge), an open source module for creating attractive content and DNN Apps.

Comments

Bang On Daniel - @Razor is awesome - but then I am somewhat biased. We added support for Razor in "WebForms" a couple of years ago and with Razor the primary View-Engine in MVC if you can do Razor now (together with jQuery and Web API) then you are all set for the future.

"Microsoft is officially phasing out ASP.net WebForms and WebControls"? AFAIK, WebForms is going to be around for years to come. Do you have an authoritative Microsoft link which supports this claim? (This post does not imply I am in support of WebForms).

It's not quite correct to state that webforms are dead, MS will continue to support and invest in it for years to come, but they've stated a number of times that webforms are "done" (announced a number of times during the MVP summit to asp.net MVP's). If you look at asp.net vnext (http://www.asp.net/vnext), you can see that they're focussing on MVC, Razor, WebAPI and OWIN (http://developer.telerik.com/featured/microsofts-special-k-an-introduction-to-asp-net-vnext/). As such we should not expect any large asp.net webforms changes, all new innovation will be on the new vnext areas, so it's pragmatic for us to look at and invest in those areas.

@Tony: I guess it boils down to the meaning of dead.From where I stand in the web industry, dead means that the creator doesn't invest much into enhancing it at industry speed. The web-speed being amazingly fast - based on this, WebForms has been dead for a good 4-5 years already. The main improvements that happened in the last versions are some performance aspects and some trivial stuff (like ClientID control) - and that's actually just about it. And yes, WebForms as a technology will still work in 2025. I'm sad to say that I sometimes run into projects that just went live - running on classic ASP which is dead since 2000. As being official - if you are looking for a writing from MS stating exactly that you won't find it. MS has learned that such statements cause a lot of unintended damage and insecurity (for example: they recently declared InfoPath dead without offering a clear replacement, and that has cause loads of trouble in the SharePoint world). But Microsoft does officially say what they are focusing on. It's a bit much to write here - but in summary: WebForms doesn't appear. When a clearly structured system whose communication is filtered through marketing doesn't mention the currently most prominent offering - that's as official as it will ever get.

One more note - http://www.asp.net/vnext shows a bit of what's next and this (unfortunately 1 hour long video) also shows a lot of the vision: http://channel9.msdn.com/Events/TechEd/NorthAmerica/2014/DEV-B385#fbid=

Webforms is dead the same way that Cobol is dead. Yes there are still piles and piles of applications written and maintained in Cobol, but few companies willingly invest in doing any further development in Cobol. From a technology perspective, DNN has to be looking to the future and not to the past. Staying on Webforms will ensure that DNN gathers a larger and larger share of a smaller and smaller pool of developers. Not a great way to grow a platform or a community. Better for us to start the transition to a technology which still has another 5-10 years of life before the next big shift occurs.

Content Layout

Subscribe to DNN Digest

Subscribe to DNN Digest

DNN Digest is our monthly email newsletter. It highlights news and content from around the DNN ecosystem, such as new modules and themes, messages from leadership, blog posts and notable tweets. Keep your finger on the pulse of the ecosystem by subscribing.