The Future of DNN Speaks Razor - #3 The Death of WebForms

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:

1. ViewState
2. Page Lifecycle with thousands of raised events
3. Postbacks instead of URLs changing when we click a link
4. Dynamically generated HTML-IDs so the server can keep track of what the browser sees
5. Event-Binding so the server knows what element was clicked
6. Code-Behind for the event-programming
7. Master-Pages
8. Web-Controls to bundle standalone components
9. 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

And in addition to the extra complexity that didn't contribute enough value, the web evolved very quickly and became increasingly complex - but not like Microsofts original architecture anticipated. The original design of WebForms expected the server to handle all kinds of scenarios - including adapting to limited device capabilities (screens, touch) and produce optimized HTML for each device. In Microsofts vision this was what each WebControl would have done - but the Web didn't go that way. Today's concepts of responsive webs place all that control in the hands of CSS and Javascript - almost everything takes place in the browser. The pre-chewed-HTML-concept became unnecessary.

You could say that HTML5 makes ASP.net MVC (any Server-Side MVC but not MVC in general) obsolete.

The Place for View-Logic is now HTML and CSS with a Drop of JavaScript

Let's face it: the choice of server infrastructure is actually becoming less important. Because plain-vanilla HTML, CSS and JavaScript do a great job at creating great looking UIs which are responsive and get things done. And there are so many web-designers and JavaScript-developers out there, that they will solve your problem. So the servers mission has changed. The server of the future must only:

1. Deliver the HTML containing the content in a structured manner
2. Deliver additional assets (images, code-snippets, css)
3. 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".

Today's millions of newbies start with web technologies. They do their baby-steps in JavaScript and HTML. Then they add just one additional feature. They want to leverage what they already know - and a text-based just-add-placeholders-system like PHP or Razor is much closer to that initial know-how than a controls-based abstraction called WebForms.

Because of this, the newbies almost always follow a learning curve which doesn't fare well for WebForms.

In Summary

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
Daniel

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.