Learning JavaScript

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

Lucas, I have no problem with frameworks that abstract away the mundane aspects of coding. But HTML, CSS and JavaScript are not mundane. I don’t want a framework that writes those things for me: despite what a lot of programmers think, they are not "low-level". They are the most important part of a web page: it’s what will finally be delivered to the end user.

Now, how they are put together on the server before being sent down the wire is another matter. I completely agree that, on the server, development should be as easy, pragmatic and productive as possible. But to then take it further and say that a framework should be producing your front-end code is introducing one layer of abstraction too many.

You’re setting up a straw man by saying that other programmers "think that programming should be as hard as can be, that we as programmers work to please our computer." http://en.wikipedia.org/wiki/Straw_man

Your argument suggests that we should all be using WYSIWYG editors to create web pages. After all, isn’t writing your own markup the equivalent to coding in Assembly?

The analogy simply doesn’t hold up with client-side technologies. And that’s the fundamental problem: too many programmers are trying to take practices that work superbly on the server (code reuse, abstraction) and apply them to the browser. HTML, CSS, and DOM Scripting rarely work that way. And nor should they.

If developers rely on their framework to write their JavaScript for them, they are effectively handing over control. That’s fine if everything works, but the end result is that the developer is a slave to the framework and not the other way around. The way that Rails makes it hard to write unobtrusive JavaScript is the perfect example of this: http://domscripting.com/blog/display/49

That doesn’t mean I’m arguing against using frameworks. I’m not. But a framework needs to draw a line. I think that Django is correctly drawing the line by not providing JavaScript "helpers".

Let me compare it to CSS again. You wouldn’t a framework providing CSS "helpers". Both CSS and JavaScript are front-end technologies and quite similar in a lot of ways (one specifies presentation, the other specifies behaviour). Comparing JavaScript to Ruby (or whatever server-side language you’re comfortable with) is comparing apples and oranges. Yes, they’re both programming languages (similar in many ways), but the environments in which they’re deployed are vastly different.

Frameworks like Rails or Django are great, time-saving tools. But if developers were to rely on a server-side framework to create client-side code, they would be selling themselves into slavery. It may seem like a pragmatic approach at the time, but when things need to be tweaked and changed, there’s no substitute for knowing the technology.

# Posted by Jeremy Keith on Monday, July 10th, 2006 at 5:47pm

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

Lucas, all the cases you have given for using "helpers" are situations where you already know how to do something, but you just want to get it done faster. Fair enough. I can’t argue with that.

But in a situation where you don’t know how to do something, reaching for a shortcut is invariably a bad move. If you read the original post, you will see that the people clamouring for JavaScript "helpers" in Django are designers who want to use JavaScript but don’t want to learn the language. That is exactly the wrong time to use any kind of shortcut.

We fundamentally disagree on this point:

"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!"

Yes, they are all programming languages, but the environment is what matters here. Ruby and Python are used for server-side programming. JavaScript is used in the browser (like CSS). That similarity is far more important than syntactical differences.

# Posted by Jeremy Keith on Monday, July 10th, 2006 at 6:50pm

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

Lucas, you’re not going win many hearts and minds with that tone.

Jeff, I agree that you know enough JavaScript to get by and that’s plenty for your purposes. As you say, you are capable of communicating with the JavaScript programmers on your team and that’s the most important point. I’m not suggesting that everyone needs to become a JavaScript expert; just that they should be reasonably well-versed in the language if they’re going to use it.

# Posted by Jeremy Keith on Monday, July 10th, 2006 at 9:58pm

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

Wouldn’t there be a performance hit to using these helpers? Can the JS still be cached on the client-side?

# Posted by Tony on Wednesday, July 12th, 2006 at 8:05pm

Sorry. Comments are closed.

July 2006
SunMonTueWedThuFriSat
      1
2345678
9101112131415
16171819202122
23242526272829
3031     

Recommended Reading

XML Subscribe

Grab the RSS feed for this blog.

JavaScript API

Grab the RSS feed of comments for this entry.