5 ms·

So basically pattern matching, shorter syntax for lambdas, string manipulation à la Ruby (but with backquotes, why?) and… confusing list with array EVERYWHERE i

• Chris_Newton 12y ago
  That seems quite a negative view. The features mentioned in the article are only a small part of what is coming in ES6.[1] The “fat arrow” syntax for defining anonymous functions is much shorter and neater than the cumbersome notation we’ve had in the past: items.map(function (item) { return do_something_with(item) }) becomes items.map(item => do_something_with(item)) and there are both expression and statement variations of fat arrow functions, so we don’t need the return in this sort of situation either. There are also some other significant differences, particularly in what “this” means within the anonymous function. Combine that cleaner notation with the introduction of generators[2] and we can have lazy fluent interfaces for transforming data efficiently, along the lines of: items.map(item => item.interesting_property) .filter(item => is_wanted(item)) .reduce((item1, item2) => combine_usefully(item1, item2), initial_value) It’s not yet completely clear how we will take advantage of these possibilities in standardised ES6, because being backward compatible is a priority so you can’t just make sweeping changes like having all the existing Array.prototype functionality become lazy. This article[3] gives some ideas of how the kinds of utility library we’ve used in the past might look if they were written to take advantage of ES6’s new features, and presumably even if ES6 doesn’t include this kind of generator-based lazy functionality as standard it won’t take long before libraries are written to do it if they haven’t been already. Incidentally, that emphasis on backward compatibility also explains the use of back-ticks for strings with substitution. You need a new syntax that doesn’t change any existing behaviour, so regular single- and double-quoted strings can’t be used. There’s a lot more to ES6 besides just these areas. The article and this HN discussion are simply concentrating on some of the more interesting data-munging parts of it. For example, it also finally has a useful module system.[4] It really is quite a step up from today’s JavaScript in actual use; perhaps a good analogy would be the shift from Python 2 to Python 3, where the older version still does a decent job but a lot of little details are better in the newer one and the cumulative effect feels like a qualitative improvement in the language. [1] In practice, these features are already available today with only a small amount of effort, because you can use a transpiler like 6to5 or Traceur to convert ES6 code into ES5 that will run quite happily in any modern browser. These transpilers are straightforward to install and literally a one-liner to run, similar to installing SASS to convert an SCSS stylesheet to CSS for use in the browser. They are already integrated nicely with most other popular tools like Gulp, Grunt and Browserify. At worst you need a polyfill for a few features, but for example 6to5 provides one polyfill that does everything, so again this is a very simple thing to incorporate into your project if you do need it. [2] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/function* https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe... [3] http://aaronstacy.com/writings/if-underscore-was-written-in-es6/ http://aaronstacy.com/writings/if-underscore-was-written-in-... [4] Very sensibly, the transpilers used to work with ES6 today can just turn those ES6 modules into AMD or CommonJS modules for compatibility with other existing tools. For example, you can use a 6to5 plug-in with Browserify, and it will convert ES6 modules into CommonJS ones that Browserify itself can then work with in the usual way. Again, this is yours for the price installing the plug-in using npm and an extra command-line option to Browserify, or something similarly straightforward using other package managers/build tools.
  • JadeNB 12y ago
    items.map(item => item.interesting_property) .filter(item => is_wanted(item)) .reduce((item1, item2) => combine_usefully(item1, item2), initial_value) I'm not a JS programmer, but isn't this just items.map(has_interesting_property) .filter(is_wanted) .reduce(combine_usefully, initial_value) ?
    • Chris_Newton 12y ago
      Sorry, you’re right, that wasn’t a very good example. The use with `map` really is different: with a fat arrow, you can easily pick out a single property from each object in your container (not just whether it exists, which seems to be what you were getting at in your alternative). But yes, the fat arrow is unnecessary in the trivial filter and reduce examples I gave. I should have provided a slightly more involved example, such as this: items.map(item => item.interesting_property) .filter(item => is_wanted(item, some_criteria)) .reduce((item1, item2) => combine_usefully(some_context, item1, item2), initial_value) Now you’ve got some extra arguments to supply, so you can’t just pass the functions in directly when calling `filter` and `reduce`. In today’s JS (meaning ES5) you would generally need the older anonymous function notation. You might still have some shortcuts available, such as `Function.bind` if the order of parameters lend themselves to convenient partial application as in the `reduce` case here: items.map(function(item) { return item.interesting_property }) .filter(function(item) { return is_wanted(item, some_criteria) }) .reduce(combine_usefully.bind(this, some_context), initial_value) Of course in ES6 you can just choose whichever representation you prefer: items.map(item => item.interesting_property) .filter(item => is_wanted(item, some_criteria)) .reduce(combine_usefully.bind(this, some_context), initial_value) The other thing to watch out for when jumping between how today’s mainstream JS handles these kinds of manipulations and the new ES6 tools is what happens with `this`. It’s one area where current anonymous functions and the new fat arrow notation do behave differently, and unlike the `bind` example above, it’s not necessarily explicit what `this` will be when you start passing functions into other functions.