The WebForms Rant

Ever since ASP.NET MVC was announced/released, there’s been a lot of talk about it with respect to ASP.NET WebForms. People want to know which technology they should use, and are likely confused by the fact that there isn’t a consensus amongst respected developers with respect to which of the two is better.

Ideally every developer would take the time to truly understand ASP.NET MVC and compare that with their WebForms experience to come up with their own opion (and even more ideally we’d all largely agree on the pros and cons). The reality though is that some developers don’t have the time or opportunity to take the necessary time to learn a new framework. If we are being completely honest, many developers don’t have the necessary skill to accurately judge two competing technologies – maybe they are casual developers, maybe they are new to developing; maybe they come from a different technology. There’s nothing shameful about that – in fact, that’s how most of us learn.

With that said, should you be using ASP.NET MVC instead of WebForms? The short is: continue using WebForms for any existing projects that you have that are working well (you can define for yourself what “working well” means). Use ASP.NET MVC for any other project.

The long answer is the same, except it uses the word “stupid” and “idiots” a lot more. Here goes…

So-called experts who claim that ASP.NET MVC and WebForms serve two different purposes are stupid idiots. Seriously. They are both web frameworks, capable of producing the exact same systems. You could build a digg, facebook, twitter, joomla or any other website using either technology. What makes one (ASP.NET MVC) better than the other (ASP.NET WebForms) isn’t where you can go, but rather how you get there. ASP.NET WebForms is an ugly and messy framework that complicates an otherwise simple thing. ViewState, codebehind, postback, page lifecycle and databinding are things that you have to constantly program against. They don’t help you; they just slow you down, slow your site down, and make it harder to change things in the future.

I’ve known programmers who thought that complex frameworks were required to build complex systems. I also know programmers who think you can just duct tape anything together. The truth is so much simpler, and so much better, that both those groups of programmers are idiots, and in fact can’t really program. Simplicity is the only way to build simple or complex systems in a clean and timely manner. Build a system too complex, and it’ll cost a fortune and be too rigid. Build something too quickly and shitty, and it’ll break and won’t be fixable. ASP.NET WebForms, along with ASP.NET Ajax, was clearly built by people who believe that complexity can solve all problems. Postback with server side events is such a poor solution to what’s a really simple problem. ViewState is a solution to a problem that doesn’t even exist (which makes it infinitely complex).

When WebForms first came out, developers were overjoyed that their tangled code and html were a thing of the past. We were so stupid not to see what mess we were getting involved with (I’m sure some did). Get it through your head people, having ASPX pages loaded with non-html or javascript is an equally horrible situation to be in. Take your most complicated ASPX page and give it to someone who knows HTML (but not ASP.NET) – if they can’t understand it (which they won’t) or think it looks ridiculous (which they will) then you’re doing something wrong. Just because you are coding with angle brackets doesn’t make it clean code.

Pro-WebFormers like to use a scare tactic to make sure developers don’t switch to ASP.NET MVC, they claim that ASP.NET MVC is suited for Test Driven Developer (TDD) specifically, and unit testing in general. This is a scare tactic that relies on the growing divide between those who do and those who don’t unit tests.  You can use ASP.NET MVC without writing a single unit tests, or knowing how to write a unit test, or knowing what a unit test is. It is true that ASP.NET MVC is easier to unit test than ASP.NET WebForms (which is next to impossible). Even if you don’t write unit tests, or know how to write unit tests, or know what a unit test is, believe me that the simple fact that ASP.NET MVC can be unit tested and WebForms can’t, is a very compelling reason to forget about WebForms. It means that ASP.NET MVC is better designed, is more flexible, has less coupling, and less magic shit which will break.

If someone tells you that ASP.NET MVC is more complicated, requires more heavy lifting or is less productive, they are trying to tell you a lie. Of course there’ll be the lost productivity of having to learn something new. But I promise you that mastering ASP.NET MVC will take a fraction of the time its taken you to master the clusterfuck known as ASP.NET WebForms (just like learning jQuery will take you less time than learning ASP.NET Ajax). Maybe you don’t have time to learn something new, that’s fine. Just don’t believe what you’ve been reading. ASP.NET MVC is simpler – unless you’re the type of developer who doesn’t like to learn new things.

Now, I have my problems with ASP.NET MVC, which I’ve shared in the past. But those are problems with ASP.NET MVC with respect to other MVC frameworks.

A framework that accepts that HTTP is stateless will always be simpler, cleaner and more powerful that a framework that doesn’t. A framework that allows unit testing, regardless of whehter you are going to unit tests, is better than one that doesn’t. WebForms is nasty.

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

52 Responses to The WebForms Rant

  1. Thank you! I don’t even know why ASP.Net still exists – and couldn’t they call it just .Net MVC -instead of ASP.Net MVC? It would initiate less bad feelings when I hear it!

  2. Like Karl, very few people has gut to say the truth in public. Good Job Karl, there is nothing wrong in speaking for truth.

    As far as official statement from MS is concerned, we all know no wise man will ever step on the hammer (well at least willingly). Looking at current revenue stream from ASP.NET Web Form, it makes no business sense to tell that it was bad idea to come up with it, in the first place or do not use it. After all nobody would like to call their own creation, a shit (even if they are)

  3. Ricardo says:

    Great post, love the comments. In the end, our job as developers is to create an application that meets (or preferably, exceeds) our client’s requirements without making it too difficult for the next developer to work with our code… my opinion, use whatever you want as long as the application does what it is supposed to do and the code is truly maintainable.

    Webforms just like MVC are great tools and we can create amazing apps with both… the app that hosts this website is a web forms app isn’t? and it is just as good as the asp.nt mvc site StackOverflow.com

  4. Chris Nicola says:

    I wouldn’t go so far as to say that calling out people with with “stupid” or “idiots” is “dirty talk”. I don’t think “you’ll catch more flies with honey”, rather “honey” will just make it easier for the WebForms crowd to continue to ignore the seriousness of that ignorance.

    We are not children here. Grown ups some times need to (as one friend of mine puts it) “not be afraid to *use words*” to get their point across. Also it’s a blog, not a newspaper, so it’s also fun to take liberties and stir up a bit of controversy.

    If you’ve had the experience of working with any developer stuck in such a broken paradigm. One that tells them they don’t need to learn or understand what they do. Then you can easily understand how *words* are sometimes necessary to express a deep frustration at what can only be described as a lack of passion for what they do.

  5. Danijel says:

    We have just choose WebForms for several new projects mainly because of close deadlines and the fact that all team members are very productive in WebForms. MVC maybe next time, but it’s not that simple to use new fancy thing. Personally, I would use Silverlight over WebForms and MVC, but that is just not that simple – there are many aspects why someone choose specific technology as Scott Guthrie clearly explained in his blog.

  6. Andrew says:

    Good blog Karl, who cares about the language, it’s about time people stop dancing around the Web Forms v. MVC issue.

    Yes, it’s horrible to generalize, but if you are designing a new Web Application and are supposed to use ASP.NET, you better have a darned good reason for choosing WebForms over MVC…and “I don’t know MVC” is not a good reason.

    Now, I’m off to judge my team by how many Lines of Code they wrote today.

  7. vkelman says:

    @Dennis Gorelik,
    As a next step, try to hit browser’s “Back” button on that page you created with 5 lines of code :)
    Besides, you can program those sample simple scenarios in anything. That’s when you need to build something complex and flexible, when you discover that WebForms battles *against* you at its full strength.

  8. vkelman says:

    “Asp.net is big. Web forms is just an IHttpHandler on top of it, just like MVC. I don’t get all the anger.”

    Jeffrey,
    But unfortunately WebForms was taught and still is taught as a default, overall, fit-all solution by most of book / MS, rather than being described as an edge case, which is really is. That’s where anger is coming from.

  9. vkelman says:

    “when ASP.NET first appeared, there was a lot of resistance to from the classic ASP camp. Many claimed that ASP.NET was too complicated”

    Sean,
    I’m a classic ASP developer with 15 years of experience and I’m using ASP.NET (WebForms) for several years too. I still think that in many aspects classic ASP is better than ASP.NET+WebForms.
    Yes, VBScript is an awful language. Yes, classic ASP does not provide you with any help for developing a structured, layered code. But at least it doesn’t battle against you, doesn’t prevent you from using your own structured strategy and from following HTTP Request /Response principles.
    WebForms, on the other side, while allows to use a wonderful C# language, tries to enforce a completely inappropriate WinForms logic. As a result, its’s really much harder to program with WebForms than with classic ASP.

    As fars as I can see, ASP.NET MVC combines good features of classic ASP (flexibility and compatibility with HTTP principles) with good features of .NET (C#, great support from the environment, etc.)

  10. Aaron says:

    All well designed complex systems are composed of many well designed simple systems. ASP.Net MVC, is one of those simple systems that we can use to create an orchestration of simple systems that display complex behavior. ASP.Net WebForms is a complex monolithic system that dumps all over my simple systems. :)

  11. Gleb says:

    Thanks Karl, good one!

  12. Scott Koon says:

    Dennis:

    http://www.jupiterimages.com uses MVC, it’s a high-traffic site that is owned by Getty Images.

  13. Scott Allen says:

    @Denis:

    Stackoverflow.com uses the MVC framework and does over a million page views a day.

    If lines of code is the best metric for project complexity, then why are we still programming in C#?

  14. Bob Jennings says:

    @Dennis

    With all due respect, you are way, way off. Rational Unified Process??? MVC as a methodology has been around for decades, and is a proven way to build UI based apps. Do you consider Rails a “fad” too?

    Stick with webforms if it works for you.

  15. @Pita
    Lines of code is the best available metric of project complexity.
    Yes I know that different lines have different complexity attached to it, but unless you prove otherwise I would assume that complexity of Web Forms’ line is about the same as complexity of MVC line of code.
    So, the more lines of code are required – the more complex project is.
    And the more complex project is – the worse it is (more time spent on development and maintenance of the code).
    So far it looks like MVC requires more lines of code than Web Forms for the same functionality.
    @Dinesh:
    1) Implementing ViewModel in designer is still coding.
    That’s why I counted lines of code for TextBox and Button in Web Forms example in my first comment.
    You do not get properly defined “InputModel” ViewModel just by adding new page to your MVC project do you?
    So, how many lines of code would it take to define InputModel? (Manually or through designer – doesn’t matter much).

    2) There are tons of new technologies out there. Trying out all of them is impossible and doesn’t really make sense.
    I’m intrigued enough by MVC so I wouldn’t mind to jump into MVC team (assuming they know what they are doing), but I’m not ready yet to spend significant time to dig deep into MVC just on my own.
    And no – it wouldn’t take just one day. It would take much longer to bring my MVC skills on comparable level with my Web Forms skills (even considering that lots of tools are the same in both frameworks – since they are both ASP.NET).
    MVC did not really prove itself yet. Are there any well-known web sites that utilize it?
    Relying just on buzz around new technology methodology is too risky: for example, RUP (Rational Unified Process) is nowhere now after all that buzz 10 years ago. Learning it (aside of the most basic concepts) would be mostly waste of time.

  16. Dinesh Gajjar says:

    @Dennis,

    You don’t have to implement ViewModel (called as “InputModel” in the example). But this is a sane method to do, so that you can add items to it whenever needed without changing too many things.

    Fundamental problem is not what you described above, but it is you being resistant to change. Take a day off and go over starter video by Rob Conery, play with the framework and I can assure you, you will never go back to webforms if you have that option.

  17. Pita.O says:

    @Dennis,
    Lines of code count is not a very good way of measuring software complexity, the ease to develop in a framework or the ease to maintain the resulting system.
    But if we take your argument seriously, and considering that you have not implemented a GET-POST-GET nor an interface-based model, and that you have excluded scaffolding code, then what you actually need with the MVC is one variable declaration and 1 line of code. Yup, one line of code (BusinessModel.Save()). Everything else is generated for you by the create/update view generator. The controller method is also generated for you.
    But like I said, “framework complexity” is much more than line count.

  18. @Jeremy D. Miller:
    1) Yes, it’s a simplistic example but otherwise it’s too easy to drawn in details. Especially at the first step of the discussion.
    2) I counted lines of code that developer needs to add to default template of the page.
    3) Here’s your MVC code example:
    ===
    void Save(InputModel model) {
    BusinessLayer.Save(model.Text);
    }
    ===
    Is InputModel class automatically generated by MVC framework or developer has to define it manually?
    Where is the code that links Save button and Save() method defined?

  19. Rob Kraft says:

    Having used both frameworks, mvc is clearly superior to web forms. You will hear that over and over again by just about anyone who has actually used both for real projects. As the post points out, if your new to .net and can’t bothered to make an educated decision on your own, go mvc, no question. Anyone who says otherwise is not being honest, or yes, an idiot. The pro web formers are out saying things like, “Haven’t tried mvc yet, but blah blah blah”

    It’s too bad Microsoft just won’t come out and officially deprecate win forms now. The sooner it goes away the sooner we’ll all have more reliable, more maintainable, robust applications on the web.

  20. @John Davidson,

    Been there, done that. If you absolutely have to use WebForms, by all means, try MVP. Business logic and service logic has always been testable in WebForms with minimal effort. It’s efforts to test Presentation logic where WebForms/MVP falls down flat.

  21. @Dennis,

    Um, basically the exact same amount of code? This is way, way too simplistic of an example to compare things against.

    - 1 line of ASPX code for textbox

    - 1 line of ASPX code for Save button / submit button

    - 3 lines of controller code:

    void Save(InputModel model) {

    BusinessLayer.Save(model.Text);

    }

    You’re leaving out quite a bit of noise code on both sides too, remember.

  22. Alberto B says:

    WebForms were born for idiots who thought they could use the same Windows Forms model for a web app.
    I’ve used them for more than 5 years and I’ve never felt very comfortable. Too many events to manage: postbacks, viewstate.
    I still think it was an experiment.
    MVC is absolutely fantastic.
    It seems natural for me to use it. You don’t have to deal with all that crap. You don’t have to waste time to fix the viewstate problem. You do not have to manage 10 different serve events for the bloody loading of the page and the exact time when you have to load you dynamic control.
    You don’t have to use those long control names.
    You can manage javascript in a better way.
    I reckon that those who are still discussing about that are old-school developers who are scared of the changes.

  23. BjartN says:

    I mostly agree with you on this one. However I’m not convinced that a framework that embraces statlessness is always the best way to go. If you look at a majority of well functioning web sites out there many of them are stateful. Why not have the framework support it. Web Forms is crap because Microsoft is trying to please everybody with this framework, and ends up pleasing nobody. The framework is too bloated. I think it is possible to implement a Web Framework using the same basic patterns as WebForms, but letting it be more geared towards testable MVP-type applications. By not trying to please everyone you could create a good, testable and productive framework. Well, that’s my opinion at least :)

    Later.

  24. Last time I checked, MVC required 50+% overhead (relative to Web Forms) in terms of the amount of code required to implement the same functionality.
    Was that fundamental problem fixed yet?

    Let’s consider an example of business requirements:
    Create a page that allows user enter text, click “Save” button, and then call existing business layer method BusinessLayer.Save().
    With Web Forms approach it would take:
    - 1 line of ASPX code for textbox
    - 1 line of ASPX code for Save button (including Save_Click() call).
    - 3 lines of code-behind:
    void Save_Click() {
    BusinessLayer.Save(Input.Text);
    }
    Total: 5 lines of code.

    How many lines of code that task would get in MVC?

  25. Kim Rossey says:

    I believe webforms is why we see so many PHP sites online today. Back in the day of classic asp it was not that way. I am hoping MVC changes this and am looking forward to those changes. Never liked webforms much from day one.

  26. @Karl,
    as an author of asp.net mvc in action, I have to say that I see a
    reconvergence of asp.net coming. I don’t thing postbacks are going
    away. They are really useful in some scenarios. With .net 4 routing
    and abstractions are in system.web. I think the next step is to put
    controllers o. Front of existing aspx pages as a means to pull code
    out of page_load. Heck, I can even see an update panel being plopped
    on an mvc view.

    Regarding component vendors, the model is more powerful in .net 4
    because virtualpathprovider works in medium trust. That, along with routes
    makes delivering components even more powerful.

    Asp.net is big. Web forms is just an IHttpHandler on top of it, just like MVC. I don’t
    get all the anger. Why not rant again Java or ColdFusion? Why not rant against COBOL, which is still being developed. Why single out Web Forms?

  27. Steve Austen says:

    God this is tedious, another uber geek spouting on about how WebForms apps are developed by idiots who aren’t nearly as uber as you. Get over yourself. WebForms is far from perfect but it was created as an abstraction layer to make life easy (yeah it failed in many ways) for developers who looked at web dev and thought ‘This is a shitty mess’.
    An abstraction layer has flaws, some big some small, but oh noes according to uber geeks who’ve just discovered mvc that’s not acceptable everyone should output pure html and javascript. Of course they’re allowed to use ORMs or jQuery because those abstraction layers are anointed but woe betide anyone not using the anointed tools because they are all idiots.
    It’s like the ROR community attitude is infectious, basically elitism at its shallowest and most obnoxious. If you love mvc great, so do I, how about you try using your posts to convey why it’s great instead of bashing something everybody already knew was flawed.
    You can write testable code in WebForms and whether you do depends on one fundamental thing – do you want to enough to try?

  28. miensol says:

    Fully agreed. I’ve been working with WebForms for about 6 months now, actually using WCSF, and the number of problems that are constantly occurring when doing even simple things is just annoying especially when it comes to performance and extensibility…

  29. Bob Simmons says:

    This post is spot on. And please, stop whining about the language! I’d rather read a post like this where someone expresses themselves like people do in the real world. I have NEVER worked in a development shop where it wasn’t at least R rated.

    Bunch of uptight sissies….

  30. gregmac says:

    Great article, totally agree with pretty much everything here.

    @Gabriel : I moved from many years of PHP development into a job with .NET, working on a Webforms based app. 8 years old or not, I was frustrated at how difficult it was to accomplish REALLY simple things I’d be doing for years. Several month later, once I knew webforms quite well, I *still* find myself working around viewstate problems, and it always feels like anything beyond the fixed number of use cases that Webforms was explicitly designed to addressed is an excercise in futility – the framework is constantly fighting against me.

    It’s not a matter of being old — it’s just simply a bad design. It’s overly complex for what it does, and as Karl points out, it has attempted to make HTTP look stateful, but mostly fails.

  31. Dan Martin says:

    I like my rants to have some occasional profanity (especially usage of clusterf***) so no complaints here.

    “A framework that accepts that HTTP is stateless will always be simpler, cleaner and more powerful that a framework that doesn’t. A framework that allows unit testing, regardless of whether you are going to unit tests, is better than one that doesn’t.”

    This! I totally agree.

  32. Joachim says:

    Confirmed!

  33. Me says:

    I like MVC. I like ASP.NET. Eithe way, you’re a jackass.

  34. Where did the aggressive tone come from? It’s very much a detractor from your argument and made focusing on your points that much harder.

    Aside from that I can’t help but feel you’ve put forward the sort of “religious war” type rant that contributes little more to the community than grounding for further argument.
    Articles of this nature (and I see this continually from other bloggers) generally betray a narrow focused view that leaves little room for the consideration of other developers’ circumstances.
    While I generally agree with your subjective points (after looking past the racy language) you did leave me, and I dare say other readers, somewhat alienated and defensive (because it felt like a personal attack).

    That said, you did make one point I completely agree with: “A framework that accepts that HTTP is stateless will always be simpler, cleaner and more powerful that a framework that doesn’t. A framework that allows unit testing, regardless of whehter you are going to unit tests, is better than one that doesn’t”.

    Still looking forward to your posts – just please try to remove some of the “heat” from the argument.

  35. John Davidson says:

    Our team is building a Web Form based application using the MVP pattern with NHibernate. The Web Forms are limited to a Page Init function, property getters and setters and event triggers. The Init function is responsible for starting the Inversion of Control process. Unit tests of the code behind getters and setters are done via mock replicants.

    Presenters are where the logic of each web page resides, managed by responding to events from the aspx code behind. These are unit tested in the traditional manner.

    We use external dlls abstracted through a Provider pattern and interfaces. The methods and properties in these external dlls can be unit tested.

    The model is access via services. The presenter detects whether the environment is production or test. If the environment is production then the presenter creates the service to use NHibernate, otherwise when it is in test mode it uses an in-memory database for speed and simplicity.

    Unit tests coded against the service layer can use the in-memory database or the NHibernate managed database. All of this is unit testable.

    To get these capabilities we had to give up most databinding, but are able to use some very complex composite controls that simplify the aspx page itself. All html display is controlled via css files.

    The point of all this is that it is possible to get all the benefits of MVC, by using a correctly constructed MVP (not what MS tried selling as MVP for ASP.Net, but an Alt.Net version)

  36. David says:

    I agree that MVC is a better programming model for websites. But where’s the DotNetNuke/CMS/module-based framework? Those work great in enterprise apps where the navigation is completely data driven and pages customized per tennent!

  37. Arnis L. says:

    Conclusion => nothing beats Sharepoint. :D

  38. John Mitas says:

    Great read, fully agree. I was one of those that started in the webforms world and moved to MVC. Now I’m in the Silverlight world (since 1.0) and am now seeing the rise of MVVM.

    Do you see the same happening here? Is MVVM ultimately like MVC and webforms is like Classic Silverlight Usercontrol/codebehind development ?

  39. so now everything is a nail and you should always use a hammer… sigh

  40. Gabriel says:

    I haven’t even tested ASP.NET MVC, but I’ll get to that during the next couple of months…however, I agree about the unnecessary name-calling for WebForms.

    People say it’s badly designed and all other types of things, but take something you created/worked on 8 years ago, when it was considered to be revolutionary, fast-forward 8 years and try comparing it to a new available solution? Bet your 8 yeard old solution will look like crap when compared to a newer alternative.

    ASP.NET MVC probably has a good design based on all the learning acquired during these 8 years, and maybe the next thing that replaces ASP.NET MVC will even make it look bad.

  41. karl says:

    thx bill, should be fixed once the cache times out

  42. Don’t you mean “they claim that ASP.NET MVC is suited for Test Driven Developer (TDD) specifically”? (Left out the MVC)

  43. Grant says:

    Lol! Nice blog, but I’m not sure I really understand the message.. Are you saying that you’re for or against webforms here?

    Really though, I’ve always hated (and avoided) webforms because it always seemed overcomplex. Although it tried to make things simpler by overlaying the web with it’s winforms-style model, it always felt like you were going against the grain, and there were many associated problems – but not interesting problems.

    From what I’ve seen & heard about MVC, I think I might like it. Web development here I come!

  44. UK Programmer says:

    Okely dokely…
    Karl, I heartily agree with the thrust of your post, but heck did ya need to use all that dang blamed dirty-talk language??

    My maiden aunt reads this blog!

  45. Sean says:

    I really think the language took away from the quality of this post and undermines the overall meaning. It’s your blog, so do with it as you wish, but I feel it would receive more positive attention (from both camps) if it were rewritten and cleaned up.

    At any rate, nearly ten years ago, when ASP.NET first appeared, there was a lot of resistance to from the classic ASP camp. Many claimed that ASP.NET was too complicated (for other reasons) and felt that OOB was little more than a passing trend in the web development world. Not only were those people wrong, but they eventually hit a crossroad where they had one of two options a) learn a new framework b) become obsolete. Most sided with learning a new framework.

    Aside from the testability of ASP.NET MVC, there is a fair amount more that it has to offer over classic ASP.NET applications. The web development world is rapidly changing. ASP.NET AJAX and the UpdatePanel were desperate attempts to bring ASP.NET up to speed with the changing marketplace. While this was a valiant effort, the original ASP.NET platform simply wasn’t designed to build applications the way they are, today. Building a website that conforms to the RESTful architecture constraints was, quite often, like trying to put a square peg into a round hole. Again, ASP.NET simply was not built for this. Additionally a strict reliance on a single form post back model hindered developers ability to implement AJAX and other web 2.0 features that other platform weren’t having a difficult time dealing with.

    I no longer buy the argument that WebForms is better for rabid development. The T4 templates that have been provided by Microsoft have greatly improved the development experience that we saw in the beta days of ASP.NET MVC. Thing are certainly changing for the better, but there is still a fair amount of FUD being passed around.

    ASP.NET has many advantages over classic ASP.NET. My prediction is that we will continue to see an increase of developers utilizing ASP.NET MVC for new projects.

  46. karl says:

    @Martin:
    From what I’ve heard, the official message is, and will remain, full support and development for both with no plans on changing that.

  47. Paul Speranza says:

    I Agree!

  48. Martin Evans says:

    I’d be interested to know what MS think about the future of the two frameworks as side-by-side entities. Surely there’s extra cost incurred maintaining two frameworks that do the same thing?

    I like to think that we won’t see webform project templates in Visual Studio after VS2010 has been superseded but suspect that won’t be the case!

  49. Paco says:

    I completely agree, and the people reading your blog will also agree, but you won’t reach any of the people you are talking about with this post.

  50. Jay Pondy says:

    A bit spicy with the language but overall I tend to agree.
    ASP.Net Web Forms was born to help lazy WinForms developers that didn’t want to learn a new paradigm (stateless web) transfer their skill, or lack thereof to the web. Having used Web Forms for almost a decade I find MVC way more natural for the most part – particularly in encouraging OOP style programming.
    Any Developer that does not have the time or inclination to take a look at new ways of doing things is either in the wrong business or with a poor company. I don’t relish the idea of learning yet another framework but there’s never been one where I didn’t take something away from the experience.
    After nearly 9 months of pecking away at MVC and developing three small production apps I’ve grown pretty fond of it. Along the way I’ve picked up TDD, the Repository pattern, jQuery and Dependency Injection all of which I will continue to use with or without MVC. At 53 I’m still not done looking at new ways of doing things.

  51. Martin Evans says:

    I suspect webforms was introduced to try and draw winforms developers into web development by trying to make a postback stateful. #fail
    I also think ASP.Net MVC pisses off the component manufacturers that have made a lot of money developing webform server controls. Were that market to dry up, they’d have to rely on income from Silverlight components.

    Nice use of the word clusterfuck though.

  52. “A framework that accepts that HTTP is stateless will always be simpler, cleaner and more powerful that a framework that doesn’t.”

    Amen.