MVC vs. WebForms, A Clear Loser Emerging

Working with WebControls and WebForms for the past 8 years has taught me a lot about web development.  The one thing that I learned above everything is that the onus is on the developer to write good code.  Now that may not sound like something revolutionary, but the fact is that ASP.NET WebForms makes building web applications easy by abstracting away some of the difficulties of a stateless protocol.  And it also makes it easy to forget about what’s actually happening behind the scenes to make everything possible.  Does that mean WebForms is flawed?  No.

MVC offers a fix for some of the problems that WebForms has been plagued with.  Problems like bloated ViewState, and that ‘pesky postback model.’  On the surface, this looks like an attractive solution for every web developer out there.  A promise to get rid of ViewState – a web application’s mortal enemy?  It has to be good. That is until the application your building needs some sort of state mechanism, and you begin re-inventing the wheel.  I think it would have been much easier just to go back to you WebForms application and disable ViewState. 

The problem right now is that there is so much focus over why MVC is better than WebForms, that everyone is forgetting a basic rule of software development: use the right tool for the job.  I’ve said it dozens of times, MVC has a set of scenarios that it first very nicely, as does WebForms.  One platform does not need to be declared a winner – they’re two equals that should be placed into your metaphorical toolbox.  So who is actually losing right now?  The developer community that is caught in the middle of this faux war.  Developers who think that they have to move to MVC out of pride or fear that WebForms will be replaced by MVC.  Developers who are only hearing one side of the story right now at local community events and tradeshows because let’s face it.. WebForms isn’t sexy anymore at 8 years old.  Ironically, this same issue of “sexy talks” was discussed last week at NDC with Scott Hanselman behind the camera.

Conferences aren’t picking talks about “the old stuff”, because they’d rather focus on what’s new.  New is sexier, and conferences are all about attendance numbers.  But here’s what these conferences don’t seem to understand – every day there’s a new developer joining the community who needs to start from zero.  Developers gauge what’s important by what’s being talked about, it’s why we have trends and tag clouds.  It’s human nature.  If I hear 100 people talking about a subject, it must be important.  Right now I hear 100 people talking about MVC, and no one talking about WebForms, so I guess MVC is more important, right?  That’s the type of thinking happening right now, and it’s nothing new.

“MVC brings web development back into ASP.NET”, is one of the most common arguments I hear for its use.  Yet the whole reason for WebForms existence was to free you of the dirty details of building a web application, and let you focus on your business logic.  To give you a set of functionality to be able to build on top of, the same focus for every library and framework out there.  It’s why you don’t have to write browser specific JavaScript when using jQuery or ASP.NET AJAX, and it’s the reason we don’t still program in machine language.  Can I write a tighter loop in assembly than I can in JavaScript?  Sure.  But for the applications I’m writing that’s not going to be an issue.  Maybe I’m writing an application where performance is the top and only concern.  Now writing the application in assembly doesn’t sound like a crazy idea.  If my requirements were to build a spreadsheet like application that offers filtering, copy and paste and exporting to excel, I’m going to jump to WebForms.  That’s the whole point behind using the right tools for the job. 

I read a blog post today that talked about how you should dump WebForms and go with MVC as soon as possible, so you can get back to web development roots.  The argument just didn’t make sense to me.  It’s like asking me to stop coding in C# and move to C++ because C# developers just don’t understand pointers and memory allocation. 

So here’s my call to action.  Rather than talking about why one framework or platform is better than the other, start discussing when one is better than the other.  What scenarios is MVC geared for?  When would you use WebForms (MVP) instead? 

The best advice I’ve seen so far is that WebForms is the platform of choice for building web applications, where MVC is more suited to building web sites.  This is still a bit abstract since there’s no clear definition of web applications, but I think it’s safe to say that if you’re building a web version of a win client application, you’re building a web application.  If you have a ‘grid’ in your page for purposes above that of just layout, you’re building a web application. 

56 Comments

  • The undeniable fact about webforms were that they were designed to abstract scarey html and javascript away from existing vb6 developers who didn't want to learn web programming.
    ASP.Net Ajax was Shoehorned on in order to keep the old dog going and has never felt like it really belongs. If you already have a command of Html and Javascript then webforms can feel like bloatware that gets in your way.

    I believe that a new MS supported framework was needed. I'm not sure MVC is it however.

  • I think you hit the nail on the head. All I hear about is MVC. When developing business applications, I feel like we spend half our time just throwing up a utility that allows somebody to upload, edit, or download data. MVC is totally overkill for those types of things. Also, for those that invest in learning webforms, being able to develop your own toolbox controls can be a huge time-saver in the long term. It doesn't seem to me that MVC promote such componentized code re-use.

    While I agree with Dave that ASP.NET Ajax doesn't really feel like it belongs, it is useful, and can make "ajaxing up" an existing application a snap. If you're building static website, then yes, webforms can feel like it gets in the way, but for constantly evolving business applications, I can't see how you could survive without it.

    For those who just like to complain about ViewState, I offer the following:

    http://msdn.microsoft.com/en-us/library/system.web.ui.sessionpagestatepersister.aspx

  • Oh my goodness, where do I start.

    Firstly, ASP.NET MVC is, hands-down, better than WebForms for advanced developers. The WebForms model was great 8 years ago when developers really wanted to develop for the web in the same way they wanted to develop for windows. Microsoft thought they could abstract away the fundamental differences between the two platforms. I think they were successful at their goal, and developers were happy.

    But, inevitably, web applications got more and more complex. That's when the cracks started to really show in WebForms. In order to push the boundaries of web applications, developers needed to get at the guts of everything. We needed total control. And the tools needed to help without sacrificing that total control. The goal of abstracting the web into something it wasn't turned from being an asset to a giant pain in the ass.

    To compound on that, AJAX took the web by storm, and ASP.NET WebForms was *NOT* a framework that helped developers during this paradigm shift. Just think of the first incarnation of ATLAS, especially the UpdatePanel. Once again, it seemed like microsoft wanted to abstract all the complexity away in exchange for making things easy. This time developers rejoiced for all of two seconds before realizing what a mess it was to use the Update Panel for anything even remotely interesting (or maintainable).

    At some point, the guys at 37Signals created ruby on rails, which built a framework and tools that embraced the web for what it was, and embraced AJAX for what it was going to be. Their success is the reason why we have ASP.NET MVC, which follows the same methodologies.

    So now we have a choice. And I am the most thankful developer on the planet for that choice. My career started with .NET 1.0 Beta, and I've always wrestled with WinForms, especially on complex applications. Since MVC came out, I've been using it and enjoying every minute. It's like developing without handcuffs.

    Sam

  • @Sam

    Well said. Webforms definitely had its purpose, and now that there is a flood of .NET web devs, it's time to graduate away from postback model, among other bandaids in the framework.

  • I prefer to use MVC, even for Web "Applications" for three reasons.

    1. When designing complex UI the Property/Method/Event model that WebForms uses ends up getting in your way. You are forever chasing events and hoping the right thing will get called at the right time to cause some magic to happen like a grid to get formatted or a value to be updated. It was the same problem I had with Delphi after a while. Event Spaghetti is what I call it.

    2. For an experienced web developer who knows the difference between a POST and a GET and isn't afraid of writing some JavaScript then MVC is much more productive. It is hard to believe that manually writing HTML for a web page can be done much quicker than using visual tools, but it is the case.

    3. The average developer doesn't understand things like trying to separate business logic from presentation logic and database logic. They just started coding and see where it takes them. MVC at least points them in the right direction.

  • I generally find it a lot easier to develop applications using MVC.

    Last week I was modifying an existing application which uses the ASP.NET AJAX stuff. I needed to be able to do a postback from a checkbox in a datagrid to turn the indicated row on or off.

    In MVC using jquery, this would have been about 5 minutes work. Just add the checkbox input with a jquery statement that does a call back to our MVC controller with the appropriate path and inputs.

    With ASP.NET AJAX, first I spent about an hour finding out how to do it on google, then I had to write some custom javascript, then I had to make sure I added the ajax httphandler in place and configured pagehandlers. Took me most of the morning to get it working right and testing the configuration.

    And this doesn't even begin to get into the thousands of examples out on the internet using custom ajax functions written for jquery or some other javascript framework that just flat out work out of the box with MVC but require hours of monkeying to make work with the ASP.NET AJAX. Why not benefit from everything PHP, Ruby or whatever developers do? Why be different just for the sake of being different?

    It's actually the datagrid stuff in asp.net webforms which has caused me the most pain over the years, like my example. bloody databound events and what not to customize the display. Bleah! Just give me a for loop and I'll emit the HTML myself. Far easier to deal with for non-trivial examples.

  • My one year old post on MVC Vs Web Form http://weblogs.asp.net/shijuvarghese/archive/2008/07/09/asp-net-mvc-vs-asp-net-web-form.aspx

  • 100% agree with you, i share same sight to this new model2 wave.

  • Tony, excellent post. I agree with you in full 100%.

    Thanks for posting this.

  • I have not bought into the MVC 'hype', I have seen nothing there to really impress me, yet. Just some new shiney toy to play with. What I have grown tired of is bloated pages generated from Web Controls, etc. So I finally made a concerted effort to put into practice something I wanted to do for several years, create the UI with HTML and CSS. Not using MVC, just using the same ole ASP.NET foundation I created over 300 production sites from the last decade. I just stripped out the web controls and I love it. Face it, if you are going to implement MVC you have to learn these principles in the first place, but sadly MOST MVC zealots are not going to take the time to really do it correctly.

    Anyway, you can follow my series as I add new entries: http://professionalaspnet.com/archive/tags/Thin+ASP/default.aspx

  • @Sam, @Sheldon - Abstraction leads to progress. That wretched UpdatePanel that you speak of solved a problem that 80% of developers were trying to solve, and did it gracefully. Admittedly though, it is one of the most overused and abused controls out there. But to me, WebForms is all about the common (80%) development tasks easier. By making those tasks easier, developers can focus on the real problem like business logic. As Sheldon mentioned, for the simpler grid scenario, spitting out HTML is easier, and I agree. It's when you get to the more complex grids that mimic Excel like functionality that WebForms becomes irreplaceable. Are there scenarios that MVC makes easier? Certainly. The key is to use the tool that fits best, and use it the way it was designed.

    @Craig, thanks for sharing your list of MVC Strengths. There's no doubt that MVC makes separation of concerns a top priority, and I too grow tired of event spaghetti. In the end, these are the types of tradeoffs that need to be weighed when choosing between WebForms and MVC, and will likely change from application to application as the requirements change. As @mhildreth said, for the apps he's building, the MVC separation of concerns is complete overkill.

    Thanks all for your great comments!


  • @docluv - Being a developer who wrote some of that bloated web control markup, I can tell you that I'm entirely with you on the need for clean and concise markup. The problem has always been the disparity between browsers, and coming up with the least common denominator. Sadly, 7 years ago that meant tables for everything. The Dark Ages of web development.. Luckily browsers are getting better, and WebControls are being updated. Hopefully the HTML bloat will be a non issue soon. I know at Infragistics this is one of our top concerns.

  • Tony,

    There has been a lot of discussion going on about when to choose one or the other.

    WebForm is still great if you have to build heavily datadriven apps, or if need a RAD development, if you are building a prototype, or you have to rely on the component model, either because you need to (a la sharepoint portal, with webparts) or because you deeply invested in control libraries (either custom or 3rd party).

    ASP.NET MVC is better if you have a TDD approach, if you want finer control over HTML markup, if you care about writing good code and if you want a more strict guidance for doing it.

    Yes, I'd also say that your distinction is fine: if you want to build a web-version of a winform app (a CRM or a ERP) without using Ajax, go for WebForm. If you are building a public facing website, (CMS, e-commerce, government sites, and so on) go for ASP.NET MVC.

    In addition to this:

    the C# -> C++ vs WebForm -> MVC is not correct.

    Now nobody cares about pointers and memory allocations because now PC have loads of memory and because compiler are getting the job better than humans.

    The same is not true when it comes to HTML: broadband is not "enough", and unfortunately the "HTML Compiler", which is the WebForm control, is not good enough to replace the human in writing markup... and unfortunately browser are not good enough to render crappy HTML correctly.

  • -- Simone Chiaretta
    unfortunately browser are not good enough to render crappy HTML correctly.

    Au contraire. Browsers, IE in particular, are very, very good at rendering bastardized HTML. This is the single most important reason why web-form lovers believe web forms are the best thing under the sun. They've never had to worry about bastardized HTML emitted by web-form controls. :-))))))

  • @foobar: you are right IE tries to render everything... but unfortunately it renders it in its own way...
    given the recent decision of dropping HTML support from Outlook, I guess MS could make webforms emit a Word document... IE9 will probably be Word 2012

  • This is one of those things where I almost got caught up in the hype. I started researching MVC and it was great, however it also comes with some challenges over web forms that many people who are on the MVC bandwagon don't advertise too much.

    For example, one of the biggest challenges for us is maintaining web part integration..something you still need WebForms for (or at least a partial MVC/WebForms split). I want to see how well this is also supported going forward in enterprise web applications Microsoft offers like SharePoint.

  • cool. These are the same conclusions I came to myself. MVC is nice on paper!

  • -- alessandro
    >> microsoft has been quick to fix it and these are all fixes we get for FREE

    You're deluding yourself. You pay for AspNet indirectly. If you want to run your AspNet-based website you have to have Win2k3 or Win2k8. And you must pay for it.

    >> many new enhancements on the way for webforms

    Again, you're deluding yourself. Microsoft will never abandon its support for web forms, but it's not going to keep sinking any significant money in web forms either. Microsoft is betting on Silverlight. And that's the technology web-form adherents should be looking into.

  • You said it all!

    I only want to comment on the comment that "WebForms is for VB6 developers who don't want to learn web and Javascript."
    That statement falls apart as soon as some "web and JavaScript" guru faces the development of a true business application. He will either fail to deliver, or if he's really good, he'll end up reinventing 99% of what WebForms brings to the table.

  • A very fast search in the article+comments on words like "test", "architecture", "pattern" makes me totally surprised !

    All the debate is about comparing two technologies ! But it SHOULD be about comparing two architectural patterns (Page Controller + Template View vs MVC) !!! And, effectively, you choose one of the patterns in different situations !

    Why I will certainly not use Webforms anymore is because of the complexity induces by the ASP.NET lifecycle, which is totally unuseful, except for handling stateful components, and the testability of the framework.

    Can anyone inject dependencies in pages in a simply manner ? (Yes, I know about Spring ! I've used it !) Can anyone simply unit-test every event handler of a page ? Can anyone simply mock any dependency of a web page ?

    So while testability, and so maintanability, is the primary priority, yes, MVC is the best choice you would ever take. But ASP.NET MVC is more than that ! ASP.NET MVC is about scaffolding.

    Tony you should really make a deal with one of your friend who knows ruby on rails, and try to beat him in developping a webapp efficiently. Even with complex ASP.NET components. You would be very impressed... unless your friend is not aware of RoR, or if you have blind eyes ! :)

  • Tony, GREAT article. Honestly I'm kind of shocked at how quickly some of the webforms zealots have flocked to MVC.

    I remember switching from Classic ASP to .Net webforms thinking about how crazy it was to try and break away from the basic GET and POST concepts, and get into the whole postback thing. Meanwhile people at conventions would hold their nose up and scoff at the old school ASP developers. Now it almost seems like the old Classic ASP development is back, especially if you compare it to the old COM WebClasses model.

    I've made plenty of websites in both MVC and webforms, and I absolutely agree that the two can coexist as tools in the same toolbox.

    Just another religious war for the programmers. Ignore all the shouting and pick for yourself.

  • This post is one of the best viewpoints I've seen on ASP MVC and it has helped to solidify it for me. After doing a years worth of Ruby on Rails off and on as well as .NET web forms, I'm convinced that MVC is a better solution for web sites while web forms is an excellent solution for web-based applications. And I define a web-based application like this...

    If the solution would work as well in client-server form but web-based is chosen for ease of access and distribution, then it is an application.

    (BTW... you don't have to use an MVC solution to do MVC designs.)

  • hello. sir, i am actually working on a thesis entitled "significance of using MVC Framework in developing a web based application"
    is you do have some idea on what parameters should i use in order to measure the data retrieval performance of the web application, please please do let me know...
    please email me at engotzz_16@yahoo.com

    please help me, i am a 4th year computer science student, and i would really like to graduate this school year.. please please help me.. if you can recommend soem other experts on the matter, plwase please tell them just email me.. thnx

  • I know that this is quite an old topic now but I had to post.
    There was a user back in July that said "MS will not sink significant money into win forms" to this I must point out that
    a. Win forms is currently dominant - and is likley to remain so for some time.
    b. MVC.NET is built *ON TOP* of win forms.

    I agree 100% with the article use the right tools for the job - I find it quite amusing that > 95% of the comments miss the point of the article and are all bashing one method over another...

    Ill use win forms or MVC depending on the app...


    One last thing: to the poster that said (Regarding the datagrid control) "give me a for loop and let me emit my own markup" - - -
    All I have to say to that is: Emit me a sortable, editable, pageable table that supports inserts...
    Do it with less than 10 lines of code...
    And then for a laugh put that into a format that I can share between pages/projects (ie web control)

    Before bashing me - please note my line above - Im not saying win forms is the be all and end all - but it has its place.

    PS. I like events.

  • My first impression of Webforms was "it sure is easy to put a page together, and it sure is a pain to debug". With MVC, "it sure is a lot more work to put a page together, but is sure is easier to debug".

    MVC is harder to learn in my opinion. You have to grasp the entire concept, where with Webforms, you can muddle along.

    I'm going to use both depending on the job. If it is a quick and dirty project, where I need to get it done as efficiently as possible, I'll use Webforms. That's how you make money, and can compete. If it is a big project, that I'm going to have to maintain over years and years, I'll use MVC. MVC is more loosely coupled, and easier to maintain and modify. Also if I have a customer who is especially picky about the way things have to look on the page, I'll use MVC.

    Silverlight is another option now. I'll look at that when Visual Studio 2010 is released.

  • I don't have anything against a developer who wants to only use Web Forms. Each project and developer has contstraints you cannot make hard and fast rules about.

    I also have nothing against developers like yourself that have chosen to use both Web Forms and MVC depending on the project.

    What this article fails to understand is that there are developers like myself that have made a decision to only develop in MVC and never use Web Forms again. I build both large and small business applications (with the help of my team of developers). Web Forms get in my way by trying to help me. How can you say I am wrong for making that decision just because it does not match your decision.

    For new developers I would recommend that they learn MVC first. Then learn Web Forms as needed.

    Also, Telerik has a nice grid for MVC that is open source.

  • It seems that the development time for MVC will much be longer then for WebForms for an average web application. I would use MVC only for a very specific purposes.
    This question is similar to the endless WinForms vs. WPF.

  • G.S:

    "He will either fail to deliver, or if he's really good, he'll end up reinventing 99% of what WebForms brings to the table."

    I must be amazing then, what with my ability to not only deliver successfully almost 100% of the time *and* have managed to do it without reinventing the WebForms wheel. Don't worry, I'm happy to come help teach you how to do this too, since it appears to be a mystery to you!

  • MVC has really allowed up to improve the look & functionality of our front ends. We were able to hire two superb front end devs that don't come from an MS dev environment.

    People always mention separation of concerns, testability, etc when talking about MVC. But for us the biggest plus for MVC has been letting our front end people go-to-town on an app without them needing to have WebForm knowledge or risk of them breaking something.

  • Good is good, but better carries it.

    -----------------------------------

  • Just want to say what a great blog you got here!
    I’ve been around for quite a lot of time, but finally decided to show my appreciation of your work!

    Thumbs up, and keep it going!

    Cheers

  • -----------------------------------------------------------
    "Virtuous what I used to be searching for and fairly thoroughgoing as surface. Many thanks for placard this, I saw a yoke various associated posts but yours was the optimum up to now. I outlook it stays updated, really like dread."

  • I prefer to acquire breaks throughout the my working day and appear by means of some blogs to view what people today are stating. This blog site appeared in my searches and that i could not help but clicking on it. I'm glad I did simply because it had been a really pleasurable learn.

    --------------------------------------------------------------------
    Electrical Engineering

  • I honestly can't understand the huge deal with MVC. Yes, the large ViewState can be a pain, but I had already found a way around that. In my web forms I have [WebMethods]. This is MS's really easy way of getting POST data from $.ajax requests. I've already been using these to pass JSON objects to my pages to avoid always having to pass the ViewState. When I pass the ViewState, it is always in preparation to re-render large parts of the page with updatepanels. The display logic was handled in the code behind.

    And my code-behind contains no SQL queries. I have actually created by own objects that have properties and can be saved/edited/deleted. I actually wrote these myself, without an ORM. These objects are edited in my code-behind.

    After spending some time with MVC 3, I have to say that I'm not sure I can really find a huge advantage. My controller (the page behind in my case) was already just working on the models (my objects) and rending my .aspx page (view) with various partial renderings (my user controls). I guess I just don't see the huge difference.

    Now I have a controller class where all my page behind code has moved, my models are the same, and my views have partialviews. One thing I do like is that component model attributes for validation. However, according to the previous link this is about to get incorporated into forms.

    Another issue I have with MVC, and this just might be my newbishness, is what do I do with my parent view that has child views that need complicated data and I want to use intellisense? If my page contains views that require 3 different typed IEnumerables (say one for navigation and two in content for selected and possible), do I have to dump all of these in a ViewBag or write a wrapper for them? I've done the wrapper to get intellisense, but this could leave me with a ton of classes that I don't really want.

  • Thanks for this article. I've have just come to the decision that it's time to learn MVC. More than any other reason, it's because I've been rounding up consulting work and felt awkward saying I don't know MVC, when many people I've talked to said they prefer it.

    However, I have a feeling I might like it based on 1) WebForms is sometimes a bit too high level for me (I ended up writing lower-level stuff to gain more control), 2) although GridView is useful, I've always found it a little cumbersome and too abstract from what's going on underneath for my liking, and 3) I love the clean HTML MVC produces.

    I always seem to be running behind. I've been so busy, it seems like I just barely got comfortable with WebForms. I've been a developer for over 20 years and I didn't like my first look at MVC because of the way it mixes markup and code. However, Razor helps here a little and I think it's time for me to make the jump.

  • You know I came across your post after watching MIX 2011. You are 100% correct. New technologies is what conferences are for. I have been developing with ASP.NET since 1.0, 1.1, 2.0, 3.0, 3.5. After you have great patterns and practices in place web development for APPLICATIONS is a snap. I think I will be sticking with Webforms.

  • Mvc vs webforms a clear loser emerging.. Awful :)

  • I have developed in asp.net for years and have had great success. The author's that diminish this technology appear to be entry level developer's who know little or nothing about OOP and how it is nicely applied to the event model in asp.net to produce powerful frameworks that can be used again and again.

    The worst comments I hear for MVC "its pure" seem to be written by web graphic artist types that think that once they complete there html markup the job is done!! What a pathetic joke.

  • Is viewstate still an issue. Sure, I've seen some forms where people have added controls dynamically ad-infinitum that result in 500kb of viewstate, but generally, in my day to day work it doesn't really get in the way of what we do. I had a look at MVC and it seemed kind-of basic. I think people are jumping on the bandwagon as it seems the cool thing to do. Not knocking it, just saying....

  • “MVC brings web development back into ASP.NET”, is one of the most common arguments I hear for its use. Yet the whole reason for WebForms existence was to free you of the dirty details of building a web application, and let you focus on your business logic. "

    This sums up how I feel about it quite nicely. Why do I want to go back to the drudgery of hand coding HTML/Javascript? It seems like a step backwards.

  • I've used both and have to say web forms is a better rad tool, with rapid development being the goal. MVC is better when many people are working in the same app (a little better). This is just all snobbery mostly, with MVC you can fool yourself your more advanced even though your making your client wait longer for product, reminds me of the vb vs c# debates. Intelligent web forms with good understanding of view state etc and good third party tools is the way to go in my opinion, if you care about time to market.

  • I really liked the article, and the very cool blog

  • I read until line 13 when you misspelled "you're" and that's as far as I would let myself go.

  • Thankfully some bloggers can write. My thanks for this piece of writing...

  • After working 4 years with asp 1.0 and 3 years with asp.net web forms, I believe I developed good programming practices that allow me to produce better products on the web, and I intend to stick with web forms since the most important thing to me is to be able to deliver faster because that's what makes my boss happy and willing to increase my salary each year!


  • The problem with web forms is that a lot take place under the hude. The page httphandler loads the layout, creates the logical tree 'visible and hidden for html literals' of controls, iterates them to make them work ..loads state, read post data,set properties, raise events etc. It is like a world running side by side your implementation just to give you the feel of non http based communication system.
    It is not an expected flow. And for those that support the use of mvp or mvc patterns, i say that it will not change the fact that controls written by others will still do their job as authored. You will just have changed the way you set the datasource prop!
    m
    Mvc on the other hand only automates/hides the action's model binding, something is not only practical but easy to modify.
    Web forms are just like automatus forms that we all dream.
    It is also an exaguration that i have also followed for years and when mvc will cover the lack of build-in ui, well we should never ever try to automate business!

  • Read through all the comments and thought people would actually discuss what the author asked to discuss. Instead it gets in to yet another battle and defending ones decision. I sincerely wanted to read about what application scenarios the different .net platforms would be best. I am ASP.NET WebForms... And I read about how ASP.NET just gets in the way. I personally very rarely have had that happened. Right now I am dealing with "old" classic ASP(yes in 2012 I am dealing with classic asp). And I miss my WebForms. Made things alot easier with events and RAD. I miss using it. But I am going to have to ReDevelop this app in .NET (hopefully if I ever get the time) and I am looking into which one will be faster to develop. Allow for the greatest complexities. Because when I did tried MVC it seemed to me that it wasn't meant for a complex web application.... O-well I will go search else where...

  • Thanks for the article, and for all the blog posts.

    I have a web-developer education, and next a programmer education.
    Most of my friends friends from the web-developer use web-forms because its easy and most is done behind the scenes, and you have that wonderfull drag-and-drop toolbox.

    What i take from that, is that web-forms does alot for you so you dont have to write your own code or learn alot of new stuff.

    I dont have much experience with web-forms other than trying it out and helping my friends.

    From a programmers perspective the separation of logic and presentation is crucial, so web-forms out of the box is out!.

    The best way to accomplish this is by using a pattern (MVC).
    This ensures that your web-application is both maintanable and scalable.

    The choice then is about whether to choose MVC2(web-forms) or MVC3(pure html, javascript, css and razor).

    If you are familiar with web-forms then you can stick with that and use MVC2.

    If you are a skilled programmer go with MVC3, there no toolbox and all basic stuff about layout(lists, buttons, forms etc.) are up to your fantasy to build. MVC3 commes with a large helper library that lets you do advances stuff with easy and still maintain full control over how your html is produced.

  • I love the comment that we are really talking about patterns.

    I like webforms for all the same reasons mentioned above, I implement MVP to make sure my code seperations its concerns properly. This is something that the MVC developers seem to think is limited to MVC.

    At the end of the day I love this article, they are both tools and in what I do time to market is key. if my viewstate is a little bloated... meh. my clients want to see desktop feeling applications in the browser and I give it to them.

    As developers we are here to give our clients what they need based upon thier business requirements and if we dont give it to them we fail. So if we focus on what the customer wonts (stated and implied needs), apply the right tooling then we will succeed.

  • WebForms makes it easier for novice programmers to create a project that becomes unmanagable and html/css/javascript that is a bloated, mangled mess. But, after 10 years of WebForms experience, I'm in a position now here I can actually create very clean projects that are propertly architected and that renders clean html and uses CSS properly, mixed in with some nice clean jquery.

    I've also done a handful of MVC projects, and the first thing you notice is that the developer is neatly forced down a path of better architecture and seperation.

    For someone who has a lot of experience with html, css and jquery... you're going to create your html, css and jquery in a similar way whether you go down the WebForms route, or the MVC route. You're not going to abuse all the shortcuts and pretend-windows-application-development features that WebForms puts at your disposal.

    To me, it becomes a choice between how much the project is "web site", and how much it is "online business app". I tend to lean towards web forms for "apps", and MVC for "sites". That said, I'm currently building a bunch of pure public facing sites using WebForms. I guess it just depends on what I feel like on the day.

  • I've been writing software for 32 years. I cut my teeth as a web programmer before the first browser was released.

    MVC has been around for a long time - since the 1970s. What hasn't been mentioned is that WebForms is an implementation of the MVC pattern:

    Model - your data objects
    View - your HTML code
    Controller - your code-behind for web forms, your controller class for MVCx

    As for my opinion of MVC (MVC3), I was excited at first to try it, but ultimately it was more painful to use during the development cycle for a massive application. MVC3 was sold to me as being fast to develop, even though it was a logical solution, it wasn't faster. I'm hoping MVC4 is fixes the issues we encountered.

  • For those saying stuff like "well, there's silverlight now, we should be investing in and looking at that" I would say "Um, don't pull the trigger just yet. My sources within MS tell me that the latest version of silverlight will essentially be the last." To the average joe, Silverlight is really just flash and you can't even run that on an Android anymore. So, I wouldn't worry about learning silverlight...personally.

  • If you desire to get a good deal from this paragraph then you have to apply such
    methods to your won website.

  • I dare you all to quickly create MVC project, put a grid on it and bind it to a data table in C#... lets see how much time you spend on that vs. WebForms.

    The problem is... the moment I opened my visual studio in MVC project and there were no controls to drag and drop.

    Now, if someone pays you per hour, which model do you think that someone would like to follow.. ???

  • What's up Dear, are you actually visiting this site daily, if so afterward you will absolutely obtain nice knowledge.

  • Regarding the coining of "web-sites" vs. "web-applications" - where does a high traffic website like Amazon fits in? Is it a web-site? (Like the classic "online business card" back in the 90's?
    Or is it an application?
    I'd go with the latter, but MVC has just a nice bunch of features, while Webforms is really RAD oriented...

Comments have been disabled for this content.