Sponsored By Aspose - File Format APIs for .NET

Aspose are the market leader of .NET APIs for file business formats – natively work with DOCX, XLSX, PPT, PDF, MSG, MPP, images formats and many more!

WebForms vs MVC (again)

There’s a new video up on www.asp.net which aims to help developers pick between ASP.NET WebForms and ASP.NET MVC. The video boils down to 5 benefits per technology which Microsoft thinks you should consider.

Let’s go over the points, shall we? First, ASP.NET WebForms:

1 – Familiar control and event base programming model

The claim here is that the ASP.NET model is comfortable for WinForm programmers (thankfully this unbiased analysis left out who it’s more familiar for). This is largely accurate, but disingenuous. The differences between web and desktop cannot be overstated nor can one overstate how bad ASP.NET’s (or any other framework) is at hiding the difference. “Familiar” is probably the right word to use so long as you recognize that, in this case, at best it means: superficial; at worst: a serious pain in the ass. Your knowledge of building a VB6 app will allow you to write a “Hello World” web application – great.

Familiarity can be a liability when it tries to force a square peg into a round hole.

It also largely relies on your inability (or unwillingness) to learn. Today, next month or even next year may not be the right time for you to learn something new – that’s fine. Eventually, sticking with what you know, only because you know it, will kill your career and possibility part of your spirit.

2 – Controls encapsulate HTML, JS and CSS

It’s true that in ASP.NET WebForms controls can, and frequently do, encapsulate HTML, JS and CSS. How this ads “value” is beyond me. You can’t, and shouldn’t, be trying to build website without a solid command of HTML, JS and CSS. Whatever programming language and framework you use, the ultimate output of any website is HTML, CSS and JavaScript. Your server code essentially generates a stream of characters, which a browser loads and renders. To suggest, or think, that generating HTML, CSS or JavaScript in C# has any advantage is insane. It’ll be more complicated to learn, do and maintain – and the end result will be inferior. Its like saying we should write C# in VB.NET; or drive cars by bolting planes to the roof and getting in the cockpit.

3 – Rich UI controls included – datagrids, charts, AJAX.

Point 3 is a different perspective on point 2, which is a different way of saying point 1. However, it is the most interesting and important perspective. Fancy tables and charts, as well as client-side behavior, shouldn’t be a server-side concern. This is fundamental to what we all know about good and bad design. Classic ASP was a mess because it intermingled presentation code with server side code. The value of WebForms is that presentation logic is now a server side concern. Do you really believe this? Would you consider generating your HTML from a stored procedure?

The claim also implies that by using ASP.NET MVC, you won’t be able to have a rich UI. In truth, you won’t only have access to a wider range of controls; you’ll also avoid a bunch of poor abstractions, and generate JavaScript by writing JavaScript, css by writing css and html by writing html.

4 – Browser differences handled for you

I’m guessing that the claim is that some of the controls mentioned in point 3 might render different HTML based on the requesting browser. Guess what, most jQuery (or any other js framework) plug-ins are fully compatible with all relevant browsers because they too can generate different HTML. In fact, doing this on the client side is almost always better – since you can tell the exact capabilities of a browser.

Also, it would probably be better if you generated correct HTML, CSS and JS in the first place – something you can’t normally control using ASP.NET WebForms. So not only is this really just a benefit because IE is a pain, but its only worth mentioning because points #1, #2 and #3 mean that you’ve lost complete control over doing it right in the first place.

5 – SharePoint builds on WebForms

Yes, if you use SharePoint, you’ll have to use WebForms.

Now on to ASP.NET MVC:

1 – Feels comfortable for many traditional web developers

ASP.NET WebForms is familiar while ASP.NET MVC is comfortable – that’s helpful. Nonetheless, when I see “traditional” I think “not-modern”. A more honest counterpoint to the WebForms claim would be: “A more natural way to build web applications”. WebForms tried to help WinForm developer’s transition to the web. ASP.NET MVC is a model that better reflect the realities of programming on the web. It’s more than just comfort, and has nothing to do with tradition.

2 – Total control of HTML markup

HTML, JS and CSS are yours to command. That doesn’t mean you can’t use controls to speed up development and improve your applications. The way this is worded sure makes it sound like MVC is a lot more work than WebForms though. It isn’t.

3 – Supports Unit Testing, TDD and Agile methodologies

I’m not sure what the technology stack has to do with the development methodology, so we’ll just ignore the last part. That aside, its true that MVC makes it possible to unit test your code. The counter point to that is that WebForms is essentially impossible to unit test. This also understates the architectural superiority and design of MVC – its doesn’t only allow you to leverage a number of best practices, it itself is actually built around those same practices. Code that can be unit tested, regardless of whether it is or not, is almost always superior to code that cannot.

4 – Encourages more prescriptive applications

So if ASP.NET MVC lets you build you application the way you should be building it, should you infer that ASP.NET WebForm forces you to build applications the wrong way? Yes, you should.

5 – Extremely flexible and extensible

Both frameworks share this value – but ASP.NET MVC is more about building on top of existing code, while ASP.NET WebForms is more about hacking things until they work. If you think this means that ASP.NET MVC can only be useful once you’ve extended it, then you are wrong. It works great out of the box is is feature rich.

Other Stuff

The video goes on to make weird assertions, like the possibility of turning back and picking a different stack if you feel you’ve made the wrong choice because of how similar and how much infrastructure they share. The better solution is to pick the right technology because going back months or years into your project doesn’t sound like good advice to me.

It also mentions that it’s common to have some pages handled by MVC and others by WebForms. It’s good to know that you can do this – especially since it’s a good way to upgrade from WebForms to MVC. However, I’d hardly call it common or even recommended. It’s a useful transitional tool which you should aim to get out of as quickly as possible.

Ultimately, the first 4 values of WebForms all boil down to the same thing: there’s a System.Web.UI namespace which represents the wrong way to build a web app. There are good reasons to pick WebForms – but they all come down to time and practicalities of learning new things (and SharePoint). I won’t tell you that you have to learn MVC, because that may not be practical for you. I’ll repeat what I’ve said before, ASP.NET MVC and WebForms DO NOT serve different purposes and one is not better suited for a particular type of application than the other(except SharePoint). They are completely overlapping technologies, and ASP.NET MVC is superior to WebForms.

This entry was posted in Uncategorized. Bookmark the permalink. Follow any comments here with the RSS feed for this post.

31 Responses to WebForms vs MVC (again)

  1. CodeMonkey says:

    MVC was only “formally” released early last year. There are very few 3rd party components made for MVC, compared to ASP.Net. In order to support MVC, you would have to find and hire persons who know MVC. MVC is simply not widely used yet. There is nothing that I cannot be done with ASP.Net. Why would I change something that’s not broken?

    You indicated that this article would discuss the pros and cons of each. All you’ve done is try to sell us on MVC and slam ASP.Net. Can you point out one place where you indicated the pros of ASP.Net — where you actually thought that ASP.Net was better? Yah.. I didn’t think so.

    You’re so in bed with MVC. Go take a shower man :)

  2. Mike says:

    Dragmonkeys need to be shot.

    OK, I’m kidding. Let me rephrase that:

    Dragmonkeys need some HTML lessons. And then some MVC books.

  3. CrustyOldDean says:

    I think they’re both sub-optimal. With enough prodding and coaxing you can bend either to your will. In the hands of a qualified developer, I don’t see one being any better than the other. I’ve been serving up HTML since the IDC/HTX days and before that using CGI executables and scripts. It’s no way to build an “application”. Bring on the client side Javas! er, um… I mean Silverlights! HTML5 by 2015? 2025? Any bets?

  4. Abdu says:

    Comparisons aside, use the tools which pay your bills. Right now all the ASP.NET open positions in my area are WebForms and not MVC. However learn MVC on the side. You will use it sometime in the future when it becomes more ubiquitous.

  5. Andrew says:

    Chris,

    But this isn’t how Web Forms is being sold to the public. The “benefits” of Web Forms that is constantly being peddled by Microsoft (and fans of Web Forms) is the ability to using complex controls and the ability to create a thick client.

    I completely agree in the YAGNI world if there is a requirement to build a one page site that simply spits out some data for internal use only, there’s nothing wrong with creating a Web Form app to do so. I did just that a few weeks ago and I loathe Web Forms but I needed to hit a DB and display the contents of a single table in a grid/table. No style sheets, no other controls, just a page where a table dump could be read by the Hardware Developers. For that job Web Forms did the job in minutes, and I was thankful for it.

    The problem is, that frequency of projects like that is few and far in between.

  6. Chris says:

    While I definitely prefer MVC and advocate it’s use over WebForms on a daily basis, I’d have to agree with Pete. If you need to create a pretty simple application that just does some database interaction (i.e. display a table, allow you to edit the data) you can create it in WebForms much faster than you can in MVC. The output it not going to be something anyone would consider a “Quality web site” but if WebForms gets the job done and fulfills all the needs of the users its still a viable option.

  7. Last 4 monthes I working with ASP.NET MVC in my free time, and with classic ASP.NET in my working time, and find MVC is much more better. It allows to create better user interface with javascript, easy to use, but more difficult to understand.

  8. Very well said again, Karl!

    Bertrand raises an important point above, saying that for “web controls … real reason is to provide higher level abstractions than div and input”.

    I would agree with that, but still thinks that it is insane to generate client code on a server, trying to predict all the features and quirks of client-side interface and logic.

    To me, a proper design includes client side tools/libraries and only *very basic* server side generators which together allow to avoid/diminish amount of low-level (‘div’ and ‘input’) client code manipulations.
    Business logic is largely contained on a server.
    This makes extremely [most] important to have a standard generic protocol and transport mechanism (think about JSON) allowing to pass information / requirements between server and client.

    For example, there should be a set of rules which allow server to tell client what validation it has to perform on user-entered data.

    If server and client can speak and understand each other (i.e. common protocol), there is no need any more to generate the whole client data validation code on server. Instead server just tells client what to check for.

  9. mendicant says:

    “I agree, but your average corporate developer doesn’t want to learn jQuery” or DI, or SOLID, or anything really. That’s why your average corporate developer, the people you are defending, aren’t worth the keystrokes it took to type this.

    It’s the embodiment of what is wrong with what we do and helpful little videos like this make it worse.

  10. I think you’re right but your point would have been better made had you “mis de l’eau dans ton vin” (tone it down).

    With that being said, good post as usual!

  11. Andrew says:

    Justin,

    I’m not saying it’s not done, but I’d be surprised if it was anywhere close to common.

    I just find it weird that a site like http://www.asp.net would even post such a video, I guess it’s to get hits or something since it’s just flame bait anyways.

    See, just look at our Bullshit Detector, he already knows that Karl is out of touch…apparently he migrated here from WekeRoad.com. :)

  12. Ben Taylor says:

    I would guess that the argument that Microsoft is trying to make is one that doesn’t involve putting a bullet in the head of WebForms. I think they did that before with VB and that didn’t go that well for them. Doesn’t do any harm to point out better ways of doing WebForms while people are still using it.

    Anyway, we all know that ASP.NET MVC sucks too. FubuMVC and OpenRasta FTW!

  13. Justin says:

    @Andrew,

    I don’t know how common it is but I am running MVC alongside of Webforms. I didn’t really have a choice. I wanted to get out of Webforms but I was not going to rewrite 3 years worth of code. It was actually fairly easily to get MVC and WEbforms working together. Now any new code gets written in MVC and I can choose to rewrite and old webforms code if and when I want to.

  14. karl says:

    @Ben and Onur:
    Your argument, re MVP frameworks that sit on top of WebForms is valid. But that isn’t the argument Microsoft is trying to make. And the vast majority of people who are going to pick one or the other are going to be using as-is out of the box.

  15. BullShit-Detector says:

    Hi Karl,

    what a load of arrogant, self-righteous crap:

    ‘should you infer that ASP.NET WebForm forces you to build applications the wrong way? Yes, you should.’

    Obviously written by someone who is out of touch with the reality of developing software for a living.

  16. Parag says:

    I agree with you Karl. To give you example of why we should learn and adopt MVC is : What happens to webforms when HTML 5 is popular suddenly (with IE 9 around, I have no doubt even Microsoft will move in that direction). All those custom/3rd party webform controls and even some of Microsoft’s own components like GridView will take some time catching up.

    It goes beyond saying that even as of today any one that has anything to do with Web Development must know ins and outs of HTML,CSS and javascript.

    I am not saying Webforms is bad, but I don’t see any reason why I should start anything new in that. Picking up MVC is extremely simple for experienced Web forms guys. I myself did it in a week :).

  17. Simon says:

    “Would you consider generating your HTML from a stored procedure?”

    What’s so wrong with this??

  18. Onur says:

    “The counter point to that is that WebForms is essentially impossible to unit test. This also understates the architectural superiority and design of MVC ”

    Oh yeah ? And apparently you never heard of MVP pattern.
    At least in this post you are not cursing as your previous MVC , Webforms post

  19. Dan Martin says:

    @Eric

    Same here. I’ve been using MVC a lot lately and web forms are pretty bad. I know a case can be made to use them in certain situations, but right now I want nothing to do with em.

  20. Eric says:

    I’ve been slowly coming to the same conclusions as you, and every day I spend working with MVC I love it (MVC) more and loathe Web Forms more.

    I ranted about my love/hate affair with Web Forms a couple of weeks ago:

    http://blog.devadept.com/2010/02/abstractions-abstractions-pile-them-on.html

  21. Andrew says:

    Wayne,

    More often than not, that sort of thinking leads to no good. It leads to very thick web clients which are buggy as hell, take forever to load (due to about 9 pages of ViewState) and results in a maintenance nightmare.

    If your client/customer/management wants a think client, why not just propose one? A website is a website, it can have some client side goodness (basic validation, etc.), but if you find yourself getting requirements like “Make the grid act just like Excel”, then its time to step back and realized that maybe the web should be used to launch a Winforms/WCF/Silverlight application, not do a poor job in implementing a thick client.

  22. Ah, while I’m firmly in the MVC camp myself (works for me is the only argument I need), I think your point number two calls for comments.
    The point of web controls is not to hide the HTML away. That has always been fallacious: if that were the intention, how about the rest of the page? Why isn’t the whole of WebForms pages written in a language that’s not HTML?
    No, the real reason is to provide higher level abstractions than div and input. Granted, there are more modern approaches now but by claiming that it’s “insane” to think controls generating HTML have any advantage over plain HTML/CSS/JS, I think you are building a straw-man, among other logical fallacies.

  23. Wayne Molina says:

    @Troy:

    I agree, but your average corporate developer doesn’t want to learn jQuery, they really do want to drag+drop some third party UI, make a few changes to the properties via a wizard dialog, and be done with it.

    @Karl:

    Agreed as well. I’m learning ASP.NET MVC at the moment, but most of the jobs I’ve seen/applied for/talked to others about are still heavily WebForms.

  24. karl says:

    @Wayne
    I’m on the fence….I’ve seen that shortsightedness for intranet “thick client” apps bite people many times. I hear the same argument about silverlight, and I’m just not a believer.

    @peter
    Can you redistribute system.web.mvc.dll now or not? If not I agree its a problem.

    As for speed, YMMV, but i know I’m faster now on MVC than I was at my peak on WebForms – but that might be due to other, unrelated growth.

    I still think my myopic stances makes for better reading, and results in more meaningful discussion. Its certainly fun to write.

    I know django well enough…and I do like it.

  25. pete w says:

    How do you create a setup wizard for an MVC web app that installs to IIS 6?

    If you have a well-built existing app and you need to build out a web interface as quickly as possible, do you think you can write it faster in MVC than a few web forms and some devxpress controls?

    I’m just playing devil’s advocate, but my point is both of these tools should be taken into consideration.

    I respect your writing and expertise, but sometimes you take a very extreme myopic stance, such as “dont use try/catch”.
    If your standpoint on web apps is based solely on cleanliness, then you should look at django or turbogears, which are far cleaner than MVC.

  26. Troy Goode says:

    Wayne Molina:

    “make use of a lot of VERY nice third party UI components”

    There are a whole lot MORE UI components built in server-agnostic client side libraries like jQuery that will be much easier to use when developing with MVC.

  27. Scott White says:

    Sure Microsoft has to defend this antiquated paradigm of web programming that many of their products (which are as antiquated as WebForms… cough: SharePoint) use.

    I’m actually somewhat surprised that something like ASP.Net MVC could actually come from Microsoft however to be fair there was a lot of collaboration with the community. Actually Karl was being easy on Microsoft.

  28. Wayne Molina says:

    I still maintain that WebForms are good for developing what would amount to a thick-client app (e.g. a Corporate CRM or Time Tracking system) because you can do it relatively painlessly and make use of a lot of VERY nice third party UI components. To the average corporate developer these are good things.

    ASP.NET MVC is better overall because of the flexibility and control that you get, but there are situations where that flexibility doesn’t really matter, and RAD/using those $1K controls the director bought is the concern.

    As always, both are tools and one isn’t “better” than the other. I daresay that for the majority of professional .NET developers out there, and the majority of .NET work, WebForms are the preferred solution over MVC.

  29. Andrew says:

    There goes Karl again, bashing Microsoft.

    There, just wanted to get that out of the way because a comment like that will be coming sooner or later. :)

    Can’t say I disagree with anything you said, I guess I’m just surprised that http://www.asp.net would put this video up on their site. Common to run MVC alongside Web Forms? Sure…

  30. Ben Taylor says:

    While I agree with your overall conclusion (ASP.NET MVC is overlapping and superior), it is not the case that WebForms apps have to be untestable or (always) about “hacking things until they work”. We are happily testing and running a large webforms app using our own simple MVP framework and the Readify guys in Aus are doing the same with their http://webformsmvp.com/ framework.

    IMO – A lot of the crap that was done with WebForms historically was because as a community we were still writing crap procedural code. Pre-SOLID, pre-IOC, pre-ProperOO (POO?) :) And yes, I know the WF framework does not make achieving these things easy.

    Again, I’m not being a WebForms apologist. I think the WebForms abstraction is an abomination and I would never personally use it again when given the choice. However, it is here to stay as we all know MS are not going to say “Actually, yeah, webforms suck so all your investments are worthless” anytime soon (regardless of privately held opinions). In the meantime we need to help the folks still in WF land (and there are a lot of them stuck there).

  31. Anders says:

    I couldn’t agree more with all of this. I have always disliked the arguments that WebForms is something good just because it “kinda sorta” resembles WinForms (which is a lousy WIN32 wrapper and should never, never ever, be used, now that WPF exists).