moving more web presentation logic to javascript via jQuery

Question

I am building a new web based application in asp.net. Our backend has existing WCF/REST services that are returning JSON. I also have a JavaScript library that wraps up calling/consuming these JSON services for me client-side. This enables the app to make client-side AJAX calls and do things like a client-side repeater (Rick Strahl has posted about doing this with jQuery). This works quite nicely, and provides a snappy web 2.0 feel.

The question is, given the backend I have, and a JS library for plumbing - should I build out all my major list controls and other functionality completely client-side?? I have built out a couple pages with this already, and it is a little jarring to see nothing in my code behind! I am trying to get opinions on pros and cons of this approach.

Again, the JS library is built, the backend is build - so its just a question of should I build out pages and logic using jQuery (client-side repeaters and such), or the more traditional server-side approach.

Thoughts and suggestions are very welcome!!

Answer 1

Can you ensure that your audience will always have JavaScript enabled when browsing your site? If you can make that a requirement, then go ahead and do the front end in JS if you think it will be easier. If you can't guarantee that, then you need to do it server side so users without JavaScript can actually see output. You don't want a bunch of nothing showing up for people, right?

Answer 2

I'm interested in the approach. It allows you to hastily show the page and lazily show lists and other things that live in a repository.

Answer 3

There are definitely some negative implications to building everything client-side. It can cause a problem for vision-impaired users who are using a screen reader -- readers typically support some but not all javascript. It's worth trying out the site using a screen reader, at the very least. I believe it can also affect search engine indexing -- the GoogleBot or similar web crawler will not see anything on the page.

I've used some survey software that worked in this manner, and I can also say that it makes debugging on the client side become quite a pain.

There can be a middle ground, in which the basic structure of the page gets loaded normally, and tables and lists are loaded using AJAX, with a link available (that would be hidden for users with javascript) to reload the page with all data present.

Answer 4

It's an excellent question with which I too am struggling. My current concern is only for intranet situations where we control both client and server. In these situations my feeling is that it's best to take the middle ground. I think it is important that another developer can look at the .aspx and understand the gist of the page.

For example, if a table of data needs to be displayed, then instead of sending it out as json and then templating it on the client, which would not show intent very well, send it as an ordinary ASP.NET datagrid html fragment. The datagrid sitting on an .aspx at least shows the intent to display tabular data. And it's probably easier to do it that way as well.

Now, suppose you want to display a really fancy datagrid, that would be difficult to do using just ASP.NET. I would still send it as a simple datagrid, because jQuery can slice and dice it a lot more easily on the client than ASP.NET could have back on the server. And probably this will save some bandwidth as well. (Oh, I ALWAYS turn off ALL ViewState!) I try to let ASP.NET do the semantics, and the easy stuff that it is good at, and let jQuery do the rest.

In practice things get more complicated and fuzzy. As a long time Model View Presenter guy, I am starting to think of the View and Presenter as living on the client. The .aspx page is just a template that shows the gist of the page. And the code-behind (.aspx.cs) is nothing more than a thin layer that delegates to the Model.

While I have been very happy with the results of this architecture, still I feel vaguely uncomfortable about it, mostly because I can't unit test the presenter with trusty old NUnit, and also because jQuery and JavaScript are so powerful that it's like playing with dynamite.

The usual architecture experts are silent, this is all too new. I'm 100% sure that many have already studied exactly this kind of situation as long as 30 years ago, and sooner or later this will all be discussed at length everywhere you look. But it's a very interesting situation we are in right now, I wish more people would put in their 2 cents. Where's Martin Fowler? Scott Bellware? Uncle Bob?

Mike