Most frameworks are created with a core philosophy in mind. A core philosophy provides a central theme for all major product decisions. The core philosophy behind DNN was extensibility, and as a result almost every core feature was developed in a manner which could be enhanced, extended or overridden. The core philosophy for Oqtane also includes extensibility but places a much greater emphasis on performance, which is highlighted by the Oqtane brand name whose root word "octane" is a standard measure of the performance of engine fuel. Performance is a very general attribute and for a framework like Oqtane it needs to encompass a wide variety of characteristics such as the speed of installation, familiarization, development, deployment, and interaction with the product.
In order to be actionable, a high level philosophy must be broken down into concrete principles in order to provide the lower level guidance for managing the product. Utilizing the wisdom obtained from the real world experience of guiding the DNN framework for over a decade, the goal was to retain the most successful principles from DNN but also introduce some new principles which align with the performance theme and provide a solid foundation for the new open source project. This blog will focus on these principles, as they are the most relevant aspects of the Oqtane product philosophy.
From its inception, .NET Core has always benefited from a very strong emphasis on performance. In fact based on widely accepted benchmarks it is considered to be one of the fastest web frameworks available today. The Blazor component model is based on a single page application model which optimizes how the user interface is rendered in the browser to produce a highly responsive experience. Oqtane takes advantage of all of these high performance technologies to offer a high performance modular application framework.
One of the benefits of the Blazor component model is that it is adaptable to a variety of different run-time scenarios. Currently it supports a server-side model via SignalR as well as a client-side model via WebAssembly. However, there have already been demonstrations of future options including desktop apps via Electron or a native shell, progressive web applications (PWA), and native mobile apps via Xamarin. The goal for Oqtane is to support all of these run-time scenarios. In order to accomplish this, Oqtane is built with a clearly defined client/server architecture. This architecture provides the flexibility to adapt to a variety of run-time configurations.
Although Visual Studio provides a powerful set of functionality for software development, it can sometimes be overkill for solving specific problems and is not always available or accessible to all software developers. As a result Oqtane should not rely upon or take advantage of any specific features in Visual Studio. It should be possible for developers to be productive on Oqtane using other development tools such as VS Code, JetBrains Rider, etc...
In this context "ceremony" refers to the knowledge and procedures required in order for a developer to come up to speed and work with a framework. Obviously, the goal is to keep the amount of ceremony to a minimum so that developers can be on-boarded quickly and can be highly productive. This area has traditionally been a weakness for DNN when developing modules due to the fact that there are a variety of manual steps required in order to integrate a module with the framework and make it functional. This was one of the focus areas in Oqtane. For example, a developer can simply create a razor file in the /Modules folder within the Oqtane solution, hit F5, and framework is immediately aware of the module without requiring any manual registration steps.
One of the core capabilities in a modular application framework is the ability to create custom modules. The ability to create and package modules independently from the framework is a critical requirement for many organizations, but is especially important for ISV's who wish to sell custom modules as professional products. In DNN there are a variety of custom artifacts that need to be created and maintained independently from the code itself and must be manually included in the final deployment package. In Oqtane the goal is to encapsulate as much of this functionality as possible in the code itself so that a module is simply a package of one or more DLLs. The most important example of this principle is that there is no custom "manifest" file in Oqtane - it is a class which is compiled into the module DLL.
Although there are cases where it makes sense to come up with original solutions to development problems, it is generally an industry best practice to take advantage of the native solutions which are offered by the providers of the platform. This alignment helps to ensure that the approach is well validated and will be supported in the future. This focus on consistency also minimizes the time it takes for developers to come up to speed on your framework because they are already familiar with the approach based on their other development efforts. In DNN there were many creative solutions, some of which may have been slightly better than what Microsoft provided, however in the long term they became a barrier to entry for new developers and a maintenance headache for the platform. Oqtane will utilize the Microsoft recommended approach as much as possible and only be creative in the areas where Microsoft does not offer a solution. A good example of this is that Oqtane uses Nuget for its packaging and deployment strategy as opposed to creating its own proprietary approach.
Too often in software development a feature is considered to be complete as soon as it delivers the basic functionality to an end user or administrator. Usually the moment this occurs, the developer moves on to the next feature. However this approach is exactly how tech debt accumulates over time. Instead, much greater emphasis should be placed on the run-time characteristics of the feature, how it performs under load or with a variety of different configurations. It is only after a feature has been put through this "last mile" of evaluation that it should be considered to be complete. These optimizations help ensure that a framework maintains its performance characteristics and integrity over time.
There is a tendency in frameworks to make them as flexible and elegant as possible so that they can be adapted to any theoretical use case which may arise in the future. The problem with this approach is that all of the layers of abstraction eventually make the framework overly complicated, incomprehensible to most developers, and next to impossible to test or maintain. In addition, they often lead to performance problems which are difficult to diagnose and resolve. As example of this in DNN is the extensive use of the provider model pattern - even in areas where it is very difficult to imagine an alternate provider implementation. Practical engineering is more of an art than a science, but Oqtane aims to provide a framework which is balanced and intuitive to work with.
Open source philosophy highly encourages the sharing of code so it is common practice for developers to utilize third party components to accelerate their development efforts. There are definitely some advantages of using third party components however there are also some disadvantages. License compatibility and compliance is an aspect of software development which most developers do not usually consider but is a very important topic when you are providing a web application framework. In addition the long term security, performance, reliability, and upgradeability of third party components also need to be carefully considered before they are integrated as tightly coupled dependencies of your application. The goal for Oqtane is to choose dependencies wisely and only include components which are widely used and industry accepted. For example Oqtane needed a common design system and chose to use Bootstrap based on its maturity.
When it comes to software, people often have very strong opinions about how a product should be developed. However in many situations it is not a matter of whether those opinions are right or wrong, it is simply a matter of individual preference. That being said, the most important consideration when it comes to developing a product is to establish some guidelines, implement them at the highest level of your organization, and ensure that all of the related projects follow them consistently. Consistency is the key to making the product easy to understand and maintain in the long term. This includes multiple aspects including items such as coding standards, development patterns, and user experience. As a result, it is important for developers to understand and conform to the established guidelines in order to provide the best possible experience to the community. For coding standards, Oqtane follows the .NET Core guidance and for development patterns and user experience there are plenty of examples demonstrated in the current product.
NOT a CMS
Oqtane is a modular application framework - it is not a content management system (CMS). This is an important distinction as CMS's are typically built around a central content repository and are focused on content management scenarios such as content versioning, workflow, and localization. Oqtane is not focused on content - it is focused on enabling developers to create highly functional web applications.
As mentioned previously the core principles described above are intended to support the overarching core philosophy of performance. If Oqtane is able to maintain this focus on performance it has the potential to be the preferred web development framework for modern applications.