Almost two and a half or three years ago now, Mark
, founder of BizStream, and I finally made the call to mandate that all new projects (where it made sense) would be developed ASP.NET MVC for Kentico and not ASP.NET Web Forms (Portal Engine). Fast forward two and half years later, and I would say we have stuck by that decision for 90 to 95 percent of the new projects BizStream has taken on.
The Initial Push
The nail on the head for our transition away from Web Forms was not what happened externally, but what happened internally. We had found a young talented developer just out of school. He had no idea what ASP.NET was, only PHP, but the concepts still apply. We started working on training him and put a lot of time into it. He had been at BizStream almost 3 years, was a smart kid, and was killing it with Kentico in that 3rd year. We had high hopes he would become a senior developer for us as he had amazing talent and was a great fit into our team and our culture. But after the third year, he surprisingly quit without much warning. Mark and I were stumped as to why. In his exit interview he had two main reasons: One, he wanted to travel and be out more, being a 23-year-old, I couldn't fault that, and two, he literally said the words, that I will never forget, "I hate Kentico. I just can't stand dealing with Web Forms and the legacy technology that it is, it is not helping my skills grow, and I really don't ever want to touch Web Forms again. All of my friends are doing other newer things".
That hit me like a ton of bricks. I had never thought of it like that before. After that statement, he walked out of the interview and out the door. We are still friends to this day, but he works elsewhere now. This was tough for Mark and I. We had invested a lot of time, effort, and most importantly, a lot of money (non-billable time for him to learn) to train and grow his skillset. To have him walk out the door like that, it hurt. We vowed to never let that happen again.
That's the story, but if I had to summarize it: BizStream moved to MVC because we need the ability to recruit good talent, retain good talent that we develop, and provide solutions on technology that our team is passionate about developing on. Building out sites on Kentico using the MVC development model allows us to keep delivering cutting-edge solutions to our clients that are future proof (as best as you can in the rapidly changing world of technology).
The point about building in MVC, "where it made sense", is also an important last point. What we mean by this is, we set two basic rules for our clients regarding the technology we build on:
- If a client had a large investment in Portal Engine sites in Kentico 7.0, 8.x or 9.0, and were using it well, "add-on" projects or additional mini-sites would still be done in Portal / Web Forms. It did not make sense to us to have two different types of projects for the same client. It also didn't make sense to ask the clients to re-train if they were already used to Portal / Web Forms, and it was working well.
- If the client dev team (not ours) was most familiar with Portal / Web Forms, and they didn't have any MVC experience, we again would recommend/choose to stay with Portal Engine, as it doesn't make sense to try to get into the developer education business when BizStream is in the business of building and delivering projects quickly.
The Technical Reasons Why BizStream decided to go all in on MVC
I have been working in ASP since it was just ASP. Yes, it is now known as ASP Classic and was the precursor to ASP.Net Web Forms. I liked ASP Classic then and loved Web Forms when it came out initially. I got to try Web Forms in the first beta release of 1.0 and stuck with it ever since. What that means is that I have a deep knowledge of Web Forms, I loved it compared to Classic. But technology does march on. The more and more you see from Microsoft how-to articles, best practices, and GitHub repos, all of the documentation was moving to MVC and at this point, in 2018 and moving into 2019, is all fully in MVC. That’s a sign that industry is changing. Not to mention if you listened to the Microsoft evangelists and MVPs it was announcement after announcement about the future of where the .Net platform was going. All of it spoke to how Web Forms would not be fully forgotten, but the message clearly said the future would be in MVC.
Front End Innovation
I guess the key here also is that our client's needs were moving towards fully accessible websites that meet WCAG 2.0 AA guidelines, they wanted rich meta data tags such as open graph images and schema.org for rich snippets, and they wanted lightning fast mobile responsive pages that looked great. Those three things are much harder to do in ASP.Net Web Forms then compared to MVC. But from a front-end perspective, the real nail in the coffin was the release of Google Accelerated Mobile Pages (AMP). When the first version of AMP came out, the <form> tag wasn't even allowed in the source of the page. So without a lot of extra effort, making AMP pages that can't have a <form> tag inside a framework that absolutely was built on the <form> tag just didn’t make sense. Now as AMP moved along you can now add in support for <form> tags, but again, all this extra effort for what?
Back End Capabilities
On the backend side of things, our C# developers, who have mixed levels of experience, on Web Forms but each day got them further and further away from understanding the page lifecycle that Web Forms dictate. Over time they have become more fluent in Controllers and Actions, it's just the simple truth. Again, I would attribute this to all of the help out there for developers on StackOverflow, Github, and Microsoft.com all illustrate the MVC way, not Web Forms. MVC offers a clean pipeline where back end developers can inject core components like authentication models with modern and standard packages like SAML2, OAuth, etc. etc. very easily. You add in the required Nuget packages and you are on your way. Large open source projects are really built this way for modern frameworks, and just really aren't built for Web Forms. This is another sign the community of global developers has just moved on.
Then everything changed…again…last year with Microsoft's announcement of ASP.Net Core, ASP.Net standard and even ASP.Net Core 2.1 this year. Now we have MVC Core which is the next generation New Kid on the Block for developers. .NET Core has been built from the ground up to be better, faster, stronger, than the full ASP.Net framework. It runs on just about any platform these days (even Linux and MacOS). Our experience in MVC 5 has helped us leap right to MVC Core and has us ready for the next bleeding edge cycle.
To Sum It All Up
Again, that's the story of the technical side, but if I had to summarize it: BizStream moved to MVC because our client’s project requirements of being responsive, accessible, semantic, and share-able demanded it. MVC is a technology that you don’t have to “fight” to accomplish these things whereas Web Forms is. Couple those requirements with Microsoft’s own statements that Web Forms is on long-term support only, and .NET Core is the fully supported future, the software development world demands it as well.
Oh, and don’t forget that MVC (and especially MVC Core) is flat out more performant than Web Forms. While not perfect, we believe that you can accomplish anything in Kentico MVC that you could in Kentico Portal engine, and your clients will have a much more modern technology solution if you do.
On the flip side, are the concerns and some cons to moving to MVC and Kentico’s implementation of it? Of course, but we firmly believe the cons do not come close to pros. If you or your agency want to deliver the best solution to your clients, that will also be future proof for the current and next technology hype cycle, I would truly urge you to consider MVC as your answer.