8 ms·

A summary of ECMAScript 6 features

124 points by sevko 12y ago

antjanus 12y ago
Awesome list. I'm happy to have saved it. I'd love to see a post about how to easily and quickly start transitioning without a hassle. :)
- kevincennis 12y ago
  6to5 has been mostly pain-free for me. Getting it to play nicely with my code coverage tool was a bit tricky, but aside from that it wasn't bad at all. Bear in mind that ES6 is fully backwards-compatible with ES5, so you can set up a transpiler without having to actually rewrite your whole codebase right off the bat. It's pretty easy to upgrade gradually if you need or want to.
spion 12y ago
Despite what people may say, ES6 is turning out to be a pretty great language all around. Type coercion is still pretty annoying and is there to stay, but the new features are all mostly well done. Now if we can only get the bind operator [1] in a timely manner, everything will be awesome. [1]: http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator http://wiki.ecmascript.org/doku.php?id=strawman:bind_operato...
- kevincennis 12y ago
  Hadn't seen that proposal before. It's definitely interesting. My first impression is that it's kind of confusing to read, but I suspect I'd get used to it. Sort of similar to some of the destructuring assignment stuff, e.g. `let { address: { street } } = user;`. Awkward at first, but now I'm kind of into it – although I still think people are likely to abuse it.
rzimmerman 12y ago
A lot of these features look great, and some of them are even useful. I think it's a shame that async/await has to wait for ES7. It would really give some direction to the node community and give JS an edge for async programming. Generators just look like another awkward attempt to avoid callbacks by jumping through different hoops.
- aaron-lebo 12y ago
  Generators have long been used in the Python community for reasons other than callback avoidance (they are lazy sequences). Generators in ES6 (as well as several other features) seem to be inspired by Python. There's no reason we'll have to wait for ES7. Seeing as how good 6 to 5 transpilers already are, I'm sure you'll be able to use await relatively soon.
  - rzimmerman 12y ago
    Generators in Python are a very useful feature (lazy sequences, like you said), so maybe I spoke to soon. However, I don't think people should be lauding this feature as some kind of solution to callback hell. I just feel like priority-wise, users would benefit most from modules (which made it), async/await, maybe class syntactic sugar, then everything else.
    - masklinn 12y ago
      > 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.
      - rzimmerman 12y ago
        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 = 5; } else { await resp = db.get_resp({user:user}); } await db.save(something); I suppose it doesn't get rid of callbacks, just makes them readable.
        nawitus 12y ago
shittyanalogy 12y ago
ECMAScript 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}, how are you ${time}?` Why aren't we just using #{} like everyone else? // Construct an HTTP request prefix is used to interpret the replacements and construction GET`http://foo.org/bar?a=${a}&b=${b}... What?? Destructuring: var [a, , b] = [1,2,3]; Is that seriously just whitespace and another comma? Splats (spreads?) f(...[1,2,3]) == 6 ... means destructure? This is not readable code: let fibonacci = { [Symbol.iterator]() { let pre = 0, cur = 1; return { next() { [pre, cur] = [cur, pre + cur]; return { done: false, value: cur } } } } } for (var n of fibonacci) { // truncate the sequence at 1000 if (n > 1000) break; print(n); } Symbols without a literal syntax: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Jesus Christ. Unicode: "𠮷".length == 2 Awesome, still wrong. Modules are cool. Promises are cool. Tail call optimization is cool. This is not readable code: // Proxying a normal object var target = {}; var handler = { get: function (receiver, name) { return `Hello, ${name}!`; } }; var p = new Proxy(target, handler); p.world === 'Hello, world!'; ES6 is a mess. Javascript just got harder.
- mythz 12y ago
  var odds = evens.map(v => v + 1); Is about as readable as it gets (inspired by C#, Java8, CoffeeScript), as a benefit of succinct syntax sugar we get intuitive `this` binding - i.e. pit of success. [ 'prop_' + (() => 42)() ]: 42 > what?? So it uses parens if there are no params, but not otherwise? Again not surprising, a leading `=>` would be a syntax error so `()` is an obvious compromise which can be naturally be extended to add args, e.g: evens.map((v) => v + 1) > Seriously another String delimiter? `Hello ${name}, how are you ${time}?` Yep, String interpolation is incredibly useful especially in JavaScript which does a lot of string munging - this will lead to more succinct, readable code. Should be obvious why they didn't want to break existing JS by re-using "" double-quotes. > Why aren't we just using #{} like everyone else? Who's everyone else (Ruby inspired langs)? Scala uses ${1 + 1} or $var shorthand (same as Groovy, Kotlin, JSP EL, Haxe), C# 6 uses {var}, Swift uses \(var) whilst Python and Java have string formats that use %(var) var [a, , b] = [1,2,3]; > Is that seriously just whitespace and another comma? It's clearly ignoring matching the second element. Some languages choose to use `_` as a special ignore placeholder, JavaScript chose not to. Either way is not unintuitive with what it does so that's ok. The other features are extremely useful if you need them, otherwise you can happily ignore them and use the subset you're comfortable with.
user_name2 12y ago
* Slavery
odiroot 12y ago
It's really hard to find browser support information for each of those. And every browser vendor chooses to develop every feature in different pace and order.
- itsbits 12y ago
  do you look into this...its gives you complete idea.. samplestitch.com.s3-website-us-east-1.amazonaws.com
- oblio 12y ago
  http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/
  - odiroot 12y ago
    I know about that. But seemingly it only shows limited set of browser versions. For me the most important thing is: what was the first version to support this feature. So I know I can actually use it -- comparing to my users' browser usage stats.
tomelders 12y ago
What's the story behind `let` becoming the new `var`? Seems odd to me to change the short hand for "variable" to `let`.
- oblio 12y ago
  Math notation, Lisp. These are probably the inspiration for it.
- ealexhudson 12y ago
  `var` is still there, but it is scoped differently - `let` scopes to blocks, e.g. if (foo) { let baz = 'quux'; ... } `let` in function scope is the same as `var`, in block scope it's narrow, it's basically the thing you want. `var` couldn't change, though, it would have broken existing code - hence `let`/
- deleted 12y ago
  [deleted]
skwosh 12y ago
I would have liked to have seen: * Skinny arrows as a shorthand for functions (for methods and constructors that don't get 'this' from outside. * Rest parameters with trailing arguments, e.g.: function zip (...xs, f) { ... } Seems like an oversight but I'm sure there was a reason (anyone care to comment?)... I guess arguments parsing isn't quite dead...
wildpeaks 12y ago
Also keep in mind that Traceur adds its own global runtime, I usually recommend 6to5 instead (despite what the name suggests, it supports some ES7 features as well and even JSX). Here's a good features comparison table of common transpilers: http://6to5.org/docs/compare/#comparison-to-other-transpilers http://6to5.org/docs/compare/#comparison-to-other-transpiler...
jarcane 12y ago
const map = (fn, [x, ...xs]) => (x === undefined) ? [] : [fn(x), ...map(fn, xs)]; This gives me the warm and fuzzies.
aikah 12y ago
Unfortunately Symbols are not that useful when it comes to private properties in classes. A better approach would be to use use weakmaps to have private properties. The problem with symbols is the absence of symbol literal syntax(along with the fact that one can access symbols through reflection).
jfaucett 12y ago
Maybe 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/presentations/empirejs/javascript-bad-parts/ http://johnkpaul.github.io/presentations/empirejs/javascript... and in Crockfords famous book http://archive.oreilly.com/pub/a/javascript/excerpts/javascript-good-parts/bad-parts.html http://archive.oreilly.com/pub/a/javascript/excerpts/javascr...) for instance.
- esailija 12y ago
  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?
g8gggu89 12y ago
How long has it been now since the last version?
wildpeaks 12y ago
The ES6 transpiler "6to5" was renamed to "Babel" a few hours ago: https://news.ycombinator.com/item?id=9052478 https://news.ycombinator.com/item?id=9052478 https://twitter.com/markdalgleish/status/566909414242660353 https://twitter.com/markdalgleish/status/566909414242660353
transfire 12y ago
It 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!
qzcx 12y ago
While 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.
- mmebane 12y ago
  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.
  - cwmma 12y ago
    > 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'
z3t4 12y ago
This is some scary shit! JavaScript is a mainstream language. That means average people like myself can be very productive with it. It is easy to learn and it's easy to find people who can maintain JS code. But it seems you need to be an academic in programming languages just to figure out what these new features do, and why they are needed. I'm afraid that the rapid development will make it harder to learn the language. And will introduce a lot of pitfalls and edge cases. Or maybe I'm just afraid of change!?
- acjohnson55 12y ago
  It honestly blows my mind that there is backlash against ES6. The new features solve so many pain points I've experienced in MVC and library development: - ridiculously verbose syntax for anonymous functions - lack of a module system - no string interpolation (seriously!) - no block scoping - super annoying - lack of language level support for immutability - clumsy 'this' management - clumsy variadic functions - competing promise implementations - competing and poorly interoperating class implementations ... And so on. This is a huge step forward and it should help redefine Javascript coding style in a much better way. My only complaint is that they didn't deprecate poorly designed features of the past.
  - z3t4 12y ago
    I've never read any programming books or taken any classes, I've just read a lot of code written by others and also written some myself. Here's my advice after 15 years of reading both brilliant and shitty JS code: a) Don't use anonymous functions ... You want your program to be easy to understand, so come up with a name for the function and put it as a sub-function at the bottom of the current function. b) I love the Nodejs implementation of modules and I would say it's the main reason behind Nodejs success. But it doesn't make sense in the HTTP world. Imagine having to download 100 dependency files each time you visit a webpage. c) I have a keyboard macro for " + + ". So if you don't save an extra keystroke, what's the deal? It might be useful if you have nasty habits like building HTML or SQL by concatenating strings though. (don't do that). d) Just declare your variables at the top of the function and stop worrying about scope, (while listening to Bobby McFerrin.) e) I can somewhat agree here. But where it's really needed you should make a copy or clone function. And if it's not really needed you shouldn't. Makes you write less complicated code because of laziness. f) Give it a name! function Car() {var car = this;} Or if you don't want people to understand your code: var that = this; g) You are probably trying to make your function do too much! If you Do want to have one function to rule them all, pass an object to it. h) It's possible to make async code intuitive. Stop using anonymous functions will help a lot! But it's not That easy. Promises is just another (ineffective; it just threats the symptoms) paradigm to reason with async code. i) We don't need classes. The prototype already work great. It might be hard to learn but once you understand it's brilliant! (I don't blame you if you never will, it's hard to learn an old dog to sit). I encourage you to use the paradigms you believe in, and also to try different solutions, and think outside the box. But don't force certain paradigms by changing the language itself. One exception being Node.js where you are forced into making modules. (but some people are stubborn and use Browserify to circumvent it).

124 points by sevko 12y ago

Awesome list. I'm happy to have saved it. I'd love to see a post about how to easily and quickly start transitioning without a hassle. :)

kevincennis 12y ago
6to5 has been mostly pain-free for me. Getting it to play nicely with my code coverage tool was a bit tricky, but aside from that it wasn't bad at all. Bear in mind that ES6 is fully backwards-compatible with ES5, so you can set up a transpiler without having to actually rewrite your whole codebase right off the bat. It's pretty easy to upgrade gradually if you need or want to.

spion 12y ago

Despite what people may say, ES6 is turning out to be a pretty great language all around. Type coercion is still pretty annoying and is there to stay, but the new features are all mostly well done. Now if we can only get the bind operator [1] in a timely manner, everything will be awesome. [1]: http://wiki.ecmascript.org/doku.php?id=strawman:bind_operator http://wiki.ecmascript.org/doku.php?id=strawman:bind_operato...

kevincennis 12y ago
Hadn't seen that proposal before. It's definitely interesting. My first impression is that it's kind of confusing to read, but I suspect I'd get used to it. Sort of similar to some of the destructuring assignment stuff, e.g. `let { address: { street } } = user;`. Awkward at first, but now I'm kind of into it – although I still think people are likely to abuse it.

rzimmerman 12y ago

A lot of these features look great, and some of them are even useful. I think it's a shame that async/await has to wait for ES7. It would really give some direction to the node community and give JS an edge for async programming. Generators just look like another awkward attempt to avoid callbacks by jumping through different hoops.

aaron-lebo 12y ago
Generators have long been used in the Python community for reasons other than callback avoidance (they are lazy sequences). Generators in ES6 (as well as several other features) seem to be inspired by Python. There's no reason we'll have to wait for ES7. Seeing as how good 6 to 5 transpilers already are, I'm sure you'll be able to use await relatively soon.
- rzimmerman 12y ago
  Generators in Python are a very useful feature (lazy sequences, like you said), so maybe I spoke to soon. However, I don't think people should be lauding this feature as some kind of solution to callback hell. I just feel like priority-wise, users would benefit most from modules (which made it), async/await, maybe class syntactic sugar, then everything else.
  - masklinn 12y ago
    > 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.
    - rzimmerman 12y ago
      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 = 5; } else { await resp = db.get_resp({user:user}); } await db.save(something); I suppose it doesn't get rid of callbacks, just makes them readable.
      - nawitus 12y ago

shittyanalogy 12y ago

ECMAScript 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}, how are you ${time}?` Why aren't we just using #{} like everyone else? // Construct an HTTP request prefix is used to interpret the replacements and construction GET`http://foo.org/bar?a=${a}&b=${b}... What?? Destructuring: var [a, , b] = [1,2,3]; Is that seriously just whitespace and another comma? Splats (spreads?) f(...[1,2,3]) == 6 ... means destructure? This is not readable code: let fibonacci = { [Symbol.iterator]() { let pre = 0, cur = 1; return { next() { [pre, cur] = [cur, pre + cur]; return { done: false, value: cur } } } } } for (var n of fibonacci) { // truncate the sequence at 1000 if (n > 1000) break; print(n); } Symbols without a literal syntax: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Symbol https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... Jesus Christ. Unicode: "𠮷".length == 2 Awesome, still wrong. Modules are cool. Promises are cool. Tail call optimization is cool. This is not readable code: // Proxying a normal object var target = {}; var handler = { get: function (receiver, name) { return `Hello, ${name}!`; } }; var p = new Proxy(target, handler); p.world === 'Hello, world!'; ES6 is a mess. Javascript just got harder.

mythz 12y ago
var odds = evens.map(v => v + 1); Is about as readable as it gets (inspired by C#, Java8, CoffeeScript), as a benefit of succinct syntax sugar we get intuitive `this` binding - i.e. pit of success. [ 'prop_' + (() => 42)() ]: 42 > what?? So it uses parens if there are no params, but not otherwise? Again not surprising, a leading `=>` would be a syntax error so `()` is an obvious compromise which can be naturally be extended to add args, e.g: evens.map((v) => v + 1) > Seriously another String delimiter? `Hello ${name}, how are you ${time}?` Yep, String interpolation is incredibly useful especially in JavaScript which does a lot of string munging - this will lead to more succinct, readable code. Should be obvious why they didn't want to break existing JS by re-using "" double-quotes. > Why aren't we just using #{} like everyone else? Who's everyone else (Ruby inspired langs)? Scala uses ${1 + 1} or $var shorthand (same as Groovy, Kotlin, JSP EL, Haxe), C# 6 uses {var}, Swift uses \(var) whilst Python and Java have string formats that use %(var) var [a, , b] = [1,2,3]; > Is that seriously just whitespace and another comma? It's clearly ignoring matching the second element. Some languages choose to use `_` as a special ignore placeholder, JavaScript chose not to. Either way is not unintuitive with what it does so that's ok. The other features are extremely useful if you need them, otherwise you can happily ignore them and use the subset you're comfortable with.

user_name2 12y ago

* Slavery

odiroot 12y ago

It's really hard to find browser support information for each of those. And every browser vendor chooses to develop every feature in different pace and order.

itsbits 12y ago
do you look into this...its gives you complete idea.. samplestitch.com.s3-website-us-east-1.amazonaws.com
oblio 12y ago
http://kangax.github.io/compat-table/es6/ http://kangax.github.io/compat-table/es6/
- odiroot 12y ago
  I know about that. But seemingly it only shows limited set of browser versions. For me the most important thing is: what was the first version to support this feature. So I know I can actually use it -- comparing to my users' browser usage stats.

tomelders 12y ago

What's the story behind `let` becoming the new `var`? Seems odd to me to change the short hand for "variable" to `let`.

oblio 12y ago
Math notation, Lisp. These are probably the inspiration for it.
ealexhudson 12y ago
`var` is still there, but it is scoped differently - `let` scopes to blocks, e.g. if (foo) { let baz = 'quux'; ... } `let` in function scope is the same as `var`, in block scope it's narrow, it's basically the thing you want. `var` couldn't change, though, it would have broken existing code - hence `let`/
deleted 12y ago
[deleted]

skwosh 12y ago

I would have liked to have seen: * Skinny arrows as a shorthand for functions (for methods and constructors that don't get 'this' from outside. * Rest parameters with trailing arguments, e.g.: function zip (...xs, f) { ... } Seems like an oversight but I'm sure there was a reason (anyone care to comment?)... I guess arguments parsing isn't quite dead...

wildpeaks 12y ago

Also keep in mind that Traceur adds its own global runtime, I usually recommend 6to5 instead (despite what the name suggests, it supports some ES7 features as well and even JSX). Here's a good features comparison table of common transpilers: http://6to5.org/docs/compare/#comparison-to-other-transpilers http://6to5.org/docs/compare/#comparison-to-other-transpiler...

jarcane 12y ago

const map = (fn, [x, ...xs]) => (x === undefined) ? [] : [fn(x), ...map(fn, xs)]; This gives me the warm and fuzzies.

aikah 12y ago

Unfortunately Symbols are not that useful when it comes to private properties in classes. A better approach would be to use use weakmaps to have private properties. The problem with symbols is the absence of symbol literal syntax(along with the fact that one can access symbols through reflection).

jfaucett 12y ago

Maybe 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/presentations/empirejs/javascript-bad-parts/ http://johnkpaul.github.io/presentations/empirejs/javascript... and in Crockfords famous book http://archive.oreilly.com/pub/a/javascript/excerpts/javascript-good-parts/bad-parts.html http://archive.oreilly.com/pub/a/javascript/excerpts/javascr...) for instance.

esailija 12y ago
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?

g8gggu89 12y ago

How long has it been now since the last version?

wildpeaks 12y ago

The ES6 transpiler "6to5" was renamed to "Babel" a few hours ago: https://news.ycombinator.com/item?id=9052478 https://news.ycombinator.com/item?id=9052478 https://twitter.com/markdalgleish/status/566909414242660353 https://twitter.com/markdalgleish/status/566909414242660353

transfire 12y ago

It 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!

qzcx 12y ago

While 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.

mmebane 12y ago
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.
- cwmma 12y ago
  > 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'

z3t4 12y ago

This is some scary shit! JavaScript is a mainstream language. That means average people like myself can be very productive with it. It is easy to learn and it's easy to find people who can maintain JS code. But it seems you need to be an academic in programming languages just to figure out what these new features do, and why they are needed. I'm afraid that the rapid development will make it harder to learn the language. And will introduce a lot of pitfalls and edge cases. Or maybe I'm just afraid of change!?

acjohnson55 12y ago
It honestly blows my mind that there is backlash against ES6. The new features solve so many pain points I've experienced in MVC and library development: - ridiculously verbose syntax for anonymous functions - lack of a module system - no string interpolation (seriously!) - no block scoping - super annoying - lack of language level support for immutability - clumsy 'this' management - clumsy variadic functions - competing promise implementations - competing and poorly interoperating class implementations ... And so on. This is a huge step forward and it should help redefine Javascript coding style in a much better way. My only complaint is that they didn't deprecate poorly designed features of the past.
- z3t4 12y ago
  I've never read any programming books or taken any classes, I've just read a lot of code written by others and also written some myself. Here's my advice after 15 years of reading both brilliant and shitty JS code: a) Don't use anonymous functions ... You want your program to be easy to understand, so come up with a name for the function and put it as a sub-function at the bottom of the current function. b) I love the Nodejs implementation of modules and I would say it's the main reason behind Nodejs success. But it doesn't make sense in the HTTP world. Imagine having to download 100 dependency files each time you visit a webpage. c) I have a keyboard macro for " + + ". So if you don't save an extra keystroke, what's the deal? It might be useful if you have nasty habits like building HTML or SQL by concatenating strings though. (don't do that). d) Just declare your variables at the top of the function and stop worrying about scope, (while listening to Bobby McFerrin.) e) I can somewhat agree here. But where it's really needed you should make a copy or clone function. And if it's not really needed you shouldn't. Makes you write less complicated code because of laziness. f) Give it a name! function Car() {var car = this;} Or if you don't want people to understand your code: var that = this; g) You are probably trying to make your function do too much! If you Do want to have one function to rule them all, pass an object to it. h) It's possible to make async code intuitive. Stop using anonymous functions will help a lot! But it's not That easy. Promises is just another (ineffective; it just threats the symptoms) paradigm to reason with async code. i) We don't need classes. The prototype already work great. It might be hard to learn but once you understand it's brilliant! (I don't blame you if you never will, it's hard to learn an old dog to sit). I encourage you to use the paradigms you believe in, and also to try different solutions, and think outside the box. But don't force certain paradigms by changing the language itself. One exception being Node.js where you are forced into making modules. (but some people are stubborn and use Browserify to circumvent it).