HN Explorer

18 comments

[ 4.0 ms ] story [ 51.7 ms ] thread
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/
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.
spion
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.
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.
[deleted]
(comment deleted)
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.
zaius
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?

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.