The Frontend Development Future. Now

An architecture built on separation of concerns has multiple positive effects on administration, development, hosting, deployment and scalability. 

The content you create can be reused and easily delivered and maintained across multiple frontend consumers. Whenever content is updated, it’s ready to be consumed via APIs by any frontend framework you choose to employ. Content editors have a high level of flexibility and independence, meaning developers on the other hand are free to explore more and better ways to improve the user experience and leverage diverse frontend technologies. 

The .NET Core renderer in Sitefinity 13, for example, is a stand-alone application that can be deployed and hosted anywhere. It can work on any OS that .NET Core supports and you can use any text editor. When developing new features and functionality, you work on the presentation layer of Sitefinity only, which lets you iterate at a higher speed.

The .NET Core Renderer in Sitefinity 13 is a technical preview aiming to give early adopters a taste of the full .NET Core replatforming, which is firmly in our roadmap. In upcoming releases, we will continue extending the functionality as we target a presentation layer fully relying on .NET Core as the technology to develop widgets, templates and scripts. The full frontend development suite. 

The Page Layout API (released in the previous v12.2) supports content blocks and custom widgets and is the key service that provides content to the .NET Core widgets but it can be consumed by any other frontend framework as well.

Plans to migrate existing pages and widgets are being prepared for the upcoming releases. There will be several migration models available to Sitefinity license holders.

• Guidelines for the migration of MVC widgets - migration of MVC views and business logic (manual migration of code)
• One-way migration of existing pages to the renderer and editor: full migration of legacy pages built on MVC and Webforms along with widgets and templates. Considering ways to automate the process.

Migration of existing .NET Core projects to the CMS. Since we have seamless integration with the .NET core pipeline, users will be enabled to migrate their MVC razor pages and controllers to the CMS pages. This would be an entirely manual process.

The .NET Core renderer can be deployed on any platform supporting .NET Core: Linux, MacOS, Windows and can work with a remote Sitefinity instance. A stand-alone application, the new renderer can be deployed on Azure App Services right out of the box.

The following hosting scenarios are supported:

Renderer	Sitefinity
Local (Windows)	Local (Windows)
Local (Linux / MacOS / Windows)	Remote on Azure
Local (MacOS)	Local VM (Windows)
Remote on Azure (Linux / MacOS / Windows)	Remote on Azure (Windows)

Sitefinity constructs pages via the Page Editor with “drag and drop” support. Even users with little or no coding skills can easily build pages. Behind the scenes these widgets and their configurations are stored in the Sterility database as a meta model. The renderer can consume this model via REST services, parse it and construct a page for the specific set of widgets. It then renders the page in HTML and returns it to the end user.

These pages are based on templates coming from the Renderer. In the case of the .Net Core renderer, they are MVC Layout files in the file system. These layout files are available to choose from when creating a page. If a page is based on one of these layout files, the renderer will be able to render the page.

The standard approach to extending the Sitefinity frontend is to write custom widgets or configure/override the logic of the prebuilt ones. The corresponding elements for widgets in .Net Core are ViewComponents. Widgets that are available in the drag and drop editor correspond to the ViewComponents classes in the .Net Core Application.

The Sitefinity .NET Core Renderer is still in Community Technology Preview. If the two OOB widgets serve your needs, you are free to start developing with .NET Core. Although we plan to elaborate on it, we will not cease to support the standard .NET framework and the two-tier Sitefinity CMS architecture.