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").
- 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!