> This means that typeof can now throw<p><pre><code> >>> def f():
... type(x)
... x = 10
...
>>> f()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "<stdin>", line 2, in f
UnboundLocalError: local variable 'x' referenced before assignment
irb(main):010:0> def f()
irb(main):011:1> x.class
irb(main):012:1> x = 10
irb(main):013:1> end
=> nil
irb(main):014:0> f()
NameError: undefined local variable or method `x' for main:Object
from (irb):11:in `f'
from (irb):14:in `evaluate'
from org/jruby/RubyKernel.java:1101:in `eval'
from org/jruby/RubyKernel.java:1501:in `loop'
from org/jruby/RubyKernel.java:1264:in `catch'
from org/jruby/RubyKernel.java:1264:in `catch'
from C:/jruby-1.7.12/bin/jirb_swing:53:in `(root)'
public class Test {
public void f() {
boolean isInt = x instanceof Integer;
Integer x = 10;
}
}
>javac Test.java
Test.java:3: error: cannot find symbol
boolean isInt = x instanceof Integer;
^
symbol: variable x
location: class Test
1 error
</code></pre>
Oh no, it's now in line with just about every other lexically scoped language.
Whoop-dee-freakin’-doo???<p>Sure there's a zillion frameworks and patterns for shoehorning OO into JavaScript. But the point is, ES6, is standardising it. That means libraries going forward will assume this is the way it's done and build on top of it. It gives them more expressive power and better inter-op.<p>Also, default params are long overdue but I'm not sure that makes them "so what". I'd rather avoid mangling the arguments array in some awkward if statements.<p>Bottom line, there's a lot of things about JS that aren't great, but it's what all the browsers actually run so we're kind of stuck with it and any improvements are welcome.<p>(Even if you use something like ClojureScript or CoffeeScript, JS is still the target language and the runtime. Improvements and standardisation matter.)
><i>Classes. Whoop-dee-freakin’-doo.</i><p>There are dozens of ways to do classes/inheritance. Standardizing this means better tooling, documentation, and interoperability.<p>><i>Default parameters. By itself, this is another “so what” feature.</i><p>It's extremely useful in conjunction with named parameters. Named parameters are so much better than "option" objects.<p>If it's right in the function's signature, you can see right away how this thing is supposed to be used. Since it's declarative, it can be also picked up by your editor, too.<p>><i>let considered harmful</i><p>No, it's not. It makes variable declaration work like everywhere else. Function scope is the super weird anomaly.
> let considered harmful<p>Did people actually use the side-effect var-hoisting intentionally within their code?<p>Pretty much any JS style-guide worth its salt suggests manually moving var declarations to the top of scope since it's nice to know ahead-of-time which indicators of state you should be keeping an eye on.<p>The idea of inspecting a variable that is later-on defined with let seems baffling to me. I can't think of any reason why you would want to do this.
> let considered harmful: The problem with let is that it is not “hoisted” to the top of its block, as var is with its containing function.<p>Interesting point, but I disagree. I think that the lack of hoisting is one of the <i>benefits</i> of `let`. It works in a different way, which is more in line with other languages. Sometimes, you don't want a bunch of variables at the top of your function. Many functions do not need to be executed in the way that hoisting makes easier.<p>By the way, quoting Betteridge’s law of headlines at the beginning of your article whose headline is a question does not mean you get a free pass of using such a headline ;)
ES6 is fantastic and usable today using the excellent 6to5 [0]. I disagree with all of the author's points, I think these are great features.<p>[0] <a href="https://github.com/6to5/6to5" rel="nofollow">https://github.com/6to5/6to5</a>
Whats his problem with classes?<p>I find them a whole lot easier to reason about than prototype based inheritance. (But then I have more experience with class based languages).
JavaScript is definitely getting better. The only question is whether they are changing too much too fast. There'll be a lot of headscratchers when running into unfamiliar ES6 code.
So classes in ES6 are something I have very mixed feelings about, on one hand all that is being added is syntactic sugar for what is already being done, I'd like to repeat that ES6 classes add NOTHING that isn't already being done and all it really does is pave the cowpath that is being used in places like node<p>Currently:<p><pre><code> JSONParseStream.prototype = Object.create(Transform.prototype);
function JSONParseStream(options) {
Transform.call(this, options);
...
}
JSONParseStream.prototype = Object.create(Transform.prototype);
Object.defineProperty(JSONParseStream.prototype, 'constructor', {
value: JSONParseStream,
enumerable: false,
writable: true,
configurable: true
}
JSONParseStream.prototype._transform = function(chunk, encoding, cb) {
...
}
</code></pre>
With ES6:<p><pre><code> class JSONParseStream extends Transform {
constructor(options) {
super(options);
...
},
_transform(chunk, encoding, cb) {
...
}
}
</code></pre>
That being said, the fact that previously you could not simply use the word class meant that despite efforts of people unused to the language (let me tell you how many half assed class libraries i've seen in code written by people who mainly code in python or java but have some web code as well), unnecessary inheritance tends to be avoided. The lack of a class keyword tends to get javascript writers to avoid inheritance for things best served by mix-ins or object literals, or whatever. I predict that adding the class keyword, while saving me some time will also cause an uptick to unnecessarily convoluted inheritance patterns as new users find they can implement all of their design patterns verbatim without thinking if they really need the ajax method, the json parser, and the url builder to all be in objects that inherit from each other.
I'm sorry, but I really see no point in this article.<p>Do you realize that if the optional arguments were not included in Function#length, you'd just be saying "They are not reflected in the function’s length property. C'mon, man" instead ?<p>Also, I don't understand Whoop-dee-freakin’-doo.
Eh, a lot of the additions are improvements, a few are not, a very small few introduce some annoying features. It's an improvement, maybe not perfect, but still a big improvement. Disclaimer: I like JavaScript.
<i>Best of all, proper tail calls</i><p>When are proper tail calls expected to show up? Looks pretty bleak.<p><a href="http://kangax.github.io/compat-table/es6/" rel="nofollow">http://kangax.github.io/compat-table/es6/</a>
I'm more interested by how many people still seem to be using typeof instead of toString. What are you doing for array checking since typeof array === "object", !!x[0]?