I think there's no point trying to avoid memory leaks in older versions of IE. Circular references due to closures are too common and it's not worth messing with your code.<p>IE users are probably used to getting a horrible user experience anyway. I'm sure they can cope with a few browser freezes/crashes every once in a while - They know how to take a beating :p
The article mentions an idiom for iterating over an array. It says 'an even nicer idiom is...' and then it shows it.<p>I just wanted to say that the behaviour of this 'nicer' idiom may not be what's expected - it stops iterating once it hits the first falsy value. I was quite excited actually when I first saw them idiom, until I quickly realized its limitations
Very nice to see it starts off with a (correct) discussion of JS types! JS devs mostly don't know the actual types in JS, which is pretty crazy if you think about it.
> You can also use the unary + operator to convert values to numbers:<p><pre><code> + "42"; // 42
</code></pre>
> [...] However the "+" operator simply converts the string to NaN if there is any invalid character in it.<p>Being a bit pedantic here, why not recommending the Number function which may be less obscure for beginners?<p><pre><code> Number("42"); // 42</code></pre>
Whoa, the closure-based circular reference memory leak thing, is that just an IE issue or is that a language level (anti) feature? I need to know because I've very often done something like:<p>el$ = $('#whatever');
el$.click( function() { el$.find("a").css("color", "red"); } );
I think it's much easier to forget about "types" and think of objects instead. Trying to divide JavaScript objects into "types" will surely get you frustrated. If you absolutely want to check what "type" an object is, for example a sanity check for arguments passed to a function, you should make your own isMyType(obj) function and not rely on typeof or toString.
"JavaScript is an object oriented..."<p>No it isn't. It has support for OO and you can choose to write code object-oriented if you wish. But equally you can disregard the OO bit quite happily and compose behaviour using closures instead.<p>None of my favourite JS libs are OO, it's a poor abstraction imho.
This is a really good overview.<p>Along the same line but more in depth, I really like Cody Lindley's JavaScript Enlightenment:<p><a href="http://www.javascriptenlightenment.com/" rel="nofollow">http://www.javascriptenlightenment.com/</a>
For the second example on the memory leak section (<a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re-introduction_to_JavaScript#Memory_leaks" rel="nofollow">https://developer.mozilla.org/en-US/docs/Web/JavaScript/A_re...</a>), wouldn't just changing "el.style" to "this.style" fix the memory leak?
One caveat not mentioned is that while float is 64 bit floating point number, int is only 53 bit integer, unlike having 64 bit int in most other languages. Yeah, I've got bitten by this before causing a nasty bug.
Cool. Did Brendan Eich write it? What's he doing these days?<p>Keep up the good work Mozilla.<p>edit: I see MANY people contributed! You can too! <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Connect" rel="nofollow">https://developer.mozilla.org/en-US/docs/Mozilla/Connect</a>. It still would be cool if Eich could act as an "editor" to JS related articles!
Rediscover Javascript, by using :TypeScript, CoffeeScript or Node.js and a gazillion of slightly incompatible web frameworks ...
I wish DART had been there in the beginning.