As you might have heard, you have to migrate to Razor soon. Old-school developers have a hard time understanding why WebForms should be replaced, since it's worked to well for more than 10 years. So in this part 3 of my Series The Future of DNN Speaks Razor, I'll explain why WebForms turned out to be the wrong solution for web development and how the web changed to make WebForms' strengths obsolete.
The Truth based on My Personal Experience
My answer is a mix of the official version and by experience. Note that I've refused to adopt ASP.net MVC for many years now, because in the beginning it was so trivial that there was no benefit in migrating. After a few years it got better, but most features were also available in WebForms, so I still didn't want to adopt it. This changed about 2 years ago after the introduction of Razor (August 2012). Since then, most of our web work was done in Razor (did I say MVC? nope, must have missed that...).
As an important note: I'm still not too excited about ASP.net MVC, because it contains a bunch of stuff I don't care about. But I LOVE Razor and the WebAPI - and when you combine this with DNN then you will quickly see that the WebForms paradigm is dead. Just to stay focused - again the DNN Roadmap:
Why is a great product like WebForms phasing out?
About fifteen years ago Microsoft tried to deliver Visual-Basic-Style development to the web community. Everything should have been drag-and-drop with smart components doing everything for you. This is why even something trivial as a label (Please Enter Your Name) was made smart - so that you could program against it without knowing HTML. Many things were abstracted so that you wouldn't have to know HTML, CSS or HTTP. It should have felt as if your web-page was always connected to the server (like a VB-Program). It should have just worked. And the server should have been very important for the user experience. To do this, Microsoft gave us things like:
- Page Lifecycle with thousands of raised events
- Postbacks instead of URLs changing when we click a link
- Dynamically generated HTML-IDs so the server can keep track of what the browser sees
- Event-Binding so the server knows what element was clicked
- Code-Behind for the event-programming
- Web-Controls to bundle standalone components
- Themes to generate HTML and CSS when some design changed (used to be necessary if you wanted rounded corners)
But the Abstractions Backfired
So first of all this abstraction-concept backfired. It was never possible to create solutions without knowing HTML, CSS and HTTP. To make matters worse, we were actually forced to learn both HTML/HTTP AND the wannabe-abstractions Microsoft invented AND we needed to learn workarounds against the abstractions as they caused a lot of problems. The Viewstate is a perfect example of this - it would have been great, but I wasted so many hours working around the problems created by a Viewstate that it killed all the efficiency gains the Viewstate should have given me.
And the CodeBehind Backfired
Another thing that the classic VB-Programmer got wrong: the Codebehind was the perfect place for quick-and-dirty (and with time: very large and dirty) solutions. Millions of WebForms solution have business logic and data logic in their code behind - because it's so d**n convenient to put it there. This resulted in solutions that never scaled, couldn't be reused and were hard to maintain.
Browsers Became so Powerful That Servers didn't need to Predigest any more
You could say that HTML5 makes ASP.net MVC (any Server-Side MVC but not MVC in general) obsolete.
- Deliver the HTML containing the content in a structured manner
- Deliver additional assets (images, code-snippets, css)
- Save data if the user submits a form or something
This is a bit oversimplified, as delivering the right content actually takes quite some work (URL-Routing, database retrieval, security checks, …) and delivering the assets is also complicated (re-sizing, bundling, …). And saving data is also quite some work. BUT it's much less work that originally anticipated 15 years ago by Microsoft. The final straw was when Responsive beat the cr** out of Adaptive.
Here's my favorite Responsive-Quote by Josh Clark, beautifully illustrated by Stéphanie Walter .
And the Web Designers of Today are the VB-Developers of Yesterday…
And they start with the simple stuff, not the object oriented multi-tier looks-easy-but-is-very-tricky-to-run editions.
In 1995 many programmer-novices got started with Visual-Basic. Thousands of people needed something automated in Word or Excel, wrote their first macros and then went on to build solutions, leveraging their limited initial know-how. Every solution built upon the previous one and became just a little more complex. These people never spent a week to learn a new concept or patterns - it was always "I already know 90% - how do I get this other detail to work".
Because of this, the newbies almost always follow a learning curve which doesn't fare well for WebForms.
WebForms must be replaced, because the abstraction failed and actually increased complexity. An a plain-vanilla approach focused on classic technologies like HTML and CSS will succeed, because it's the "natural" way people grow into this topic. But before you say "I knew MVC is better" - wait for the next post showing why ASP.net MVC failed as well, and why Microsoft is still calling it MVC.... (more in the next post)
With love from Switzerland
PS: Want to get started before the entire Razor-series is out? For the impatient, try the DNN-Razor Host Module and watch this video or try packaged code apps by installing 2sxc and some of the Razor Apps like the Razor Basic Tutorials, List-Tutorials or the SQL and Peta-Poco Tutorials.