Kentico MVC vs Portal Engine

Delete’s Solutions Architect and Kentco MVP, Dmitri Bastron, recently covered this topic at the Kentico Xperience Connection event. So if you missed it, or you simply want to know more about this subject, here’s a summary of what Dmitri and two other Kentico MVPs had to say.
Kentico MVC vs Portal Engine

*This blog includes the additional insights of Kentico MVPs Sean Wright, Development Lead at WiredViews, and Andy Thompson, CTO from Luminary who discussed the subject of developing websites using MVC vs Portal Engine with Dmitri. To cut to the chase, with the release of Kentico Xperience 13, Portal Engine is no more, it’s MVC all the way. I’ll talk you through this and help you better understand why you might want to make the switch yourself.

Advantages of MVC over Portal Engine

First of all, MVC is now the only option with Kentico Xperience version 13. Kentico will provide support for older versions, but MVC has been their main focus for the last couple of years and it isn’t going to change. In addition to this, there’s these advantages:

  • MVC is the technology of choice for Microsoft
    It’s not just Kentico moving away from Web Forms - which is the technology behind the Portal Engine - MVC is Microsoft’s own technology of choice. All of their efforts, new technologies and new releases are developed in MVC.

  • MVC is the developers’ technology of choice
    Most developers want to focus on MVC, .Net Core and use the latest and greatest technologies. Finding a developer who can work with Web Forms is possible, but usually costs more and the pool of candidates is less varied. There is a strong commercial business incentive for keeping up with the latest technologies which offer a greater choice of cost effective development resources.

  • MVC offers greater control
    The MVC model allows you to have complete control over the output of your own website. You are not tied to using the markup that comes out of the CMS - where forms or page elements can have CMS injected styles or HTML - which sometimes makes your front end look wrong. You are not held back by the CMS’ rendering and instead you are in complete control of it.

    .Net 5 and .Net Core is the future of web development, so if developers want to stay up to date with MVC they should also remain up to date with the latest versions of C# and .Net.

    Also, pretty much everything has moved into Microsoft Azure in the cloud and you’ll also want to stay on the latest version to get the other benefits such as security and scalability - which you can't do if you stay on a 10 year old server that hasn’t been updated.

    On top of this, doing heavy JavaScript integrations is much easier with MVC, particularly when creating client side interactivity. For instance, when we’re building client side widgets, or large sections of the page in React, View, Angular, Svelte and other JavaScript libraries, we need to be able to hand over the page to those JavaScript frameworks or find a way to easily integrate with the server rendered HTML - and this is much easier to do with MVC.

  • MVC is easier for others to use
    Creating web parts of layouts straight in the CMS is easy, doesn’t require development and allows clients with some knowledge of HTML to amend the HTML via the admin area of Kentico and publish it straight to the front end.

    However, large projects and enterprise clients do not expect platform users to edit HTML directly in the CMS. Large clients usually have different editing roles, multiple environments and the changes need to be synchronised between those environments. It is possible to synchronise changes of the HTML markup saved in the CMS with continuous integration and other approaches, but it isn’t scalable or futureproof.

    It is easier to commit changes and store them in the website code. The MVC model empowers UI developers to work in their own tools. This is why front end developers are among the biggest supporters of the MVC approach.

Content Management in MVC vs Portal Engine

When content editors, for example article editors, work with content in the Portal Engine, they find having two tabs for ‘Page’ and ‘Design’ very confusing.

Clients go into the ‘Design’ tab and expect to edit a page, but accidentally ruin the layout for other pages. There are some flexible widgets, but in order to edit content inside the widgets you need to open the ‘editor’ dialogue which has many restrictions and too many options to choose.

However, on MVC there is a much clearer UX for dropping widgets on the page, when the ‘page builder’ interface is enabled. There’s also no ‘Design’ tab anymore so it’s also a lot less confusing for content editors.

We can also use inline editors, which is a great feature in Kentico MVC. This allows us to drop a widget inside a page where developers have prepared the design styles and the editor can click inside the widgets and start editing content. It then gives greater flexibility for implementing other types of controls via inline editors. For example:

  • The number of images inside a gallery can be adjusted by clicking the plus and minus buttons.
  • Image selection can be contextualised.
  • If you have a carousel of a few slides, you can switch to the third slide, click on the image and select a new image from the media library picker.

What’s more, the consistent feedback we are hearing from clients who have upgraded is that they find these new interfaces easier to use.

Lastly, one of the real benefits isn’t really to do with simply ‘MVC vs Portal Engine’, it’s more that making the switch gives you the opportunity to rebuild with personalisation in mind.