Django is a framework for Python, often compared to Rails for Ruby. One of the differences between the two frameworks is that Django doesn’t offer JavaScript “helpers” that allow you to Ajaxify your web app without actually writing a whit of JavaScript.
As James Bennet points out, it’s actually pretty easy to get Django to send serialised data (XML or JSON) that you can use with XMLHttpRequest. But where are the helpers for developers who want to make use of this Ajaxy goodness? James tells it like it is:
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.
Amen! Read the whole thing. It’s extremely well-reasoned and culminates with this:
Using “helpers” to avoid writing JavaScript is bad and wrong. Learn JavaScript. Write JavaScript. It’ll be good for you.
As he points out, once you know the language, you can use libraries to cut development time and make life easier. But that’s completely different to using a library because you don’t want to deal with JavaScript.
There’s a lot of resistance to this idea in the comments (including the ludicrous suggestion that, just because JavaScript can be misused, it should never be used). There is a general chorus of “that’s not my job” from web designers… the same web designers who know all the cross-browser quirks of HTML and CSS inside-out. Why is there such resistance to learning a technology that is clearly useful and, these days, downright necessary?
I think there is a general perception that JavaScript is more complex than it really is. JavaScript is as complex or as simple as you want it to be. As Dean Edwards said, anyone can learn a little JavaScript and if you can learn a little, you can learn a lot.
There is a lot of FUD surrounding cross-browser issues with DOM Scripting. The truth is that JavaScript and the DOM enjoy much, much better cross-browser support than something like CSS. CSS developers might be pleasantly surprised. In my experience, it’s the server-side developers who throw up their hands in horror when something works inconsistently from browser to browser. Front-end coders, on the other hand, are used to working around browser differences. And, like I said, there aren’t nearly as many differences as people seem to think.
Learning JavaScript is something that you can postpone, but you really can’t avoid. If you make websites for a living in this day and age, it is your job to know JavaScript. James puts it even more strongly:
…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”.
Looking at this from the other side, I can understand why learning JavaScript might appear to be a frightening prospect to a web designer. Most of the JavaScript resources out there are pretty high-level: they get quite complex fairly quickly. That’s fine if you have a background in programming, but it’s off-putting for anyone else. The best JavaScript coders aren’t necessarily the best teachers; it can be very hard for them to recall what it was like not to know the basics.
That’s why I wrote the DOM Scripting book. It’s not that I’m a great coder (in fact, I’m decidedly mediocre) but I came to JavaScript from a design background. Some of the reviews on Amazon criticise the book for being too basic and hand-holding. But I think there’s a real need for resources at that level of simplicity.
If you want to learn CSS, there’s a ton of resources available, from the very simple to the very complex. But if you want to learn JavaScript, the resources seem to be non-existant or quite complex.
Also, whenever somebody who is learning JavaScript blogs their latest snippet of code, the reaction can be disheartening. More advanced coders will point out how the script could be improved (which can be helpful or otherwise, depending on the manner in which the advice is given). Others will simply say, “Hey, why not save yourself the trouble and just use this library instead?”
So, I understand why web designers don’t relish the prospect of learning JavaScript. From a distance, it looks complex and inconsistent; something best left to the hardcore geeks. That’s why libraries and “helpers” may seem like a godsend. But they’re really just crutches. They are not a good foundation on which to build your skills.
I hope that more front-end developers will start exploring JavaScript. I’m sure they won’t find it as intimidating is it seems. It can, and should, be a lot of fun.
Posted by Jeremy on Monday, July 10th, 2006 at 12:53pm
Comments
Ruby is a more terse language than JavaScript. C is a more terse language than assembly. The main reason Ruby on Rails provides helpers to javascript functions is because in the end it takes less code and less of a paradigm shift to write JavaScript. Both writing more code in JS AND because changing paradigms is very likely to introduce bugs in your code. Helper functions, at least in Rails, only barely covers up the JavaScript behind it… in a more real way it complements the JavaScript and gives you hooks to do more complicated JavaScript, while at the same time giving you faster access to what you need to get done. Ruby on Rails is very pragmatic that way.
Ruby on Rails was built from the beginning to be a collection of shortcuts to accomplish the mundane aspects of web development faster and with less code than ever before. There are a lot of programmers in the world that do not think writing less code, or writing DRY code, is a bad thing. They think that programming should be as hard as can be, that we as programmers work to please our computer… that the computer should not be a slave to our needs.
I can not argue against that, it is a major philosophical difference at the root of what we do, one based on faith and upbringing. You either love to find short-cuts, find smarter ways and faster ways to do your existing work… or you hate it. I love it, always have. If you really think it is a sin or a bad idea for one language to help you write code faster and more accurately in another, you probably think it is better to write assembly than C, better to write C than PHP or Ruby or Python, better to do all the work yourself than to let this massively powerful computational machine under your finger tips at this very second work and harder than it needs to.
# Posted by Lucas Carlson on Monday, July 10th, 2006 at 5:12pm
I think HTML and many cases of simple presentational JavaScript are mundane. I think that because I have typed them so many times, the exact same way, over and over again over my career. That, by definition, is mundane. If you don’t find that mundane, if you have not typed the same things over and over again, then I can see how you do not want your framework writing it for you.
I am not saying that a framework should write all the HTML or all the Javascript for you, just have shortcuts for the mundane parts.
My argument does not suggest we should all be using WYSIWYG editors to create web pages, my argument suggests that I like to seek out the fastest and easiest way to do web programming. For me, WYSIWYG would slow me down.
Also, I am sorry but CSS and JavaScript are not at all similar. Ruby, Python and JavaScript are all peas in a pod, all are turing complete programming languages. You can not go to the command line and execute CSS to print out Hello World!
# Posted by Lucas Carlson on Monday, July 10th, 2006 at 6:18pm
I can see arguments on both sides. The example of the WYSIWYG editor for building web pages is great ( as no web developer would see that as something good ), but I believe it’s off the mark for what we are talking about here. Disclaimer: I have never used Django, but I have used Rails and JavaScript very extensively. The problem is that comparing RoR helper’s to a WYSIWYG HTML editor isn’t right. I very much agree that trying to abstract all of JavaScript behind another language is wrong. But that’s not what Rails is doing. Rails is providing the equivalent of "keyboard shortcuts" for JavaScript. These are useful and aid in productivity, and just like keyboard shortcuts they don’t handicap programmers. I think it’s very hard to argue against keyboard shortcuts. My personal opinion that as long as helpers stay helpers along the lines of keyboard shortcuts and not complete abstraction of a language ( eg. WYSIWYG ) then they are valuable and should be added to a framework. To not is just silly. It’s not helping programmers learn anything new, it isn’t "saving them", it’s just making the tedious parts of the job stay tedious.
# Posted by John Butler on Monday, July 10th, 2006 at 6:19pm
So you think that it is the framework’s responsibility to police the designers clamouring for Javascript helpers… to punish them and not let them be bad… force them to learn Javascript. In the process, Javascript expert web programmers that would benefit from helpers get screwed, they have to work harder than they otherwise would in order to make people with less skill have to work harder.
I personally am not happy about giving up my time for people that don’t want to take the time to learn Javascript, I am not that altruistic.
Also, if you think Javascript is only used in the browser, please look at http://www.mozilla.org/rhino/ and http://en.wikipedia.org/wiki/JScript_.NET The reason that Ruby and JavaScript are related much closer than CSS and JavaScript is that as turring complete languages, you can write JavaScript in Ruby and you can write Ruby in JavaScript. They do the same types of things. CSS does something radically different, even if that radically different thing happens in the same browser that the Javascript is executed in.
# Posted by Lucas Carlson on Monday, July 10th, 2006 at 7:08pm
Since I’m one of the "chorus of web designers" who "knows all the cross-browser quirks of HTML and CSS inside-out" that replied to James’ post (James is a co-woe]rker of mine, for the record), I’ll clarify my position here…
I loves me some Javascript. I think it’s terrific, and I love the stuff that’s being done with modern DOM scripting. I’ve read Jeremy’s book and loved it. I can write a bit of Javascript here and there, but I’m no expert. More often, I pick one of the many great Javascript frameworks and let it help me along.
And my point is simply that, for my personal job, that’s all I need to be able to do. Sure, I could learn more — and maybe I should, for personal enrichment reasons. But, for my job, in which I am a web designer and have people like James working alongside me, I don’t need to be a Javascript expert. It’s literally not my job. That doesn’t mean it’s not the job of any web designer, but for me, it’s not a necessary skill for my position.
James, in his post, said that anyone who doesn’t know Javascript doesn’t deserve the title of "web developer." I found that slightly offensive, because I know countless CSS gurus, Python gurus, Ruby gurus, PHP gurus, etc. who are certainly skilled web developers but don’t really know Javascript.
And all I was trying to say in my comments to James is that I don’t believe every web developer (or designer) needs to know Javascript. If you want to learn it, that’s great. But some of us are privileged to work alongside Javascript experts and simply don’t need to add it to our repertoire.
For me personally, I believe an understanding of how to wrangle a framework or two into doing some basic things, and an understanding of the basic concepts of DOM scripting such that I can communicate well with the Javascripters on my team are good enough.
Tangentially, I agree 100% that Django should not include fancy Javascript helpers out of the box. Django is a backend framework, and AJAX/Javascript is a client-side behavior. I think Django’s approach of offering simple ways to get your data into JSON and other easily-paseable formats is perfect. It makes AJAX simpler, but leaves the Javascript to the front end, allowing the designer/developer working on that side of the picture to pick the framework of his/her choice, or simply write XHR Javascript directly.
# Posted by Jeff Croft on Monday, July 10th, 2006 at 7:31pm
There are a lot of times when the developer working on the backend is the same as the one working on the frontend. Also, to include utilities and helpers by no means ties you to use a certain way of doing JavaScript and Ajax work. You can choose to ignore the helpers completely and use whatever he/she picks or write XHR Javascript directly. Adding helpers in no way restricts such behavior.
# Posted by Lucas Carlson on Monday, July 10th, 2006 at 7:42pm
Lucas, it may not restrict such behaviors, but it certainly does indicate a preference and a "right way" to do things within the context of a particular framework. I don’t believe a backend framework ought to "prefer" one method of frontend development over another. Rails definitely "prefers" Prototype, and if you choose something else, you lose a lot of the cool stuff that Rails gives you.
Django’s development team (some of which sit next to me every single day — full disclosure and all that) are big-time believers in loose coupling of components. For that reason, they’ve made it very simple to choose, for example, a template language or ORM other than Django’s included ones. Likewise, I ought to be able to pick whatever Javascript framework I want for the front end and not be penalized for my choice (by losing some features of the framework).
# Posted by Jeff Croft on Monday, July 10th, 2006 at 7:51pm
"Rails definitely "prefers" Prototype, and if you choose something else, you lose a lot of the cool stuff that Rails gives you."
Yes, you have the choice between making life very easy if you choose Prototype… and just as hard as Django if you choose anything else.
At least you have the choice of making life easier.
Also, there is loose coupling in Rails too, if you choose to, you can write Ruby helpers for Dojo and quickly replace the ones that are there for Prototype. If that isn’t loose coupling, I don’t know what is.
# Posted by Lucas Carlson on Monday, July 10th, 2006 at 8:00pm
Lucas…
I’ve never used Rails, so I wouldn’t dare comment on it. I never said Rails doesn’t employ loose coupling, I only said that Django does.
I do know, though, that Rails indicates a preference for Prototype. It may be simply philosophical and not actually affect development at all, but I think it feels dirty for my back-end framework to be telling me what I ought to do on the front end. I want my back-end tools to not give a damn what sort of front end code I write. That’s all.
# Posted by Jeff Croft on Monday, July 10th, 2006 at 8:04pm
"I want my back-end tools to not give a damn what sort of front end code I write."
Rails doesn’t give a damn what sort of front end code you write. Rails doesn’t prefer Prototype. If you choose to use Prototype, Rails helps make your life easier. If you do not choose to use Prototype, Rails does not get in your way.
You are saying that because Rails integrates well with Prototype that Rails prefers it. I am simply correcting you… integrating well and tightly coupling are very different things. Tight coupling means you are inextricably entwined with it. Integrating well does not entail tight coupling.
# Posted by Lucas Carlson on Monday, July 10th, 2006 at 8:11pm
Lucas, then I’ll stand corrected. As I said, I’ve never really used Rails (other than a bit of playing around), so it’s not my place to comment on it. I get the impression it is tied very closely with Prototype. If that’s incorrect, then I’d suggest some of the marketing for Rails doesn’t lend the impression it should.
# Posted by Jeff Croft on Monday, July 10th, 2006 at 8:14pm
I don’t really care what you think of Rails or its marketing, I am more interested in what you think of providing loosely coupled helper methods within a web framework to assist in the writing of JavaScript. I think Rails benefits strongly from it and I think Django would too… unless James really thinks it is a framework’s place to police people at the expense of slowing down the experts that use their software.
# Posted by Lucas Carlson on Monday, July 10th, 2006 at 8:19pm
I touched on this subject myself. I wasn’t a fan of Rails’ helper functions because of the way it mixed JavaScript with your Mark-up.
# Posted by Sam Kellett on Tuesday, July 11th, 2006 at 1:01am
Link: http://cannedlaughter.net/2006/06/21/who-uses-linktoremote/
I didn’t realise it was going to strip out my HTML tags.
# Posted by Sam Kellett on Tuesday, July 11th, 2006 at 1:01am
I use Prototype independent of Rails because I dislike repeating myself. I did not start using the framework until I had grokked closures, JSON, and DOM manipulation (among other things, including the framework itself). Frameworks are tools for a web developer, just as swords are tools for a duelist.
However, until one understands the language (or the art of swordplay) at a more than superficial depth, crutches are all these tools will ever be. For most, this will suffice; for my part, I don’t feel comfortable blindly swinging a live blade. ;)
# Posted by Daniel Stockman on Tuesday, July 11th, 2006 at 9:55pm
Sorry. Comments are closed.