6 ms·

The problem with ES6 is that everyone has 2 features they like in it. The only thing that matters in my opinion is generators and (in ES7), async/await. This i

The problem with ES6 is that everyone has 2 features they like in it. The only thing that matters in my opinion is generators and (in ES7), async/await. This is a shift we've been seeing in many languages and I think actually tangibly solves a real problem in a transformative way. By that I mean, people will actually think about problems differently. Especially in JavaScript where everything is asynchronous, you need first class support of asynchronocity. There are a bunch of feature I "like" in ES6 but are ultimately useless in my opinion. Arrow functions are great, but could 1) be implemented in a transpolar, and 2) unfortunately behave different with regard to this and thus make the language even harder to understand (why did all my code break when I switched out the arrow function for a normal inline function?). Classes are horrible in my opinion, especially if they start inspiring people to use instanceof, which is a broken feature in Javascript (and hence why we need things like Array.isArray). Due to the fact that in JavaScript you will often have code from different contexts, you can't rely on these checks, and the old-style JS programming encourages you to use feature detection, whereas now you will think you can do something like this. The species properties (so map returns the right thing when you subclass Array for example), is even more complex. The fact that I can subclass Function is a bit absurd. The fact that subclassing Object, vs subclassing null, vs no subclass will be a lot of fun to understand. Let scope is fine I guess, I honestly never thought this was a big deal (coming from C and having to make the switch). It was of course implemented with TDZ which makes it incredibly hard to write in a transpiler, so now you have situations where the transpired code will work but once real let is added your code will break.

mkozlows 11y ago
async/await is one of those very C++-ish features, though, due to how it's implemented. Understanding ES5 async callbacks requires very little conceptual understanding -- you need to understand run-to-completion and the event loop (and I guess the idea of higher-order functions), but otherwise it's straightforward. Understanding ES2016 async/await keywords require you to understand all of that, plus ES2015 promises, ES2015 generators, and how they're all orchestrated together to implement async/await. The code looks simpler, but understanding what's really happening is a lot harder.
- tracker1 11y ago
  True enough... I've been using async/await for about 6-8 months now via babeljs, and tbh trying to explain it to people so they understand how it really works is a bit painful... a lot of people don't understand that an async function is simply a promise wrapper around a generator yeilding promise-friendly values. It's kind of important to understand promises to use await/async affectively. I love the easier to read/follow code though.
nawitus 11y ago
> but could 1) be implemented in a transpolar Why is that an argument against a new feature? Should we stop developing transpilable features? This creates fragmentation and a jungle of compile-to-JavaScript languages order of magnitude bigger than what we've got now. The more languages you have the more effort is required for having good tooling, which is already lacking. > unfortunately behave different with regard to this and thus make the language even harder to understand In my opinion they make the language more easier to understand, as the this keyword becomes rarely required, the code becomes more readable and you'll get rid of weird var that = this; or .bind tricks. > Classes are horrible in my opinion Classes are pretty nice. It's a syntax sugar which is nicer and easier to understand than using functions and prototypes. > Let scope is fine I guess, I honestly never thought this was a big deal It eliminates a certain class of bugs without a downside. I never use var anymore. I agree with the general point that ES6 seems to have focused a lot on not that important syntax sugar.
- johnmaguire2013 11y ago
  > Classes are pretty nice. It's a syntax sugar which is nicer and easier to understand than using functions and prototypes. I actually think that this syntax sugar is the opposite of a solution. It has always been tricky getting developers coming in from other languages (mainly C-like, and Java-like) to understand that JS is NOT an object-oriented language, but in fact is a prototypal language. By adding the class keyword, I think this only confuses those users further.
  - paublyrne 11y ago
    It has always been tricky getting developers coming in from other languages (mainly C-like, and Java-like) to understand that JS is NOT an object-oriented language, but in fact is a prototypal language. It's both.

mkozlows 11y ago

async/await is one of those very C++-ish features, though, due to how it's implemented. Understanding ES5 async callbacks requires very little conceptual understanding -- you need to understand run-to-completion and the event loop (and I guess the idea of higher-order functions), but otherwise it's straightforward. Understanding ES2016 async/await keywords require you to understand all of that, plus ES2015 promises, ES2015 generators, and how they're all orchestrated together to implement async/await. The code looks simpler, but understanding what's really happening is a lot harder.

tracker1 11y ago
True enough... I've been using async/await for about 6-8 months now via babeljs, and tbh trying to explain it to people so they understand how it really works is a bit painful... a lot of people don't understand that an async function is simply a promise wrapper around a generator yeilding promise-friendly values. It's kind of important to understand promises to use await/async affectively. I love the easier to read/follow code though.

nawitus 11y ago

> but could 1) be implemented in a transpolar Why is that an argument against a new feature? Should we stop developing transpilable features? This creates fragmentation and a jungle of compile-to-JavaScript languages order of magnitude bigger than what we've got now. The more languages you have the more effort is required for having good tooling, which is already lacking. > unfortunately behave different with regard to this and thus make the language even harder to understand In my opinion they make the language more easier to understand, as the this keyword becomes rarely required, the code becomes more readable and you'll get rid of weird var that = this; or .bind tricks. > Classes are horrible in my opinion Classes are pretty nice. It's a syntax sugar which is nicer and easier to understand than using functions and prototypes. > Let scope is fine I guess, I honestly never thought this was a big deal It eliminates a certain class of bugs without a downside. I never use var anymore. I agree with the general point that ES6 seems to have focused a lot on not that important syntax sugar.

johnmaguire2013 11y ago
> Classes are pretty nice. It's a syntax sugar which is nicer and easier to understand than using functions and prototypes. I actually think that this syntax sugar is the opposite of a solution. It has always been tricky getting developers coming in from other languages (mainly C-like, and Java-like) to understand that JS is NOT an object-oriented language, but in fact is a prototypal language. By adding the class keyword, I think this only confuses those users further.
- paublyrne 11y ago
  It has always been tricky getting developers coming in from other languages (mainly C-like, and Java-like) to understand that JS is NOT an object-oriented language, but in fact is a prototypal language. It's both.