JS Adolescence: Change of opinion regarding certain JavaScript practices

Repeatedly used inline object literals:<p>Object literals are one of the best features of Javascript, learn to love them. In the example cited, you already have a function dedicated to creating this object; why would you need to further obfuscate it by delegating the actual leg work to a buzzword-filled framework (or worse, vanilla constructors)? Even for more complex examples, I find it clearer and simpler to use an extend() or clone() method than something that tries to emulate classes.<p>Strict equality everywhere:<p>You cherry-picked two simple examples, but normally it's more complex than that. Javascript has rather odd coercion, and it will bite you if you try to memorize all the cases where it's safe to use ==. It's not really that === is "strict", it's just that it generally works how == was supposed to. More importantly, though, there's never any harm in using === instead of ==, so why would you use the latter? Why is === "overkill?" Because it's one character more? I fail to see the argument for not using it, except to play the devil's advocate.<p>Strict coherence to a standard:<p>This is a fine swing to take if you're doing hobby work, in fact it's very healthy, but if you're working on any sort of larger project where you are or will be collaborating with others, it is nothing short of essential to agree on standards for everything from brace style to camel case to testing frameworks. Almost every other argument concerning style, practices, and idioms falls apart in favor of consistency.

Why post this stuff? He offers opinion without explanation, this is the same type of JavaScript "wisdom" that probably had him following the conventions he is now nixing in the first place. I'm not sure if his "dogma" disclaimer at the end is ironic or a cop-out.

I disagree with abandoning one statement var declarations. This will bite you. A variable declared with var is in scope for the entire function because of hoisting.<p>It's also just bad form because of how people write Javascript, for example if you have an unfortunately long nested function with a variable declaration toward the bottom with a common name, say 'width' and later add that variable name a level up in scope and then think to use it in your function because you forgot or didn't know you had a var statement declaring width somewhere in that function you'll have fun staring into the abyss when this runtime error eventually presents itself.

I disagree with not using "inline object literals". They're basically maps, and in fact some programming languages (e.g. Self) are built around the concept of using maps instead of a list of arguments. I think in some cases this can be beneficial. Much more so than SomeWeirdCall(0, 0, 0, 0, 0, 0, NULL, "some data");

Aside from inline object literals, and using strict equality (which you should always be using IMO), what does this specifically have to do this Javascript? Everything else applies to general programming.

Funny; I comment the living carp out of my JS.<p>Mainly because I suck at it (I'm a designer, not a developer, dagnabbit) and it helps me keep track of what I'm doing.<p>Other than that, great article, taught me a thing or two.

Disagree vehemently with the idea that long variable names equate to bad API design.<p>The more descriptive your naming, the better your design and the less comments you require.

Can someone explain how this is potentially dangerous?<p>if (!cachedReturnValues[key]) { cachedReturnValues[key] = value; }

Here's a tip: you're still an adolescent. Come back in 5 years.