I can’t believe I’m involving myself in this conversation. In fact, as I write this I am dying a little bit on the inside. Both Nate and Rob are probably going to shake their heads in disgust at me, but I’ve come across two blog posts today that have made my skin crawl a bit, and so I feel I have to dip my toe into this water. And so here it goes….
CONTROLS DO NOT MAKE YOU MORE PRODUCTIVE.
I seriously thought about putting some nice "marquee" tags around that, maybe a little blinking would help drive the point home.
But there, I said it. You people need to get over your control obsession. Whenever I see people comparing MVC and Web Forms, it is always "MVC is less productive because it doesn’t have controls." People will acknowledge that MVC has "helpers", but helpers apparently don’t fill the same role as controls. Oh, the argument is that MVC gives you more control, but since I can’t drag and drop a bunch of stuff on a form, then it makes me sooooooo slow. <insert your own picture of Eeyore here>
Let’s look at this for a second. Controls encapsulate a piece of functionality so that it can be reused on different pages. And in ASP.NET MVC, HTML helpers encapsulate pieces of functionality so that they can be reused from page to page. Helpers server a very similar function that controls do in ASP.NET Web Forms, only they just output text and they don’t have a lifecycle or viewstate or any other sort of abstraction around them.
So What Exactly Is The Problem Then?
So here’s the thing, I’ve heard of these two frameworks that are used by social misfits and hippies in order to build small slow websites for thousands of companies. (saaaaaaaarcasm) They are called Ruby on Rails and Django. And guess what they are known for?
Sure, they are built on powerful dynamic languages. And they use convention over configuration. And they both have simple backend ORM solutions. And they both have rich control models. Oh no wait, they don’t have that last one.
WAIT?!?! WHAT?!?! They are known for their productivity, and they don’t have control models? How could this be? Sweet hammer of Thor, how can they be productive without viewstate!? (Sorry for the Anchorman reference.) No, they haven’t involved themselves in black magic. They write their HTML like almost every developer that isn’t on a Microsoft platform. They use templates, with a mix of some helper methods, and they work with the web and not against it.
Which is interesting to think about it. Don’t get me wrong, Web Forms is a great technology. An aging technology, but it is a great technology nonetheless. In it’s name it states exactly what it’s purpose was. To take Windows Forms programming and move them to the web. And it succeeded. But I believe that it has gotten us about as far as we are going to go with that model. As the web gets more and more rich, we need to start working with the web in order to build these richer experiences.
But working with the web doesn’t mean that we are less productive. If I want to create a form with ASP.NET MVC which has a few fields on it and posts some data back to the server, it takes no more effort in MVC than it does in ASP.NET WebForms. I’ll still put a few fields on the page, I’ll still use some sort of data access mechanism on the back end. I’ll still be able to use simple form validation.
Let’s Take A Look At The UpdatePanel
The story of the UpdatePanel is the perfect example. I know everyone picks on the Update Panel, but if you really think about it, it is a hack, built on a hack, which is built on a hack (of course, that just described the entire internet). We started off with the Web Forms model and it was great. We could built web pages which were built around this idea of a post-back. We could use controls to drop things on pages, we could save data through viewstate, and then we could wire up some events and voila! We had a working page.
And then the era of ajax came about. ASP.NET developers felt really shafted for quite a while. With all of this viewstate and controls and stuff, we couldn’t modify and post our pages back. Things got screwed up because the idea of modifying the page on the client side wasn’t really accounted for within the Web Forms model. And why should it have been? No one was doing this stuff when WebForms was built. So what happened? We got more controls.
And so here is the problem, what if you need functionality that isn’t within the suite of controls that are provided for you? Well, you can either build your own controls which do this functionality for you, which is not at all an easy task. (Go look at the source for the ASP.NET Ajax controls) Or you can bypass the Web Forms model altogether and just write it with HTML/JQuery and then capture a few post values. How many of you out there have had to do this before? I know that I have had to do this more times than I care to admit.
Where Does This Leave Us?
And you know what? No one is telling you to switch frameworks. You’ve invested a lot in Web Forms, many of us have. But what I am asking people to do is to open your mind to the fact that over the last decade, people have figured out better and more productive ways of doing things, and ASP.NET MVC is Microsoft’s shot at moving toward what many in the industry have already figured out… we can be more productive by working with the web than by working against.
Loved the article? Hated it? Didn’t even read it?
We’d love to hear from you.