Understanding JavaScript - Resource

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 q

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.

Answer 2

I really like prototyping, it feels much more powerful than normal classes.

Answer 3

The hard part about javascript, in my opinion, is:

1. Cross browser development/debugging issues
2. Cross browser dom/model issues (event bubbling, etc...)
3. Lack of "classes" (subjective)
4. Lack of good solid debugging support in browsers

Firebug helps a lot for FireFox, but I have not found anything that good for IE - and the mere fact that one has to is difficult.

On the bright side, if you build a script from the ground up and understand each step, it can be really enjoyable and powerful.

Answer 4

My biggest complaint while using JavaScript are the DOM bindings, but those are not really the fault of JavaScript so much as each browser implementing it their own way. Along those lines, IE is the worst offender.

In terms of pure JavaScript issues, I still don't fully grok prototyping in a way that allows me to use its full power; but that's less a complaint than my own personal failing. As a language I like JavaScript a lot, and any complaints I have on it are overshadowed by its interactions with the DOM.

I use Firefox + Firebug intensively for my main coding and debugging. There are debuggers in Opera and Safari that I use if either browser is having particular issues. Heaven help me when I need to debug IE.

I code in whatever text editor is available and has syntax highlighting. I tend to use the YUI framework, but that's just because I know it the best; I hope to someday learn more about other frameworks and decide which would be best for personal projects.

While I haven't seen the video, I just read "The Good Parts" this week. If the video is anything like the book, it'll be very helpful. The book itself is great because it's concise and informative. It goes into a level of language discussion that one doesn't see often enough when Googling for information, that gives one a better comprehension of the language as a whole.

Answer 5

alt text http://oreilly.com/catalog/covers/9780596517748_cat.gif   Javascript the Good Parts is a pretty decent book too.

For Javascript Firefox+Firebug and Notepad++ are my IDE. jQuery (and assorted plugins) is my Framework. My biggest complaint about Javascript is IE6