What's different between HTML/AJAX application and ASP.NET/AJAX application

I hope you know the difference between HTML, Ajax and Asp.net so I won't bore you with these and just cut to the answer. I'll throw in some Javascript knowledge in this same bag as well.\n\nHTML+Ajax\n\nEvery Ajax application is actually HTML+Ajax application because it uses HTML+CSS to display visual data and Ajax to asynchronously communicate with the server. This last part server is just as important if you intend to write an application. So basically HTML+Ajax is just client side definition of your application.\n\nAsp.Net+Ajax\n\nNow this means that you'll be using Asp.net framework on the server side (as opposed to PHP, J2EE or something else). But be careful, since we have two server-side Asp.net frameworks:\n\n\nAsp.net WebForms - this one is similar to windows desktop application development because much of the processing is somehow event based (click of a button, change of a text field etc). This is both good as well as bad. The good part is that it's rather easy to write web application with HTTP protocol abstracted away, but the bad part is that in order to abstract the communication protocol and client functionality away it has to do some pipeline processing with additional variables (that may become huge) that you should be aware of, because desktop applications are not stateless, HTTP protocol on the other hand is and this is mitigated by WebForms abstraction layer.\n\nWebForms applications usually end up with bloated HTML DOM element tree, lots of page postbacks and full page reloads (a.k.a. page flickering) and sometimes strange behaviours that you can't explain if you don't know how it works in the background.\n\nWebForms also provide huge set of server side rich web controls that are represented as a single control on the server but render as complex HTML on the client (ie. calendar control). They usually encapsulate much of their event model and functionality and are often also data aware. This is good because development is faster, but also bad when you have to do something that is not exactly default control's behaviour. Whenever you deviate from this default you'll soon be writing much more code and knowledge of these controls becomes very relevant. It may also end up in writing all kinds of plumbing and hackish code.\nAsp.net MVC - this is a newer framework that doesn't abstract away HTTP protocol and is by nature stateless and very well suited to HTTP (it was actually written with the protocol in mind all the time). The good part is that you take total control of your HTML and more or less also page execution. Nothing as big as state+HTTP is abstracted away and it uses a very simplified execution model that is also very extendible. The bad part is that you may end up writing more HTML (no such thing as server-side controls) which will take more time but my take is that on the long run it's much easier to maintain and resulting code is more stable and application faster because the whole thing is much more modular and simplified.\n\nAsp.net MVC doesn't support server-side controls (although you can use WebForm's server controls, although I strongly suggest against doing it) but it does support Html extension methods that may provide some more complex HTML rendering in a short line. Open source projects like MVCContrib provide some richer Html extensions you can use. I don't use them but some of the others do.\n\n\nLet's add some Ajax then\n\nWhen we think of the two frameworks on the server side WebForms provide some sort of UpdatePanel server side control that was a quick workaround for Asp.net WebForms developers to abstract away HTTP layer (yet again) so the whole thing still works as before. It is easy to create Ajax-like applications using this server control but the way that it works means it will be much slower, won't scale well on the server and is in general not such a grand idea. If you ask me, this was Microsoft's quick fix for developers to give them Ajax without much learning curve. Embrace it and you can brag about your Ajax-powered application.\n\nAsp.net MVC on the other hand is very Ajax friendly because of its simplified execution model and because it is very well suited to HTTP protocol. Using Ajax is usually done by third party client side libraries (jQuery being preferred default). Libraries are usually used so you don't have to deal with different browser capabilities. Library makes it uniform across clients. But you can use any library you prefer (which is good to not limit you in any way). If you'd be writing dynamic websites you'd probably go with jQuery. But if you'd be developing a business oriented intranet web application you'd probably go with something like ExtJS, because it provides very rich client side controls and the familiar desktop-like experience of rich applications. A very strong candidate for such applications.\n\nWhat's the verdict then?\n\nIf you haven't done much development in Asp.net (but know it to some extent), and would like to use Ajax I suggest you take the plunge and start with Asp.net MVC + jQuery. It will be much easier to develop and a whole lot simpler to learn and maintain. This also means you'll be writing Javascript scripts for client side execution.\n\nBut if you're not so inclined to Ajax and you know Asp.net WebForms rather well, then I suggest you do it using Asp.net WebForms. But keep in mind that you may have some future requirements. You'll have to mitigate their Asp.net WebForms limitations then.\n\nIn the end the more problematic thing will be to properly choose your server-side tools and technologies. What will you be using for DAL and BLL and how you'll structure your application.\n\nWhat else can be done using Microsoft stack of technologies?\n\nFew years ago I was working on a LoB web application that used this stack of technologies: Asp.net WebForms (mainly for localization stuff and master page handling), ExtJS 2, Ajax and WCF w/JSON. Asp.net Webforms served basic page loading, then majority of the UI was generated on the client using ExtJS and all Ajax calls were handled by WCF service. Would I do it the same today? No. I'd just use Asp.net MVC which wasn't available at that time and get rid of WCF and Webforms altogether.",