Skip to content

Django and AJAX

Published on: July 2, 2006    Categories: Django, JavaScript

One hot topic that keeps coming up over and over again on the Django mailing lists and in IRC has to do with when Django will get “AJAX support”. There are two answers to that question; one can be stated with authority, and the other consists entirely of my own unofficial and non-binding opinion. Let’s start with the first:

We’ve already got it, and more is on the way

Doing AJAX with Django has always been pretty easy, though maybe in a way that’s not obvious to users of other frameworks. All you have to do is use a slightly different template — to return XML- or JSON-formatted data instead of HTML — and you’re golden.

This has gotten quite a bit easier in the past week, thanks to the first draft of a new module: django.core.serialization. In essence, the serialization system is designed to make it easy to translate Django model instances into various other formats. Serializers for XML, JSON and simple Python are now included in Django, so you could now do this in a view: 

from django.core import serializers 
def my_json_view(request):
    data = serializers.serialize("json", MyModel.objects.all()[:5])
    return HttpResponse(data, mimetype="application/javascript")

And voilà: you have a view which returns the latest five objects from a model in JSON format. Perfect for AJAX requests. You could even have the same view respond to both “normal” and AJAX requests by adding a parameter to the URL and changing output types based on that.

The same idea can easily be applied to most of the common operations people want to use AJAX for; comment posting, for example, could be handled by firing an XMLHttpRequest to a view which would save the comment and return it serialized in the format of your choice.

Jacob and I have also tossed around ideas for a Django “web services” API which would let you make calls from JavaScript or any other language to create, retrieve, update or delete arbitrary objects; the new serialization framework would make it extremely easy to have this output in any format you like, and would provide a powerful way for you to do pretty much anything you like via AJAX.

Is that it?

And now it’s time for me to step up on my soapbox and issue a big fat disclaimer: the following represents nothing more than my own opinion, and has no necessary bearing on what will actually end up happening in Django. This is just what I think, and doesn’t attempt to speak for anyone or anything else, and what I have to say on this topic is inflammatory and is almost certainly going to make some people angry. Read on with that in mind, and at your own risk.

So. You may have noticed that the above example dealt only with the server side of things, and left out the business of actually constructing and firing off an XMLHttpRequest. That’s as it should be, because — and I know this is heresy — I think people should actually write JavaScript instead of relying on a framework to handle it for them.

Yes, I know that Rails and TurboGears and all the other guys have those nifty “helpers” where you tell the framework what effect you want and it drops in the correct JavaScript for you. But something like that would be a really bad idea for Django.

Besides thinking people should write JavaScript when they need JavaScript, there are a couple of reasons why I feel that way: offering built-in systems for automatically doing XMLHttpRequests and other effects would tie Django to a particular JavaScript toolkit, which I think would be an awful idea. Or else it would require us to maintain code in the framework for all of the popular JS toolkits, which would be an even worse idea. It would also mean getting opinionated and telling people how they should develop, which is an absolutely terrible idea.

But the big, overriding reason is still this: it’s high time that a lot of so-called “web developers” out there finally grow the hell up and learn how to write JavaScript.

Whenever people start talking about how they’d like Django to offer the kinds of “JavaScript helpers” you find in other frameworks, they inevitably fall back to a single line of reasoning: “why should I learn JavaScript and deal with all those DOM quirks and other incompatibilities when all I want is this simple effect?”

My tried-and-true response to that has always been to ask why, if we buy that reasoning, a web framework should expect them to learn CSS just to float a sidebar on the left side of the page, or learn HTML just to put in a list of links. HTML and CSS have just as many quirks and incompatibilities across browsers, and can take just as much time to master, as JavaScript; why, then, should we expect web developers to have to learn any of them? Shouldn’t the framework just automatically generate all the client-side code?

Of course, that’s a ludicrous thing to suggest. HTML and CSS are foundational technologies of the Web, and no-one is suggesting that web developers shouldn’t have to know them. In fact, a “web developer” who didn’t know HTML and CSS has no right to the title.

But here’s the thing: JavaScript is just as foundational as HTML and CSS. Now, granted, when I first got into this business JavaScript was something of a red-headed stepchild; 99% of all the JavaScript deployed on the public Web was devoted to making images change when you rolled your mouse over them, and the other 1% was written by scary people who called it “DHTML”.

But now… now it’s 2006, and we’re slowly realizing that those “DHTML” guys were really onto something. The rich interaction possibilities opened up by JavaScript are being recognized for what they are, and have even spawned a whole raft of new buzzwords and new toolkits. And even though it was always technically that way, we’re coming around to see (or, in some cases, being dragged kicking and screaming into seeing) that the Web really is based on three technologies: HTML for structure, CSS for style and JavaScript for behavior and interaction.

Which means that here and now, in 2006, if you call yourself a “web developer” you have absolutely no excuse for not knowing JavaScript. And if you don’t know JavaScript, you have absolutely no right to call yourself a “web developer”.

Yes, JavaScript takes time and effort to master. And yes, there are still lots of inconsistencies in how the major browsers deal with advanced JavaScript. But HTML and CSS take time and effort to master. And advanced HTML and CSS are still rendered inconsistently in the major browsers. And, just as in HTML and CSS, it’s possible to write JavaScript which works around the inconsistencies. And, just as in HTML and CSS, smart people have already written that code and made it available online, for free.

So, once again: you have absolutely no excuse for not knowing JavaScript.

Of course, once you’ve learned JavaScript you should feel free to use toolkits like Dojo, MochiKit and Prototype; they provide tons of useful code for dealing with common situations and for smoothing out the wrinkles in the various browser implementations. That’s pretty much what libraries are for, and you should take all the advantage of them you can.

But, and here’s the thing, when you use those libraries to write JavaScript you should actually use those libraries to write JavaScript. Using a “helper” from your framework to call the appropriate code for you is like using a motorized wheelchair because you’re too lazy to walk. And, just as people who actually are walking will get places faster than you will in your powerchair, people who actually write JavaScript are going to leave people who rely on “helpers” in the dust.

So, to get back to the actual topic at hand:

Any questions?