This post reflects my personal opinions and is not an official statement from the DNN Community or the DNN Platform team. 

 

When I speak to other community members, some have concerns about the perceived lack of progress in DNN. Although I don’t agree with that sentiment, I would like to address some of these worries and inform you of a new way to render DNN pages without WebForms, which could be a next step into the future. 

DNN’s Underlying Technology 

DNN has always been based on .NET Framework and WebForms, initially developed in VB and now in C#.  As with every technology, this has advantages and disadvantages. 

A major advantage of WebForms is its stability, especially in contrast to the relatively short and sometimes frustrating support cycles of .NET Core. 

A disadvantage is that WebForms is not viewed as cutting-edge by some developers. 
However, it is important to realise that WebForms offers a lot of functionality that you would have to create yourself in any other technology. 

Some worry that Microsoft support for WebForm will stop, but I’m not convinced support will end anytime soon, as many of their platforms still rely on it, such as office 365. 
Also with the release of Windows 2025, we are again assured of .NET security updates for at least the next 10 years. 

Ever since the Community has control over DNN, a lot has been done to introduce new technologies in DNN. 
 

Recent DNN modernizations 

Examples of this are the MVC module pattern, dependency injection, Web-API and more. 
But the main DNN rendering engine is still based on WebForms. 
It offers a lot of functionality out of the box, at the cost of not having 100% control over the finer details of page rendering. 

 

Take it one step further... 

During an Open Content meeting, Sacha Trauwaen  (the developer of Open Content) shared an intriguing idea. 

Sacha needed full control over the output rendered by DNN to be able to adhere to Content Security Policies for a client. He was unable to achieve that using the current WebForms rendering. 

He created the concept of a secondary DNN rendering Pipeline based on MVC 5 without WebForms. At that time, he showed just the content of an HTML module without a Theme. 
 

I really liked that idea, as it seems like the natural next step for DNN, and this new way of rendering would potentially align more with .NET Core's approach without breaking every existing DNN site. Essentially, it introduces the concept of MVC-based pages rather than just MVC modules. 

 

The MVC Rendering Pipeline: A Proof of Concept 

We created a “playground” to see if, by introducing a secondary DNN MVC Pipeline, a next step can be taken to reduce DNN's dependency on WebForms. 
We discussed this with a small group of DNN friends to determine the best direction with Sacha doing most of the heavy lifting. 

 

Key Concepts of the MVC Pipeline: 

1. A secondary DNN MVC based Pipeline will be available, not using any WebForms to render the page. 

1. There will be no functional changes to either DNN or the Database as that will only lead to scope creep. 

1. You will get the choice to choose either WebForms or the new rendering engine, per page / portal. 

1. All Modules and Extensions used on an “MVC” page, will have to support MVC rendering though. 
    

Supporting Extensions for MVC Rendering: 

No module currently supports this kind of MVC page rendering. 
Even the current MVC pattern Modules will probably need some (minor) work to be able to be used on an MVC page. But obviously this will be a lot easier for modern SPA or MVC modules than for a classic Webforms Module using a ton of Webforms controls. 
Instructions for adding this support to existing Extensions will be published later. 

Sacha did add support to the most used Skin Objects, the HTML Module and Open Content for this proof of concept. 

Why Should the DNN Community Care? 

The primary goals of this initiative include: 

• Cleaner HTML output: Eliminating unnecessary elements such as <form> tags and ViewState. 

• Improved security: Implementing Content Security Policies to achieve an A+ security rating. 

• Faster page load times, improve SEO 

• Deprecating outdated elements: Removing JavaScript Unload Handlers. 

• Simplified Azure firewall configurations for access-restricted websites. 
   

DNN code quality 
Despite the effort involved, this new rendering pipeline was relatively easy to implement—a testament to DNN’s high coding standards and solid architectural foundation. 

Evolution vs Revolution 
The major advantage of this new rendering pipeline is its ability to coexist with the existing WebForms-based approach. This allows users to adopt the new rendering method at their own pace while maintaining support for older modules on other pages. This evolutionary approach ensures a smooth upgrade path without disrupting existing DNN solutions. 

While radical changes might sound exciting, they often come with unintended consequences. For a community as large as DNN’s, gradual evolution is the most practical and sustainable path forward. 

Current status 

This proof of concept is currently mainly developed by Sacha Trauwaen. 
Peter Donker already spent considerable time reviewing the code and he and Sacha are working on an installable proof of concept for the DNN Connect 2025 conference. 

 

Stay Updated 

• Follow development progress in the temporary repository: GitHub Repository 

• Attend the upcoming DNN Connect Conference in Spain, where this topic (and much more) will be a key discussion point. You can register here: https://dnn-connect.org/registration 

 
This initiative represents an exciting step in DNN’s evolution, balancing innovation with continuity. Your feedback and support are crucial in shaping its future—let’s build the next chapter of DNN together! 

Timo