With JavaScript, there is an interesting contrast between what its fans say are its strengths and what battle-hardened experience actually requires you to do.
For example:
- 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.
You've set up a straw man argument. Where are these JavaScript fans who are pointing to several well-known problems with the language (e.g. semicolon autoinsertion, the for-in loop, the poorly-thought-out type system) and saying they're JavaScript's strengths? No-one is saying the language doesn't have flaws.
JavaScript's strengths are that it's small and surprisingly powerful and flexible, in spite of its design mistakes.
(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.)
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.
Prototype systems are great. I use them all the time, even in other languages. Extending prototypes of existing objects is amazing and powerful, and can be used for some beautiful data structures.
There is nothing wrong with extending the prototypes of objects, as long as they are objects you own. Don't modify what you don't own is sound advice that applies to many things. I wish they went into detail on what the problem is with multi-level prototype hierarchies.
Nice. I'd never before seen a company language style guide where I agreed with every single point (Though I do tend to use "this" within my own classes, so I guess we're not in complete agreement).
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.
While it doesn't enforce the guidelines, their Closure Compiler enforces the variable types and encapsulations declared in the JSDoc comments with warnings.
http://code.google.com/closure/compiler/
On another note, a Google engineer argues against Crockford's arguments for functional inheritance while pitching the benefits of the Closure Compiler and Library:
http://www.bolinfest.com/javascript/inheritance.php
I find his points are well made.
not necessarily ... official language standards bodies might make decisions much more slowly than individual hackers or groups, and even when a feature is officially baked into a new version of the syntax, it might take compilers/interpreters several more years to all implement them properly. there's definitely a need for good lightweight static checking of guidelines in IDEs
The inclusion of const in JS predates its use by Microsoft in Internet Explorer, which doesn't support it (at least up to IE6). It's not that it won't respect its const-iness; it won't even do the initial assignment. The original designers at Netscape couldn't have foreseen this, so it's in the language.
The document says not to use const but you can use @const when appropriate. Can anyone explain what @const does? In the documentation example code it looks like it is just in the comments.
For example:
- 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.