

ES7 Array and Generator comprehensions - mdibaiee
http://dibaiee.ir/es7-array-generator-comprehensions/

======
zaius
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.

~~~
oldmanjay
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.

~~~
lobster_johnson
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.

------
aidos
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).

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

------
colanderman
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?

~~~
mmastrac
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.

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

~~~
zaius
You can use it now if you preprocess with babel -
[https://babeljs.io/](https://babeljs.io/)

~~~
lobster_johnson
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.

~~~
untog
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.

~~~
lobster_johnson
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.

~~~
untog
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.

~~~
lobster_johnson
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.

