RIP Web Forms, MVC Is the Future! – Part 2

No Big Bang MVC Moment

What we typically talk about with partners that are very active building or working on complex projects, and are digitally mature, is how much of their beloved libraries of components for Portal Engine do they regularly use? This is an important factor when you want to gain a more accurate perspective of the true scale of kicking off that transition to MVC. But in all honesty, they often admit that their fear of the transition is, in fact, a slight overreaction when it is actually only 5, 10, 15 things they are using and will have to recreate. And because they will not have to recreate all of them at once as their next project will need say three of them, and the one after that, an additional five, that transition no longer seems such a daunting task, but instead a manageable step-by-step one. So the main point here is that there does not need to be a big bang, you can do it gradually, and we have the documentation you need to learn about how to build different kinds of widgets to help you—meaning, there is plenty of guidance prepared that you can follow. And we have prepared an MVC transition guide for taking those first steps too.

Another great benefit is you get to look at your core pallet of components, and it gives you the opportunity to see how you have been doing things in the past, and think about how you can improve upon this in the future. It shouldn’t be viewed as a challenge, but rather an opportunity to provide customers with better experiences while building a competitive edge over those others stuck on legacy technology. And when it comes to explaining to customers that it is not Kentico that is pushing them to transition, but it’s Microsoft, these customers will realize very quickly that they don’t want to have their projects built on outdated technology. So, we are trying to think ahead and provide you with the resources and guidance you need that will help you achieve all of this.

Banish those Upgrade Woes

One of the major pains that partners and end clients encounter when it comes to upgrading from one version of Kentico to another is the upgrade path. It is necessary to not only upgrade to the latest version, but go through each version in between, meaning the monolith of administration (the ‘Mother’) and presentation (meaning Portal Engine) has to be tested at every step, and it is a huge investment in terms of time and money. And all of this concerns EMS, content management, online marketing—all of those modules, and your presentation, which is the Pages application where you are actually creating the presentation using web parts. As they are all intertwined, when you modify something and make some customizations to the presentation layer, it’s part of the Mother instance and not the separate frontend application. So, when you’re performing an upgrade of the Mother, you’re also upgrading the frontend application, and any conflicts coming from customizations that weren’t done properly will result in potential issues. This means you need to test that customization is actually still working the same way it did before, and you may need to redo it if the related APIs changed in between the versions.

Whereas, with MVC, it’s your web application that is actually consuming and displaying the content, the services capabilities from the Mother are separated, and it’s loosely coupled through the set of purpose-specific APIs, and that’s it. So, the upgrade of the Mother should be much faster and easier, and you only have to deal with changes with the presentation—and it is separate. By leveraging the API we provide, if anything changes, it will be, typically, hidden behind the business API you’re working with in your web application. It’s true, swapping to MVC takes time, but when you compare the 20 hours necessary to recreate those three, four, or five components you were using on your old site, with the 30 fewer hours of work you will need for every upgrade in the future, the math speaks for itself.

Bring on the Talent!

As we have previously mentioned in other articles, agencies are struggling with the almost-impossible task of recruiting developers if they continue to pursue working with a soon-to-be-extinct technology. This is nothing new, university graduates haven’t been receiving any education on Web Forms for a while now as Web Forms are not relevant and do not feature in the current curricula. So, when you want to recruit and retain talent, you are going to need to have those current technologies in place so they can bring their know-how and their latest technology knowledge with them and use it if you want to keep your business healthy and a going concern.

Plus, the developers that know Web Forms are typically more expensive as they are considered more backend development, and those developers are typically pricier than frontend ones. Meaning, from an OpEx (operational expenses) perspective, it is more cost effective to hire frontend devs than backend devs. So if you have MVC technology, you do not need your devs to be so skilled in backend development, and not only is it cheaper to find and hire developers, it’s also easier. In addition, those people that know MVC can generally also easily pick up other frontend work such as JavaScript and CSS. And all of these things contribute to the business value proposition for the end client. When you ask your client, “Do you want the best talent you can get in the area working on your digital projects to make sure it’s successful? Or do you want to get fewer but more expensive people where you don’t get the choice of picking who is going to work on your project?”, this typically sparks an interesting discussion and makes the client realize the technology is actually more important than they thought.

Laggards Beware!

If some agencies are not interested in building their business and only want to maintain their current “sustainable” business, there could well be a reluctance to make the switch. But the result of that approach is they will have built their business on a technology that is no longer relevant. So every agency that wants to survive in the .NET world needs to be learning .NET Core MVC, which is one of the reasons for the direction Kentico has taken. Otherwise, you face the danger of: How am I going to provide a future-proof platform for my clients so they can succeed in the long term?

So to recap on what we covered, simply put, if agencies are not going to make the switch, their expenses are going to keep going up and up, they simply won’t be able to compete with the other agencies in their area. Because those MVC-adopting agencies are going to be more agile and nimble due to the technology they are using. They will struggle to find developers that can build on those dying and unsupported technologies, and most importantly, they will be creating an upgrade path obstacle course that will hit them where it hurts, in the wallet.

In the final part of this blog series, we will be taking a look at some of those considerations agencies should keep in mind before making the jump to MVC in order for that transition to be entered into in the best possible fashion. As always, should you have any comments or feedback on the points covered in this blog post, feel free to share them in the comments section below.