Why ASP.NET (webforms) Sucks.
Somehow, I got into a heated discussion at work today regarding the suckitude of ASP.NET web forms development model. As a preface, I wrote Java for four years in a college, ASP in VBScript and JScript all throughout college, ASP after college, and then started working with ASP.NET when it released.
Don’t get me wrong, I love .NET and C# to death; they’re awesome (so awesome). But ASP.NET webforms? I could smell coming from a mile away – like the stink of a dead skunk (or 20) in the middle of the road. It’s clever, I’ll give you that, but it’s been over-engineered to hell and back to account for the shittiness inherent in how it wants you to write web applications.
Finally, after what? 8, 9 years? Microsoft has got it right with ASP.NET MVC.
What follows is the summary of my arguments as to why ASP.NET webforms suck (and it’s only the tip of the iceberg!).
Undoubtedly, JSF and ASP.NET webforms suck giant elephant balls. I mean giant balls of epic proportions of suck. If this were the Richter scale, it would be a magnitude 10 level of suck (by the way, wiki describes that as “Epic. Never recorded“).
A simple google search for “JSF sucks” yields plenty of results.
Freddy D. has a nice summary list:
- JSF + JSP = templates that are filled with way too much noise.
f:verbatim? ack! Facelets helps here but it is still too hard to read.
- The generated HTML is all kinds of black magic.
- You can’t have a simple link to a JSF bean with some parameters and invoking an action method, from outside the JSF context, without having to jump through all kinds of hoops.
- Parameter binding and retrieval from a different page involves tricks and digging through the FacesContext.. yuk.
- faces-config.xml. struts-config.xml all over again. Just too noisy and useless. What is the added value, really?
immediate="true"? are you kidding me?
- the managed beans are supposed to be reusable POJOs. So why do you need to use
SelectItemfor select boxes? More useless code. This ties you to JSF for no good reason.
- the data table is inept. Display Tag anyone?
- writing your own component is way too much work.
- want some AJAX? you’ll need to add yet another framework to handle it, and if it doesn’t work, you’re SOL. if you want to write your own AJAX-enabled component.. read the item above and add a few more “way way WAY” in front of “too much work”.
- Even if you find ways to solve your problems, just knowing that it would be SO much easier with another framework, just adds to the frustration. Case in point, we switched to Stripes and our code is up to 30-50% more concise, clearer, easier to understand.. plus, as a small bonus, it actually works!
- The principle of least surprise definitely does not apply when using JSF.
Well I’ll be damned if those weren’t some of the same reasons that ASP.NET webforms suck.
Since I’m not as familiar with JSF, I’ll discuss this from the ASP.NET perspective. First, why is ASP.NET the way it is? Why did they design it like this? Undoubtedly, one of the core reasons was because they thought VB6 developers were too damn stupid to know better. To make these plebeian, lowest-of-the-low, bottom rung programmers “productive”, they put together this abomination of an event model on top of a perfectly nice and awesome .NET and C#. ASP.NET webforms are shitty beyond compare because of this.
To understand why this sucks, consider how you program for a client-server model when you are building a Windows forms application. Your winform is responsible, clearly, for rendering data only. It makes a service call that doesn’t understand a damn thing about the winforms application, right? The remote endpoint, the server side, cares about data and data only. Once the service call completes, your client handles rendering of that data and putting it into grids and what not. Your services called by the winforms client don’t have silly “OnClick” handlers in the service implementation do they? Can you imagine what that would be like if you had to write your WCF services or any sort of web service like that? You’d have to do all this shitty state maintenance and pass around useless data (like what button was clicked); you would have to have UI logic in your service. It sounds like it would suck to do that with your winforms to a WCF service. This begs the question: so why do you have them in your .aspx.cs? .aspx.cs is an incredibly stupid model and absolutely forces you to mix your controller logic with your view logic, making it difficult to reuse, difficult to maintain, and difficult to understand.
Digest that for a moment.
(Granted, there are some differences in developing a winforms thin client and a web app and obviously some scenarios where it’s advantageous to return generated/static markup.)
ASP.NET MVC is very, very far removed from JSP (I did a bit of JSP) since JSP was never an MVC design (and neither is ASP.NET webforms). Out of the box JSP and ASP.NET webforms are both an almagam of the Page Controller and Template patterns with the shittiness of the faux event model layered on top. ASP.NET MVC is a true MVC model (or at least it’s pretty damn close) that uses a Front Controller pattern and truly separated concerns between the view, the model, and the controller. Most of the shittiness and pain with ASP.NET stems from the fact that the page controller pattern violates all sorts of seperations of concern as it encourages mashing up code that should be isolated in a view with code that should be isolated in a controller. The end result is a giant heaping pile of poo. The control and event model only make the situation worse by requiring this ugly, terrible thing we’ve all come to hate known as viewstate.
I’ve come to beleive that ASP.NET webforms continue to perpetuate generations of developers who have no idea how all this “magic” works and when presented with a design scenario that calls for a truly innovative UI, they stumble because they can’t figure out how to do it without a control to hold their hand…boo-hoo (I’m amazed when people are amazed by some stupid ASP.NET web control without realizing how easy it is to accomplish the same thing with some jQuery goodness (or conversely, how hard it was before we had nice things like prototype and jQuery)). The list of companies that don’t screw around with these stupid frameworks probably have some of the most brilliant developers working for them: Yahoo!, Google, Facebook, Amazon, etc. — these guys long ago learned the lesson that ASP.NET webforms/JSF is for simpletons (or masochists).
Okay, I concede that it’s great for initial productivity. Certainly, most developers can probably throw up a page with a grid with some databound recordset much faster than I could write a page with the same set of features. But I wager that my implementation would be cleaner, easier to read, easier to understand, easier to maintain, easier to reuse, and easier to work with once the need arises to address a usage scenario not supported by the grid out of the box. If first run development speed is your only concern, then I lose every time because I’m concerned about doing it right, making it maintainable, and making it easy to understand the programming model. If you care about those things, then it’s worth it to do it right.
ASP.NET MVC will be the litmus test that will differentiate the competent developers from the rent-a-coders and, hopefully, will come to replace webforms as the primary model of web application development on the .NET framework. The “stateful web” was an experimental failure of epic proportions to satisfy the simple minds that couldn’t wrap their heads around the fact that the web is inherently stateless. Let’s move on from that dark, dank, dreary past and bask in the light of ASP.NET MVC!
I use webform when i need a CRUD for yesterday, it is kind of hard when you want same fancy ajax in your page, when i need that i use asp.net MVC.
Before MVC i used asp.net like PHP. Without webform’s.
Try to do that in java, java web developing is like a lassagna of frameworks.
ASP.Net Webforms are the space shuttle of web tech… A really bad idea in retrospect that took an amazing amount of engineering, but in the end was in the completely wrong direction.
read my response
It seems to me that Wicket (a Java framework) gives you the best of both worlds. Wicket for C#, if it were to exist, would be even better.
Frank, that might be the case.
I haven’t spent much time with Java in quite a while so it would be hard for me to say (certainly, no experience with Wicket). But the original (in the flesh) discussion grew out of a comment made on the fly by another colleague along the lines of "You’re the first person I’ve heard that says JSF sucks" 🙂
I generalized that to say that not only does JSF suck, ASP.NET webforms suck, too. While it is certainly possible, with a lot of work, to write a reasonably clean application in ASP.NET, the whole programing model encourages sloppiness. On a project that is staffed heavily with junior/mid-level developers, it inevitably leads to a "big ball of mud" (odd, kind of like the project I’m trying to clean up now…).
I generally agree with that… after years working with web forms, MVC is so refreshing to use because you’re not fighting with a framework which is trying to make the web seem like a windows application.
Talking about initial productivity, I find ASP.NET MVC is actually faster in getting quick prototypes up and running. I don’t think ASP.NET MVC is just for people that want to "get it right" – if you’re going with the "fail early, fail fast" approach MVC works too – it’s a framework that gets out of the way and lets you do your thing.
"they thought VB6 developers were too damn stupid to know better"
great point – the underpinnings for ASP.NET were set with the laughably stupid ‘VB6 Web Project’.
Gee – let’s take the VB event model and treat IIS like it’s windows.
That’s a recipe for ‘square peg, round hole, hit hard, repeat indefinitely’
In twitter speak – #FAIL
Occasionally I like to see what comes up when I google "ASP.NET Sucks" and tonight (while taking a break from being pissed at ASP.NET) I found this. I’ve written code for 30 years on everything from embedded processors to bank systems that handle billions in transactions, and I honestly don’t think I’ve seen anything that sucks as much as ASP.NET.
The only place where I’ll disagree is that ASP.NET was created for numbskull rent-a-coders. If you’ve ever been to Microsoft (and I’ve worked on site with them on various problems over the years) you would know the main problem is that it was created *BY* numbskull rent-a-coders.
Get yourself a job in a major Corporate America setting where you’re surrounded by fresh-outta-school H1B bottom feeders, and you’ll recognize all the same "big ideas" mixed with "on the job training" experience being implemented with the reckless abandon that is possible only when you know you’ll be working somewhere else in six months and won’t have to answer for your experimentation in production code.
.NET is awesome. C# is awesome. ASP.NET needs to be thrown away and forgotten.
Good news is, there is a solution to ASP.NET’s problems: it’s called the Turbo framework.