As many of you know already, Blazor is new web framework for .NET Core that lets you build interactive web UIs using C# instead of JavaScript. Over the past year there has been tremendous excitement in the Microsoft developer community about this new technology, and a few weeks ago Microsoft finally made the long awaited announcement that Blazor is no longer an experimental project and that they are committing to ship it as a supported web UI framework. 

 

Oqtane was originally conceived as a proof of concept to determine if Blazor would be capable of supporting a modular application framework. Taking inspiration from DotNetNuke, it utilizes many concepts from this pionering open source .NET CMS. Specifically it supports multi-tenancy, a fully dynamic page compositing model, designer friendly skins, extensibility via third party modules, and a familiar data model. That being said this was not a migration project; Oqtane was built from the ground up using modern .NET Core patterns and technology.

In many ways Oqtane is a testament to the flexibility of Blazor, as it deviates significantly from the "standard" Blazor development model. The whole premise of a modular framework is that everything must behave in a dynamic manner and the default Blazor development model focuses on a more traditional static model. As a result many intrinsic Blazor behaviors had to be overridden. For example, Oqtane uses a custom router rather than the default Blazor router. The custom router is simply a component which handles user interaction in the browser and renders components dynamically based on type names. It takes advantage of cascading parameters to facilitate interaction between hierarchical components and ultimately provide a highly responsive Single Page Application (SPA) user experience. 

Although heavily inspired by DotNetNuke, Oqtane takes a very different approach in a variety of areas which are relevant to module developers. One main difference in particular is that Oqtane relies on code-first configuration and convention rather than relying on a database and various external resource files. In Oqtane, module requirements are encoded in the module DLL itself and as a result there is no requirement to formally install or register the module in a database. This separation of concerns makes the module development experience much faster and more intuitive. 

A fundamental goal which was set when developing Oqtane was that the framework should be functional in both client-side Blazor and server-side Blazor configurations. This was fairly simple to accomplish with earlier versions of Blazor. However in recent versions it became a bit more complicated but Oqtane was still able to satisfy this goal in a single code case by using conditional compilation. If a developer wants to develop using server-side Blazor ( which includes a full debugging experience in Visual Studio ) they can choose to Build the solution using the default Debug configuration. Or if they want to develop using client-side Blazor ( WebAssembly ) they can choose the "Wasm" configuration option in the Visual Studio toolbar and then Build the solution.

It is fair to say that I could not have created Oqtane without the assistance and support of the ASP.NET team - specifically Scott Hunter, Dan Roth, Steve Sanderson, and Ryan Nowak. I would also like to thank a long time DNN friend and colleague, Michael Washington, for his perseverance and patience in helping me prepare for the initial release. I also need to extend my gratitude to the broader Blazor community which has already produced so much amazing content and guidance to developers - Chris Sainty and Ed Charbonneau in particular have really helped fuel the demand for Blazor. Lastly I need to express my appreciation to Göran Halvarsson for publishing a blog almost a year ago titled "Time travel into the future – BLAZOR + SITECORE + HELIX" where he provided the only evidence I could find which demonstrated that dynamic component loading and custom routing was possible in Blazor. 

Now that Oqtane has been publicly released, I am hopeful that a vibrant open source community will begin to form around it. A community website will be made available at oqtane.org very soon to enable community participation, visibility, and achievements. 

One final thing I should clarify is that although I still have some involvement with the DNN community, Oqtane is not intended to be the .NET Core implementation of DotNetNuke. DNN has a very active and experienced Technology Advisory Group led by Mitchell Sellers and they are focused on constructing and implementing an official roadmap for the future of DotNetNuke. Whether or not Blazor is part of that picture is a decision that the leadership group still needs to make.