ASP.NET server side tags vs. JavaScript-based UI and REST

Question

Hi,

I've been developing "traditional" ASP.NET applications with server side ASP.NET controls and code behind files, etc. Now I'm exploring several JavaScript libraries like: jQuery, YUI, Ext Js, Prototype. (also it's hard to pick one, but it's another post). All these libraries make client to server communication a lot easier, but they also offer nice set of very sleek UI controls. And some controls are way sleeker than ASP.NET server side controls in my opinion.

But now I am questioning the traditional ASP.NET model. I am leaning towards all HTML/JS UI talking to the server (just a simple aspx page) via REST. What do you think? Have anyone used this approach? What are some drawbacks and gotchas? Also if you could comment on what JS Library/Framework you used and your experience with it, that would be great too.

Thanks

Answer 1

If the browser doesn't supports js you will block the user out completely. Also you will probably run into issue with some search engines. Notice that I say this because you are thinking on hitting a single url on the browser, and then using only js for the rest. The same goes for having it all in flash and silverlight for that matter. Any of those work nice for private info, or features that aren't meant to go in the search engines, but for the rest of the info you really want different urls.

That said: asp.net isn't so good at preventing the no js issues. Even the default paging for the grids as that issue - I got a site from a handfull entries in google to 2800+. The http://asp.net/mvc is better at making it clear with what you are working with.

Answer 2

This is a very lengthy topic covered by numerous people, but at its core the difference is basically this:

For very form-heavy web applications, which maintain a great deal of state information; frequently stay on the same page and behave similarly to a desktop application, the traditional ASP.NET WebForms model provides a lot of the glue to hold all that together for you.

For everything else, the REST/MVC model works best.

This is a generalization and does not apply to every single situation, but on the whole it's a good rule of thumb.

It's also very important to point out that if you don't have a captive audience (such as a corporate intranet, and sometimes even then) you should code your site, WebForms or REST, to work without JS. Then go back and add the sweet goodness for those who can support it.

Answer 3

Don't rule out a hybrid model. ASP.NET now supports server controls that natively output javascript to the browser. If you have traditional controls that render markup and use the ASP.NET WebForms model for posting data, consider modifying the controls to be ScriptControls, which allows you to handle loading data, etc. in your existing codebehind, but write javascript to handle the UI of the control entirely. You can write server controls that output the javascript you need (and set variable values, etc. with data from your codebehind during load), and then instead of doing postbacks, have your javascript communicate with a web service using AJAX. Definitely explore ajax.asp.net.