Drawing sparkles around the cursor ftw.
Nick Husher wrote:
>> var i = 5;
>> var i = 10; // no error here.
>> console.log(i); // prints "10"
>> Is that how it works? Is there any difference between the above and
>> something like
>> var i = 5;
>> i = 10;
>> console.log(i); // prints "10" still, I would imagine.
> Yes. Attempting to redefine a variable with the var keyword within the
> same scope is ignored. It's considered bad style to use the var keyword
> more than once with a variable (and certain camps declare it's bad style
> to use the var keyword more than once per scope), so represents a
> significant vector for bugs.
> I believe (although I don't know for certain) that the strict mode in
> first code example. As I mentioned, its goal is to maintain syntax
> compatibility while eliminating the major vectors for insecurity and bugs.
>> Currently, different implementations of JS can be pretty darn fast;
>> Granted. But the language does not lend itself well to real
>> concurrency. If you try really hard, you can simulate pseudo threading
>> by using setTimeout. In this respect, you can perform multiple
>> function executions in what would seem to be a simultaneous fashion
>> (even though you will not get the benefits of true threading by doing
>> being a hugely popular, scalable language outside the realm of browsers.
> The caveat of your above statement is that it's only in the context of a
> browser. setTimeout isn't a part of the core ECMAScript specification
> and there's no structural reason why a concurrency API couldn't be
> written into an interpreter, just that nobody has. The places that
> are strange and obscure,* but it's my estimation that this is because it
> rarely gets treated as a serious language, due in large part to its
> early uses in the web environment (drawing sparkles around the cursor,
> I don't see any real reason why a well-thought-out API exposed to an
> ECMAScript interpreter wouldn't be viable for creating large
> applications. The primary concerns--a dangerous global namespace and
> performance concerns--are manageable with tools like JSLint and a
> reasonably powerful code profiler. On the plus side, it offers a lot of
> features out-of-the-box that "real" application languages have to
> contort themselves mightily to do. Java's UI event handling and ugly
> attempts at aspect-oriented-programming would be far simpler in an
> ECMAScript environment, for example.