> 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
> 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
> don't see it 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
scripting language) 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, etc).
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.