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?
PRODUCTIVITY
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.
Microsoft built a whole suite of controls that worked around these issues for us. They posted back to the server using javascript and ran the page lifecycle (or partial page lifecycle), got some data, updated our controls. And they gave us the UpdatePanel, which made it really easy to post 200k of viewstate by clicking a single element on the screen, without even knowing it. And why was that? Because the page lifecycle needed the viewstate of the entire page in order for it to work. The whole model was built on the idea of posting back an entire page. Remove one part of that puzzle, and the whole thing falls down.
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?
In the end, ASP.NET MVC isn’t less productive than ASP.NET Web Forms. It makes YOU less productive because you have spent years learning a framework that abstracts away HTML and Javascript. It’s okay! I did the same thing! The problem is that if you want to continue to develop rich, highly interactive websites, then you are either going to need to start hacking your way around Web Forms (been there, done that), learn a framework that works with the web (ASP.NET MVC, Rails, Django), or move to a RIA technology like Silverlight or Flash. (That last one is a whole other argument)
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.
I think that there is a disconnect common among many developers between short-term and long-term productivity. Sure, you may be able to get the initial load for WebForms data grid done faster (not an assertion of fact, merely a possibility), but the customization and interactivity of that grid are going to be much harder to accomplish. And it’s the latter that most customers are interested in these days.
At my current gig, we are indeed going through the pain of learning exactly what had been abstracted away from us. But it has been nothing but good, our sites are better, our code is cleaner, and I am doing my best to forget that I ever wrote code against OnRowItemDataBound.
@KevDog Yep, I see your point. Although I feel compelled to point out that the MvcContrib Grid funtionality is great. 🙂
That is great that you guys are moving on towards new things. And realistically, I don’t even have a problem with those who don’t. What bothers me is people that actively try to keep other people from learning something new, just because they might be forced in the future to learn something new. That is what gets under my skin.
I wouldn’t say controls in general, but I do miss custom UserControls and ServerControls that have their own independent lifecycle and data access etc.
HtmlHelpers are great but if you need some data in there it has to be taken into account in the controller action and view models for each view that reuses that HtmlHelper.
The project I work on has a lot of legacy WebForms and some new MVC stuff. The WebForms stuff has a bunch of Infragistics controls to help "speed up productivity". The MVC stuff I chose to use MvcContrib (most especially FluentHtml) and make custom HtmlHelpers as necessary.
I am substantially more productive with the MVC approach. Learnable/fluent interfaces contribute greatly to this, as does how easily it all fits into TDD.
Dread fills me whenever I have to make changes to any of our pages that use the Infragistics controls. They were probably a great suite when they first came out and do WebForms really well but they certainly don’t play nice with my test-addicted brain.
Wise words!
Just use Sharepoint! 😀
P.s. Charles, try Spark viewengine. It kicks a** and makes FluentHmtl kind a unnecessary (and they aren’t mutually exclusive).
Justin,
As one of the many who has yet to find the time to look into MVC….I would love to see a post with some code, say, a simple input form, filled from a database, with a textbox, dropdown (filled from some datasource), radio button, checkbox, and some realistic representative code of how this simple example would be implemented in asp.net webforms vs MVC.
I imagine I speak for a lot of people when I say, we hear time and time again in blogs how awesome MVC is and how unproductive webforms are, but I have yet come across a post where someone actually says "look at this code, see how much better it is!"
Of course there’s no obligation on your part to do this, but I think a lot of people would be very interested in a compare and contrast article like that.
@Trevor I agree, I definitely need to do this exact exercise. It’ll elicit a lot of complaints from both sides, but I think it is something that needs to be done. I am going to put it in my queue and hopefully get a post up about it soon. Thanks!
Clicked on ad about suite of controls. Don’t want to say anything bad about product itself (haven’t even checked it out). But this one (comment/review) made me laugh:
"I can be confident that if I need to do a particular task, [CompanyNameGoesHere] will have the control to do the job. The controls I have used are stacked with properties, methods and events that enable me as a programmer to have granular control in making a program work as desired…"
‘Granular control’ part is my favourite.
P.s. @Trevor – there’s many MVC sample apps. You just haven’t looked around. 🙂
@Arnis I know there are many sample apps, but I have many things on my to do list, and learning MVC is still a ways down. My point was that I read blog after blog of MVC advocacy but for me, it is falling on deaf ears. Now, if someone was to write one thats shows some code so we can SEE how much better it is, it might be more persuasive.
If you need a sample app to get your head around the concepts presented in this post then WebForms is probably where you belong.
I often use Apache Wicket, which I consider to be the best of both worlds. A component-based MVC framework for building stateful webapps. In the past I’ve used RoR, Django, and Grails, but I always find myself leaning towards statically-typed languages. The great thing about Wicket is you *could* develop Wicket apps with any language that compiles to the JVM (such as Scala, Groovy, etc). I can’t comment much on ASP as I haven’t used it much, but in the past I’ve found Microsoft auto-generated voodoo code to be horrifying (I was exposed to Visual Basic when I started out in development). I think the problem now is the learning curve is a little steep with certain frameworks, especially in the Java world, and people feel so crunched for time they’d sooner continue dragging and dropping icons around a screen instead of taking a time-out and learning a totally new (and initially uncomfortable) technique for developing software.
totally agree with trevor
one can make an asp.net webform website better than most mediocre MVC sites out there.
MVC sites are much more “fragile”