Skip to content. | Skip to navigation

Personal tools

Navigation

You are here: Home / Steve's Blog / Learning JavaScript — again

Learning JavaScript — again

Posted by Steve McMahon at Apr 25, 2010 10:10 AM |
Filed under: , ,
Javascript's been changing. Or, is it me?

I used to think that JavaScript was a juvenile delinquent: an unfortunate child raised in a broken home; which is to say, a poorly designed language, worsened by bad implementations. Now I think it’s not half-bad.

Usually, when my opinion changes like this, it’s because I learned some things to convince me I was wrong in the first place: I changed. This time, I think it’s JavaScript that’s changed. Don’t get me wrong, it’s still poorly designed and unevenly implemented. But a programming language isn’t just the design and implementation; it’s the culture that surrounds it: the conventional usage, community standards, and common idioms.

Python has the incomparable advantage of great design and a good culture from the very start. It’s a privileged kid. JavaScript has had to grow a culture to compensate for its deficiencies.

So what’s changed my mind about JavaScript?

First, it’s jQuery. I’ve met people who use JavaScript as a general-purpose programming language, but for most of us, there’s one — and only one — reason to write JavaScript: live manipulation of a web page’s objects. While I can’t say jQuery is elegant, it’s really good at slicing and dicing the DOM and at hiding the implementation differences between browsers. And, it does so with paradigms that are recognizable to those of us who think that lists of objects are always the high-level object of choice. (I.E., our brains were damaged by Lisp.)

Next, it’s the developing consensus that there is a safe, sane subset of the language. Think of it as JavaScript-2. Working with JavaScript-2 is a mental discipline: it means pretending that some of the worst features of the language, like the big global name space, just don’t exist. (Don’t miss JavaScript: The Good Parts by Douglas Crockford) JS-Lint is the coding cornerstone of writing JavaScript-2: integrate it with your programming environment, turn up its sensitivity to paranoid, and run it every time you save a code file.

All is not nirvana for the Pythonista approaching JavaScript-2. There are still some unbridgeable chasms between Python and JavaScript culture. A few cultural differences I noticed repeatedly while chatting with folks at the recent jQuery Conference:


 

Python Culture

JavaScript Culture

Optimization

Premature optimization is the source of most evil. Write clear code first, last and always; get the algorithms right. Line-by-line code optimization usually means you got the algorithm wrong and need to refactor.

Every line of code is potentially a new hotpoint. Optimize as you write. Learn to think like a browser. IE will make mincemeat of your algorithms anyway.

Testing

Tests are something you do with code to prove code, as part of the definition of a problem space and its solutions.

Tests are something you do with a bunch of browsers. Probably every time you write a new line of code.

Wisdom

Cleverness is suspect. Our most-admired folks often begin talks by telling us how much the regret some clever bit of coding.

“Clever” is high praise. Usually for time-space optimization or finding a way to get around an IE bug.

i18n

You haven’t finished until it’s translatable and works with Unicode.

Other languages? This code is going to be rewritten for three new browsers before anyone will have the time to translate the messages.

Modularity

Big code files are suspect, and usually show that something developed organically and needs to be refactored.

Big code files are an optimization. Modularity is inefficient.

 

These differences strike me as mostly due to environment rather than language-definition (unlike the Rails culture, which has no excuses). JavaScript is mostly used in an environment where everything’s got to run in 100ms or less on a device which may be very slow and very busy. Those of us who have the luxury of writing server-based code have much more control over our environments. We’d be foolish not to add memory, processors, and even new boxes to help enable the programmer to think about algorithms and maintainability rather than User-Interface thread cycles. Writing JavaScript for the browser reminds me much more, in that sense, of writing assembler for my old 64k, 2.5mHz desktop than of writing code for Plone.

Given it’s bad upbringing and unstable home situation, I’d say that JavaScript is doing OK. At least, I’m giving it another chance.