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.

Undoubtedly, .NET and C# were a giant leap forward compared to ASP and JScript (my preferred scripting language for ASP).  But even from the start, I could never love ASP.NET.  Simple things that I used to do quite easily in ASP were now seemingly much more difficult and much more convoluted.  The HTML never quite came out the way I wanted it (remember the days when .NET wouldn’t output cross browser compatible Javascript and markup?  And how that markup would always fail validation?  Yeah, I remember those days.) and it was a chore to get many development tasks done (had to overwrite this or implement that — just to get a freaking icon in a table cell).  By the first year of use, I was already thinking that it was a terrible abomination of a framework; I never wanted to see a DataGrid ever again.

Ever since then, I’ve avoided writing applications in the traditional webforms model altogether.  First, I stumbled upon AJAX.NET, then I heard about this neat thing called “Atlas” (ASP.NET AJAX), then I picked up prototype, and finally, I have seen the light with jQuery (this is after writing my own Javascript for everything for the first several years of development).  I’ve never looked back; I’ve never once missed working with a web DataGrid.  I’ve never once missed working with most of the controls in ASP.NET web forms.  In fact, the only two four non-shitty controls worth using are the ScriptManager, Placeholder, LiteralControl, and Repeater.  That’s it; that’s where I draw the line.  UI controls?  They all suck.  Every.  Single.  One.  Why? 1) Because it mangles HTML output (ID’s anyone?) which require ridiculous workarounds to do anything cool on the client side (i.e. writing the ClientID to the page?). 2) I hate viewstate…it’s just extra…stuff (and yes, I’m intimately familiar with that “stuff” because I had to hack it to pieces at Factiva).

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:

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’m convinced that these frameworks were created for numbskull rent-a-coders because they’re too lazy/stupid/incapable of grasping basic HTML, Javascript, CSS, and simple DOM.  Look, at the end of the day, if you’re going to be a web developer and you’re not going to put in the time to master HTML, CSS, and Javascript to some degree, you’re not doing it right.  That would be like a baker that didn’t want to learn the basic composition of breads and dough and the chemical reactions that make tasty baked goods out of simple ingredients like flour, yeast, eggs, water, salt, and sugar.  Web developers attached to ASP.NET web controls and fear Javascript (and I know some) are like “bakers” who open a “bakery” and buy their products from Costco and repackage them.  I guess it’s efficient and productive, but at the end of the day, such a “baker” is constrained to a very small universe of possibilities…how boring.

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!