Webforms & jQuery: A Comparison

This one has been pulled from the archives but I still think it is quite relevant

I tend to be a bit picky when it comes to seeing what is generated by server-side technologies. The first thing I do when I write a page (JSP, ASPX – whatever) that uses some sort of tag library or user control is check the resultant HTML/CSS/Javascript. When it comes to ASPX's this has always been a major issue for me – the code it generates, the JS it pulls down, the amount of redundant traffic, the actual quality of the code – all of it annoys me. Just out of curiosity I wanted to do a “contrast and compare” study to see the differences between the DIY approach and using Webforms…

The use case for the study is simple

• A simple screen with a star rating (1-5)
• User selects a rating by clicking a star
• The result is posted back, via ajax, to the server
• The front end is updated with message indicating the selection and the rating system is disabled

Technologies Used

There is not much really to draw from this table except for Webforms the majority of the technology is server-side whereas the jQuery stuff is more client side focused. This is one of the big arguments that people use when arguing about webforms. It's all server side work which reduces client side scripting – but that's a bit blind. It's server-side for the developer but the end code isn't any less client side (it's simply auto-generated).

Development Effort Required

I'm going to end up being biased on this. I am 10,000 times more familiar with the MVC paradigm and jQuery than I am with Webforms. Ultimately it took me about the same amount of time to knock up both applications. But here are some points to note.

Webforms

Drag and drop of all the controls to knock up a simple page. The bulk of the work came from my lack of understanding I guess. I initially stuck the Star Rating control on the page and set up the CSS Classes, this failed as I didn't have the ScriptManager control added to the page. The next issue I faced was that my server side code wasn't actually having any effect – I had to turn AutoPostBack on for it to work but this wasn't Ajax-y. I got around this by wrapping the code in an UpdatePanel.

[[posterous-content:bBdcwIItewquatsyfJyv]]

Default.aspx

[[posterous-content:vfJuAxpqzbFsFoFBFwAE]]

Default.aspx.cs  (Code Behind)

jQuery

I used ASP.NET MVC framework to generate my empty page, and controller. I then added a simple one liner Action to my controller to handle the Ajax response. I included jQuery and Star Rating (JS & CSS) to my page and 5 radio buttons that act as the star rating (automatic progressive enhancement) and wrote the initializer code for the star rating stuff. For me that was it – completely straight forward with little configuration.

[[posterous-content:xqpnygHdsdJiruvDqkpf]]

Index.aspx

[[posterous-content:kgpqwhjHGDbiqHJCCvCA]]

RatingController.cs

Resultant Page Weight & Render Time

Webforms

[[posterous-content:uCAmokcAGoyHstBqGxsj]]

Page Weight

[[posterous-content:nDxjAJoJDbwurDtdAnvx]]

Render Time

jQuery

[[posterous-content:cHfxHIJCwxwiGDCgCIuw]]

Page Weight

[[posterous-content:zsChEvClgasifCgquBpo]]

Render Time

Now the real differences are starting to show. The jQuery Solution is light years ahead when it comes to page weight (with marginally faster render times). It's also worth noting here that the Webform solution automatically used GZIP compression for it's scripts whereas the MVC didn't so the results are actually skewed in favour of Webforms (not that it makes a difference).

Here in lies one of my issues with the Webform solution – it pulls down the massive ASP.NET JavaScript framework even though it doesn't use 99.9% of it. jQuery is a complete framework but it's ethos is that it gives you the bare minimum set of tools to get the job done. Look at my code (both server side and client side) – is it at all complex? Not really.

One argument I guess you could use here is that as the page grows the Webform solution, because it has most of the scripts it needs, shouldn't grow much bigger, where as the jQuery solution will. I haven't tested this so I could be wrong but it's a valid argument. That said given any situation I'd be willing to bet I could at the very least match page weight and render time against any Webform solution using jQuery (and MVC).

Server Responses

Webforms

[[posterous-content:rChlEcegkzzzEgEkxiAc]]

Request Parameters

[[posterous-content:gIgansGldxpvrcfvkapa]]

Response Body

jQuery

Request Parameters

Response Body

Again there is a big difference here. Because a lot of stuff is automated on the Webform side there is a lot of configuration (Viewstate etc) that needs to be passed about. Even for this simple solution the overhead is considerable – Firefox is giving me traffic (response only sans headers) of 1 byte for jQuery and 3k for Webforms – now multiply that by 2 to roughly include the request as well.

Which is easier to understand here?

Conclusion

A lot of the arguments and observations brought up here aren't purely Webform vs jQuery related – a lot have to do with Client vs Server programming but they are still valid. I admit I have a firm grasp of client side coding so the choice for me is obvious but the results here speak for themselves – there is a considerable overhead involved in the Webform world that must be accepted if you want to be able to drag and drop controls and save possibly a small amount of development time.

I am in no way a veteran Webform developer and I am sure there are folks out there that could strip my example down to the bare minimum and get similar results and to them I open floor – bring it – I haven't begun!