It’s crazy how fast the Javascript world is evolving now. I remember when Rails first was released 5 years ago, everyone was amazed by the handy AJAX helpers, which by today’s standards look like crufty globbed on crap. Then RJS dropped and everyone was stoked because they could do client-side manipulation without actually touching any JS.

But now, thanks in no small part to the efforts of guys like Douglas Crockford and John Resig (among many others of course) web developers are finally embracing Javascript for the wonderful language it is in its own right. Embrace Javascript fully leads to a more balanced consideration of architecture as you are suggesting here.

I was led down this path myself in several areas as AJAX interactions in my app got more complex. It’s probably hard for people to grok when they haven’t been faced with the particular details that come up in practice, but having experienced them myself this post hits the nail square on the head.

One example I worked through was a dynamic form consisting of many rows. Originally this was built a few years ago with a partial template representing a single row, and an RJS call to add new rows. The idea being that the HTML in the partial is DRY. It sounds good on paper, but as I needed to enhance this form I started having to jump through all sorts of hoops to inject the necessary state into the form. Things like generating unique dom ids so that the back-end and front-end can refer to the same element can get ugly fast.

At one point it became so ugly that I spontaneously realized that the server side didn’t need to know anything about these rows. I set up the javascript to build dom fragments of new rows. Yes, this was a duplicate of the structure present in the template, but that’s such an inconsequential detail. Once the client side contains all the state, I was able to simply delete 80% of the server side code (all the cruft). Now the server only had to generate a plain HTML fragment, and make one call to initialize the whole javascript mechanism. I ended up with 30% less total code, and a snappy interface where before there were AJAX calls. Even with a well-optimized (and topographically nearby!) 150ms response time, the instant JS response is a dramatically better user experience. On the front-end the javascript is now smart about everything. Handling UI edge cases is now much easier. The backend generates some base HTML and then JS initializes and maintains the states.

This technique taken its logical conclusion enables such things as an AJAX login that changes a full page to its logged-in state without a page refresh at all. For content pages that have only a handful of dynamic user-specific elements this type of approach can yield astonishing scalability improvements.

Another benefit that falls out of this is that some things are easier to compute on the client side then they are on the server side. Take dynamic user-specific comment in a complex page. Generally you want to load all the necessary objects in the controller, then render a template which may render many small nested partials. You do this because of the N+1 problem of each template loading the single record it needs. But this also requires that the controller anticipate what is going to happen in all the templates. However, once the page is rendered, if the dynamic elements are semantically labeled, the javascript can harvest them all in one pass and request them via AJAX efficiently. In effect, the partials can generate a semantic HTML "thunk" that is lazily loaded by javascript on the front-end. An example of this are loading user ratings and favorites at http://www.theauteurs.com/films. This small tweak makes the full page cacheable.

This comment was originally posted on Bamboo Blog

Thanks for commenting, I think you highlight some great examples. I struggled with the idea that the concept seems very clear to me, yet might be too abstract without concrete examples.

I think you are right to say:

"It’s probably hard for people to grok when they haven’t been faced with the particular details that come up in practice, but having experienced them myself this post hits the nail square on the head"

My hope was that for some people it will resonate right away, while others may only "get it" later after going through a similar practical struggle themselves.

This comment was originally posted on Bamboo Blog