How long has it been now since the last version?
A summary of ECMAScript 6 features
31–40 of 54 posts
Re: A summary of ECMAScript 6 features
#32The ES6 transpiler "6to5" was renamed to "Babel" a few hours ago:
Re: A summary of ECMAScript 6 features
#33Earlier quoted context omitted.
> I don't think people should be lauding this feature as some kind of solution to callback hell. Then async/await is no solution for it either.
I think: app.get('/thing', function (req, res) { try { await user = db.get({user: req.user}); res.send({user:user}); } catch { res.send(400); } }); beats the hell out of: app.get('/thing', function (req, res) { db.get({user: req.user}, function (err, user) { if (err) return res.send(400); res.send({user:user}); }); }); especially when you have conditionals or loops that can look like: if (user.name == 'abc') { resp =…
And the promise version for comparison:
app.get('/thing', function (req, res) {
db.get({user: req.user}).done(user => {
res.send({user:user});
}, error => {
res.send(400);
});
});Re: A summary of ECMAScript 6 features
#34ECMAScript 6 is a mess Now there's a completely new function syntax that doesn't use parens and has different scope rules var odds = evens.map(v => v + 1); Enhanced object literals: // Computed (dynamic) property names [ 'prop_' + (() => 42)() ]: 42 what?? So it uses parens if there are no params, but not otherwise? Template Strings: `In JavaScript this is not legal.` Seriously another String delimiter? `Hello ${name…
>So it uses parens if there are no params, but not otherwise?
Params are only optional if there is a single parameter.
Re: A summary of ECMAScript 6 features
#35It seems a little odd that class functions do not need a keyword. Speaking of which it would have been nice if we could use the shorter `func` instead of `function`. But in any case, I'm just glad private class members didn't make the cut. Whomever was responsible for that, thank you!
Re: A summary of ECMAScript 6 features
#36While a lot of these changes are cool, I'm worried that starting to work with javascript just got a lot harder. Although, I do appreciate the Class foo extends bar {...} syntax, now maybe we can have one simple way of doing inheritance which is readable to someone new to javascript.
Re: A summary of ECMAScript 6 features
#37While a lot of these changes are cool, I'm worried that starting to work with javascript just got a lot harder. Although, I do appreciate the Class foo extends bar {...} syntax, now maybe we can have one simple way of doing inheritance which is readable to someone new to javascript.
A lot of it just feels like cleaner versions of patterns people have been using for a long time. There's a few things I'm worried about:
* Tagged template strings might have some potential to be abused in interesting ways, since it looks like the tag function doesn't actually have to return a string.
* The Object destructuring/enhanced literals (and the Object rest/spread proposal in ES7) still take a lot of mental energy for me to parse. I'm worried they could be a maintenance liability in large projects, but that remains to be seen.
* Async functions/generators in ES7 will probably take a while to get used to, as well, but I felt the same way about Promises when they were first introduced, and they didn't turn out to be too bad. I don't have an issue with normal Promises/generators, so this might just be a matter of me needing to see the async stuff as a whole instead of the sum of its parts.
Re: A summary of ECMAScript 6 features
#38While a lot of these changes are cool, I'm worried that starting to work with javascript just got a lot harder. Although, I do appreciate the Class foo extends bar {...} syntax, now maybe we can have one simple way of doing inheritance which is readable to someone new to javascript.
A lot of it just feels like cleaner versions of patterns people have been using for a long time. There's a few things I'm worried about: * Tagged template strings might have some potential to be abused in interesting ways, since it looks like the tag function doesn't actually have to return a string. * The Object destructuring/enhanced literals (and the Object rest/spread proposal in ES7) still take a lot of mental e…
> A lot of it just feels like cleaner versions of patterns people have been using for a long time.
This was a pretty explicit goal, what they called 'paving the cow path'
Re: A summary of ECMAScript 6 features
#39Earlier quoted context omitted.
> I don't think people should be lauding this feature as some kind of solution to callback hell. Then async/await is no solution for it either.
I think: app.get('/thing', function (req, res) { try { await user = db.get({user: req.user}); res.send({user:user}); } catch { res.send(400); } }); beats the hell out of: app.get('/thing', function (req, res) { db.get({user: req.user}, function (err, user) { if (err) return res.send(400); res.send({user:user}); }); }); especially when you have conditionals or loops that can look like: if (user.name == 'abc') { resp =…
> I suppose it doesn't get rid of callbacks, just makes them readable.
You are the one who stated generators were no solution to callback hell but async/await was, yet here's what your code looks like with generators:
app.get('/thing', function* (req, res) {
try {
let user = yield* db.get({user: req.user});
res.send({user: user});
} catch {
res.send(400);
}
});
Re: A summary of ECMAScript 6 features
#40Maybe its just me but the only things that I really like from this document are "Unicode", and "Tail Call", though some other things may be nice, the verbosity is killing me, how many new keywords, synatic constructs, and symbols are coming in with ECMA6? Though I have no say in the matter, for my 2 cents, I just wish they had used ECMA6 to remove things (mainly those listed here: http://johnkpaul.github.io/presentat…
In JavaScript you can't make any backward incompatible changes, let alone remove anything. Because what browser would want to implement stuff that breaks websites for its users?