The Problems with ASP.NET AJAX
It’s no secret I’ve long been a fan of .NET and the ASP.NET stack. I feel the team really got it right making developers highly productive and the Visual Studio IDE is second to none. After spending some long hours with Atlas and ASP.NET AJAX though I’m afraid I can’t say the same.
ATLAS on top of ASP.NET is an example of a retro-fitted round tube jammed into a square hole. The whole notion of AJAX is that it’ll serve PARTIAL pages, snippets of data, merged with presentation on the browser side. Unfortunately ASP.NET AJAX adopted the notion of the UpdatePanel with which I have the following issues:
a) Update Panels are not partial page, they’re full page. The entire page posts back. Where’s the speed gain?
b) The page’s DOM is brutalized. Each <div> tags’ id is generated for you which could’ve been nice. Unfortunately the generated ids are incredibly verbose, meaningless strings of dollar concatenated craziness. Here’s an example from Foolstr:
<a id="ctl00_contentMain_ContentList1_repContents_ctl02_cmdAgree" class="myH1" href="javascript:__doPostBack('ctl00$contentMain$ContentList1$repContents$ctl02$cmdAgree','')">Agree</a>
c) Not only are these ids/names duplicated and incredibly long, they’re impossible to reference from anything other than ASP.NET AJAX. For example, if you want to combine with a third party JS library like Scriptaculous, you’re out of luck (it can be done but only with some big hoop jumping through). Unfortunately there’s little the developer can do to trim them down without overriding a lot of the default behaviour of .NET.
d) It’s non-intuitive. Essentially ASP.NET AJAX adopts a server-side style and mindset to client-side processing.
e) There’s no focus on the data contract. I don’t have to write a JSON API or an XML/REST api or anything. This might be good for some but I think it’s never a good idea to shift focus off the data.
f) It’s lazy. It encourages a laziness in the developer. Just code as normal and slap it in an Update Panel. Meh.
Those are the gripes. I have to say the third party vendors have only compounded the problem. You’d think 3rd party controls’d be lightweight, optimized and fast but so far what I’ve seen is they’re even worse. This is mostly a symptom of them having been built on top of an already broken paradigm.
Most 3rd party controls include the ASP.NET AJAX stuff as a pre-requisite. That makes them heavy. I’m talking 100KB of javascript before you’ve drawn anything. 250KB plus in pure javascript alone for a grid. That’s before you bind it to data. There has to be a better way, there IS a better way.
What do YOU consider the perfect web development stack?
There is no such thing as THE perfect web development stack. Whether one development stack is better or worse than another development stack depends on the type of application you’re writing, your team’s skill sets, and a whole range of other things. Overall, your points are correct, but here are some redeeming thoughts.
a) Right, there is not much of the speed gain, but it’s not just about speed. With all of their limitations and overhead, update panels can still improve page responsiveness (and usability) by eliminating the flicker effect.
b) Right, IDs are verbose, but this is not the update panel issue; if I understand it correctly, it’s the general way ASP.NET generates IDs for data-bound controls (they would still be long without update panels).
c) I don’t know about Scriptaculous, but it’s not that hard to reference these IDs from jQuery.
d) I’m not sure. With classic ASP/ASP.NET background, it seems rather intuitive to me.
e) The fact that you don’t have to write any additional APIs looks like an advantage to me: less code, better maintainability (in most cases).
f) Okay, maybe it’s for lazy developers, but not always. It’s a valid option for developers who are just switching from classic ASP.NET to AJAX. It may not be the final option, but could be an intermediate stage. Once developers get more comfortable with AJAX using update panels, they can move to more advanced and effective techniques. It may also be a good upgrade strategy for already built apps that do not use AJAX.
[...] time I griped about ASP.NET ATLAS [LINK]. Ok so with that said, what’s the alternative? When I wrote my book (Amazon.com Mashups) I [...]
I surprised to read ‘Atlas’ in 3/2009. AFAIK that was the beta name for this stuff that was dropped 2 years ago.
UpdatePanels are all about development speed. There is some speed gain in that an entire page is not sent back from the server. but you are still submitting the whole page and the server is processing the whole page.
UpdatePanels will continue to have a place for converting existing web applications into more ajaxy types of applications.
But if you are building from the ground up it is a mistake to use them. WCF and AspNetCompatibilityRequirements give you a lot of power to make data only calls based on a user. Once the data is back at the browser you can use whatever javascript library you like to modify the DOM.