an obession with first principles

Client Side Thoughts – All the Rage These Days

Posted: Saturday Jan 28th | Author: JohnO | Filed under: Programming | View Comments

A programming post! I know, its a bit unusual considering all thats happening in the world. But this one is worth it. All the rage these is a gorgeous, smooth, animating, fully javascript-enhanced experience for web applications. And I’ve been building them. There really interesting part is the choice of technologies to use – particularly on the backend. We’ve stayed with the tried and true django. Which, out of necessity, requires that certain decisions be made. And django is a wonderful platform I truly wouldn’t imagine working without.

Lots of the current javascript enhancements are going on with “slimmer” backends (Mongo, Couch, Cassandra, etc). Which means that a lot of the traditional things a backend framework does are not done. So their front-end has to pick up the slack. In many cases this means defining models, and url routes. For those of us using beefy backends this definition is already done, and to replicate it on the front end would be ridiculous. So I feel that the beefy backends of the world are being left out by the adventures in javascript. It should not be so.

I’m already templating on the client side with @getify’s HandlebarJS. That brings along with it a nice Promise pattern implementation. And he has also written a nice Gate pattern implementation as well that I use. Of course I’m using jQuery, along with ajaxForm to handle form posts asychronously. And now we are using Plupload to deal with uploading media (ajaxForm does this with an iframe hack that is not very pretty). I’ve written some nice utilities for dumping django model data into JSON, a Command pattern implementation, and a Databinding implementation on the client side as well.

The trick that I would like to work on, is packaging all this goodness into a unified package that takes advantage of django in a much cleaner way. Getting class information and URL route information onto the client side is the first step. Wrapping the JSON returned from the server with this class info and URL routes, tied together to the Databinding interface gets you a model layer, with instance caches. While that model layer is defined in django. With a couple more nice additions a lot of maintenance/house-keeping code won’t need to be written.

The next thing that has jumped into my mind is pushState. But I haven’t played with it enough to know how to implement it in a “framework” type of way.

This client should be written to be entirely decoupled from the actual backend client. You are dealing in URLs, JSON blobs, DOM elements, forms, events and async calls. The fact that django provides this is inconsequential. You could start with a django backend because of all its benefits of getting up quickly. And you can migrate over to other sharded DBs or non-relational DBs or other data sources (e.g. memcache) as you need to scale.

This project’s first philosophical belief is to get up and running without duplicating your work on the client side (D.R.Y.). It’s second would be to work purely with native types as much as possibile (strings, JSON, DOM). It’s third would be modularity/loose coupling. Since its built on native types as much as possible you can use the parts you want, and only the parts you want.

  • Jeremy John

    A real programmer. Nice to meet you. I’m a drupal guy myself. It looks like I’m going to have to get more serious about JS.

blog comments powered by Disqus