- Prototype object systems are great... except don't actually use this, it doesn't really work. Use our simulation of a classical object system instead.
- Lambdas are wonderful and powerful when combined with closures... except they leak memory. Don't use them, but declare named functions.
- The 'this' parameter was a stupid idea. Use it as little as possible, except when absolutely necessary.
- Be really conscious all the time, because of a stupid and misguided semi-colon insertion feature that will mess you up.
- Don't bother trying to use anything other than C style for loops over collections. They mess you up.
- The dynamic type system is nice... however experience shows us that what we really want is actually a static system, so JavaDoc types of everything with a cumbersome and extremely verbose syntax instead.
- Extending prototypes of existing objects is an amazing and powerful feature. Please don't ever use it.
(N.B. The bug with closures is associated with a problem in a single use case with IE6's garbage collector, and Microsoft patched it two-and-a-half years ago.)
Are you sure about that? From what I understood they couldn't patch it because some major unnamed web sites actually relied on DOM elements not being cleaned up to work properly.
As of IE 7, I remember I still had to close out memory leaks on some code that was binding an event to a DOM node.
My guess is that forced DOM tear-down broke cross-frame/window references. This is not necessary in implementations that let GC clean up DOM nodes.
What can you do with it that you can't do in class-based OO languages?
What extra does prototype-based subclassing give me?
Similarly object enumeration is tricky business because implementations don't agree, especially IE<9 doesn't support DontEnum attribute properly.
Type systems can be debated endlessly. In this case I think Google's choice might be motivated by GWT (avoids impedance mismatch with Java).
I loved that quote.
Great, concise explanations of why each point is good or bad (or not an issue). Opting for readability and debugability every time there's a choice.
Favorite quote: "You're better than that."
On another note, a Google engineer argues against Crockford's arguments for functional inheritance while pitching the benefits of the Closure Compiler and Library:
I find his points are well made.
abstract goto debugger enum native implements protected synchronized throws transient volatile
^^ All 'reserved' for future use.
const is used in the js 2.0 spec though.