ES7 Array and Generator comprehensions | Hacker News Reader

ES7 Array and Generator comprehensions

dibaiee.ir

38 pointsmdibaiee17 comments

While I really like comprehensions, as soon as you need a conditional, or any level of nesting, you pretty much have to break it out into a loop to keep it readable.

OTOH, block syntax (I don't think that's the correct term for it) has always irked me in JS, due to verbose function declaration, and no implicit return. So beautiful syntax in ruby like:

    some_array.map { |el| el.length }
    # Or the succinct version:
    some_array.map(&:length)

Looks like this in JS:

    someArray.map(function() { return this.length; });

Now that ES6 has arrow functions with implicit returns, we can do this:

    someArray.map( s => s.length );

Since both comprehensions and implicit return functions are being released around the same time, I'll be interested to see which of the two gets more adoption.

You call it beautiful, but that's a fair stretch. It's more compact than JavaScript but to non-Ruby eyes, there's no real beauty to be found. It's just simple substitutions that otherwise look the same.

A key difference in Ruby is that while blocks are conceptually just another argument, they aren't part of the syntactical argument list. This:

  strings.map { |s| s.upcase }

is actually:

  strings.map() { |s| s.upcase }

...and this is what it's not:

  strings.map({ |s| s.upcase })  # Invalid

It's subtle, but it does make for a simpler, more readable syntax that lends itself to DSLs, since no parantheses are needed:

  validate :name { |name|
    errors.add("Bad name") unless name
  }

It's feasible in other languages, of course; Elixir, for example, introduces a Ruby-like "do" block syntax which is more regular than Ruby's. It might be too late for JavaScript, but I'm no parser expert.

They're simple examples that fit into one line. The difference is more notable on longer chains. I think people currently avoid this block style[1] syntax in JS because it's verbose. Arrow functions fix that.

[1] Again, not sure of the correct term for this - functional style?

Nice to see generator comprehensions in js. Glad that I don't have to remember anything much when coming from Python due to the choice of '('.

Does anyone know where the for..of syntax comes from? Just seems to deviate from the way that other languages represent comprehensions (including maths).

For…of loops are an ES6 feature that iterates the values of an iterable rather than the property names of an object.

This is bizarre to me. Why complicate the browser with a feature that amounts to syntactic sugar?

Why not keep JS simple (or better yet, simplify it further!) so that browser implementations might finally converge, and leave the syntactic niceties to preprocessors & compilers?

As someone who writes stock JS and avoids post-processors entirely, I want stock JS to be a decent language. Sugar like this is great, though promises in the DOM APIs are a different matter.

I read about stuff like this and then wonder whether I'll ever be able to use it since target browser platforms are so fragmented.

You can use it now if you preprocess with babel - https://babeljs.io/

You can also use it in Node.js if you install the Babel require extension, or run under the babel-node wrapper. It's not super convenient, though; I'm looking forward to a time when Node has full ES6 support.

It's not ideal in Node but I haven't found it to be that bad - I've gotten into the habit of making a bootstrap.js file that just has:

    require('babel/register')
    require('./main.js')

and carrying on like nothing ever happened.

Absolutely. I talked about this in the Babel chat room, though, and was told it was an antipattern, without being explained why. I still don't know why.

Apparently some people prefer to build a distribution of the entire project with Babel on deploy, which is fine, but it does cause an impedance mismatch with how projects are developed on the developer's machine; obviously both ways have to work.

A real problem with babel/register is the interface for including node modules, which I think needs improvement. You can't selectively include individual modules because the {only} option isn't additive, it replaces the default setting.

Maybe it is an anti-pattern because it alters the default - I mean, I guess it means it's processing node modules through the transpiler unnecessarily as well? I can't say I've experienced a performance hit myself.

Babel doesn't touch node_modules only you explicitly include it. Browserify lets you add this to an NPM package's package.json:

  "browserify": {
    "transform": [
      "babelify"
    ]
  }

...which is great, but Babel doesn't have anything like it for server-side stuff.

Its not an anti pattern unless you are writing a libray. Just remember that your application is recompiled by babel every single time you run it and on every process restart (if any), which may or may not be unacceptably slow.

Thanks for the link!

Reply on news.ycombinator.com