Design decision needed! I’m breaking my head over our user interface. We make quite elaborate geographical water-related websites at work (you can see a screenshot at http://lizard.org/). A heading with some navigation, a sidebar, a map (and possibly text and graphs in addition to it), some UI buttons here and there, that sort of stuff.
The question: how much ajax should we use? This is also an important question for Django as a whole. I remember Jacob’s keynote in Berlin in 2010 where he effectively said that all those new-fangled dynamic internet thingies were a potential risk to Django:
The web is in flux. NoSQL is taking up fast. Which can be a problem with Django’s original sql-only approach. And what about html5, client side storage, etcetera? It is in any case a challenge of what we know. Jacob’s tip: challenge yourself by examining all those nifty new scary technologies.
I might have paraphrased him a bit to much, but at work I see how much of Django can possibly be displaced by javascript. There are basically three possibilities for our websites:
Just use Django and plain html with a bit of javascript for a dropdown menu or some dynamic list sorting.
Go the full hog and make a completely javascript-based “single page app”. Django is little more than a glorified ORM with a REST interface that way.
Use something in-between, like using javascript to refresh portions of the html page instead of reloading the full page.
We’re currently using the in-between version. Often we just re-load the current page in javascript, take out specific divs and replace the corresponding browser page’s divs with them. It works fine, it is easy to understand and it works fast enough. But it makes some of my colleages cringe.
It makes them cringe as it (probably) feels so old-fashioned to them. Why inject html when you can just grab some json and render that with some javascript-based template language? Why not use backbone.js for the whole website? For an example of great new-fangled web goodies, see my colleague’s weblog at http://weblog.nyholt.nl/ . Highly recommended.
My thoughts are probably a bit old-fashioned. But I’d also like to think my thoughts still make solid engineering sense. Here are some of them:
Everyone on the team can understand Django’s urls. Even if we tie lots of apps together. If we use backbone, we’ve got two urls.py files to handle: Django’s and backbone’s. And Django is set up for multiple apps (which we have) and I’m not so sure about backbone.
Everyone understands how Django gets from a URL to a view+template and how to build it. Just visit it in your browser and make sure your html is OK. And fix and debug it. With a fully javascript page, debugging an individual json request might be even simpler. But it is a couple of extra steps before you understand where it eventually ends up in the user interface. You’ve got to read the html bare-bones template and the javascript that requests the json and you need to understand where which part of your javascript renders your json content with which javascript template and when/why/how it requests it.
You want DRY (don’t repeat yourself), so you cannot make both a django template and a json one. You can have only one, so you must have an empty bare-bones html page. So it means a couple of extra requests to build up the entire page. They might be quick, but it are a couple of extra requests.
Just fetching one sidebar is fine, but often (in our case) you need to update other page elements as well. So do you request a json for every one of the page elements (map buttons, print links, breadcrumbs)? Or a special UI json? Or do you put that info in the “main” json you request, even though that means hard-coding UI information into what’s supposed to be plain data json?
So… is it still OK to load HTML fragments into an existing page with javascript? It is a step better than just reloading the entire page. But it doesn’t even come close to a nice modern backbone-powered fully dynamic single page app… But the slightly-more oldfashioned approach might be easier to work with. And closer to Django, which is easier to work with and easier to understand than a possibly tangled mess of javascript. (Note: I do intend to use backbone.js to clean up and organize some of our existing javascript; backbone.js itself looks fine, I just dare question its broader use).
Opinions? Tips? Can you suggest a different way that I should look at this problem?
My name is Reinout van Rees and I work a lot with Python (programming language) and Django (website framework). I live in The Netherlands and I'm happily married to Annie van Rees-Kooiman.
Most of my website content is in my weblog. You can keep up to date by subscribing to the automatic feeds (for instance with Google reader):
