Question

Using the tiny Diggit/Blog feature of StackOverflow described here:

I would like to post the following Google tech talk video I have just saw and that I found quite interesting.

I have always had problems understanding javascript ‘nature’.

Here, the JavaScript good parts are described by Douglas Crockford

I hope you find this link useful.

Now the question part:

What are your complaints about javascript? Do you use an IDE for javascript editting? Do you think this video helps to understand the ‘good parts’?

Answer 1

JavaScript: the bad parts.

1. The biggest mistake is late error detection. JavaScript will happily let you access a non-existant object member, or pass the wrong number of arguments to a function, and fill the gap with ‘undefined’ objects, which, unless you deliberately check for them (which is impractical to keep doing everywhere), will cause an exception or generate an unexpected value later on. Possibly much later on, resulting in subtle and difficult-to-debug errors appearing nowhere near the actual problem code. These conditions should have generated exceptions, except that JS didn’t originally have exceptions to raise. ‘undefined’ was a quick and dirty hack we’re now stuck with.

2. Undeclared variables defaulting to global scope. This is almost never what you want and can cause subtle and difficult-to-debug errors when two functions both forget ‘var’ and start diddling the same global.

3. The model of constructor functions is weird even for a prototype-based-OO language and confuses even experienced users. Forgetting ‘new’ can result in subtle and difficult-to-debug errors. Whilst you can make a passable class/instance system out of it, there’s no standard, and most of the class systems proposed in the early tutorials that people are still using are both desperately inadequate, and obfuscate what JavaScript is actually doing.

4. Lack of bound methods. It’s utterly unintuitive that accessing “object.method” when calling it makes a magic connection to ‘object’ in ‘this’, but passing “object.method” as a reference loses the connection; no other language works this way. When this happens, ‘this’ is set to an unexpected value, but it’s not ‘undefined’ or something else that would raise an exception. Instead, all the property access ends up on ‘window’, causing subtle and difficult-to-debug errors later.

5. There is no integer type. Number looks like one but breaks down in various ways (eg. n+1==n for high enough n). Any time a NaN or Infinity sneaks in (quite unexpectedly if you think you are dealing with integers) you won’t find out immediately; instead there will be subtle and difficult-to-debug errors down the line.

6. There is no associative array type. Object looks like one but breaks down under various unexpected keys. Arrays aren’t pure lists. Any time you ever use ‘for…in’, you have probably fallen into a trap, and will experience… yes, subtle and difficult-to-debug errors.

7. Generally poor string handling, for a scripting language at least. String.split(, limit) and String.replace() don’t do what you might think, causing… you know. The results of toString() are generally poor and not useful for debugging. Meanwhile we are stuck with a load of rubbish Netscape thought might be useful, like String.prototype.blink(), and the perpetually broken escape(). Yay.

8. And then there’s all the browser differences (IE is still missing a lot of essential methods on the basic objects), and the DOM…

9. And finally, even when an exception does occur, it is hidden away from view, so the author won’t even realise something is wrong. The result is that most sites are chock full of errors; turn on full JavaScript error reporting in IE and the result is unusable.

It scares me to think a new generation of programmers are learning this tosh as a first language. What’s worse, most of the tutorial material they’re learning from (“My fiRST AEWsome R0LL0VERZ!”) invariably encourages the worst possible practice. ‘javascript:’ URLs, ‘eval()’ for everything, browser-specific DOM access… oy.