Node.js v6.0 Released | Hacker News Reader

Node.js v6.0 Released

nodejs.org

728 pointsJoshGlazebrook159 comments

For anyone using TypeScript to build your Node.js code, you can now switch your target to es6/es2015 in your tsconfig.json:

    {
        "compilerOptions": {
            "target": "es2015",
            "module": "commonjs"
        }
    }

Assuming you're not using that 7% (http://node.green/) :)

Just make sure to update your package.json to take a hard dependency on Node 6+ if you do that:

    { "engines" : { "node" : ">=6.0.0" } }

This will make it so that ES6-compat is assumed and TS won't transpile ES6 functionality, but it will use commonjs for modules, which means your TS will almost be a 1:1 mapping with the compiled JS and everything should just work.

This should be ok 93% of the time

Probably much higher than that. 7% of the features aren't guaranteed to be used 7% of the time. There's actually no correlation.

Yes, I think he was being facetious <:)

Personal pet peeve: Please don't set the node engine field in npm packages. It potentially breaks your package whenever there's a new release candidate because `node@7.0.0-rc.1` is less than (!) `node@6.0.0` when it comes to npm's handling of this field.

that's surprisingly dumb, isn't it?

  semver.satisfies('7.0.0-rc1', '>=6.0.0')
  false

Weird. https://docs.npmjs.com/misc/semver#prerelease-tags

I guess the argument is that, if you're going to use ">=6.0.0" to choose a version of node.js, and your options are 6.1.0 and 7.0.0-rc1, you don't want a random release candidate. But if you're going to use it to verify an existing version of node.js, a 7.0.0-rc1 that someone else chose should be considered acceptable. Their semver rules can't distinguish these two cases.

PEP 440 seems to handle this by decoupling the prerelease rules and the version-comparison rules: https://www.python.org/dev/peps/pep-0440/#handling-of-pre-re... "Pre-releases of any kind, including developmental releases, are implicitly excluded from all version specifiers, unless they are already present on the system, explicitly requested by the user, or if the only available version that satisfies the version specifier is a pre-release."

Major releases are potentially breaking

But >=6 will obviously and gladly accept 7.0, so, no, that's not it.

Isn't it that `>=6` would gladly accept `7.0`, but `>=6.0.0` wouldn't?

Semver lets you do a lot of bad things like `*` that you should really never use.

Not really, you get a warning that said module might not support this 'release candidate' of a major breaking version.

Why does it act like this?

Npm doesn't actually enforce this field, unless engine-strict is set (off by default).

Indeed, and the latest versions of npm actually ignore engine-strict as well.

> because `node@7.0.0-rc.1` is less than (!) `node@6.0.0`

It is so PHPsque.

No sane people should use it for anything serious, except some lightweight browser scripting.

Sooo that's like, an npm design flaw then? If you don't specify the engine field, someone using an older version of node will just get incorrect failures and think your package is broken. I'd rather specify the engine and give a clear error to all users on a version of Node.js older than 1 day than to make it work for users on Node RCs. Although it would be nice if npm made it possible to support both sets of users.

node.js and JavaScript in general make PHP look a well designed decent language and ecosystem.

I cannot grok how can people chose this stack to create any product in it.

What does this type of condescending bile add to the discussion? Thousands of companies successfully use PHP and node to write excellent software every day. If you despise node so fervently, why are you even engaging in a thread about the latest node release?

Personally, I prefer ruby whenever its an option, but I've worked with node in the past and it's a decent platform that worked very well for the company (a commercial app servicing about 840k api and page requests per month).

I just don't understand the hate.

So negative opinions about '*' should never be expressed?

JavaScript is a terrible language, and imho es2015 fixes a lot of broken stuff in the only backwards-compatible way it can. That said, I find the entire micropackage culture around npm and node, coupled with the hundreds of packages that typically constitute build scripts for even a smallish node project make me realize just how brittle it is compared to competing platforms.

There's a difference between being negative with specific complaints versus hyperbolic, drive-by FUD.

Regarding your own complaints with Node. You're over-generalising. Nobody says you must use small modules. Larger libraries and frameworks exist. Same goes for build scripts. Also read this to get more context on small modules: https://github.com/sindresorhus/ama/issues/10

"Negative opinions" are fine. Heaping on condescending substance-free exclamations of ridicule in the middle of a thread about a specific issue regarding a platform you don't even use is just toxic arrogance.

Your "micropackage" complaint is daft; if you don't like small modules don't use them. Why is the language to blame for free, open-source code that you don't have to use? How is this even a legitimate complaint? You don't need hundreds of packages for anything and you can find examples of this in any language.

What language/eco-system isn't horrible, honestly? In some way? What's your "ideal" stack?

Professional, I have used or am using C/C++, Python, Ruby, Javascript, some Java, some C#, Golang.

Our of all of those the only one I don't really hate is Golang. In every other language/eco-system I can point to at least a dozen things that are awful. In Golang - maybe only 9.

Node has NPM with a huge eco-system. It's fast. Javascript, if written correctly, can be a pleasure to use, IMO. And even if you can't use it idiomatically for some reason, you can use Cofeescript/Typescript or whatever that forces some sort of code structure/discipline.

Node itself is decent if you understand how to ignore callback-pyramid-of-death with Promises and reactive-type programming.

Not all suck, at least not as much as the one in the discussion...

I have used most of those you listed, and some esoteric/legacy/proprietary stuff.

To me, with all its flaws, C#, Java, Scala, Python were the best, with goodness decreasing. I need to try F# as I feel I'd like it very much. Generally I believe in static type systems with proper generics support catching a lot of bugs up front, and are a pleasure to use, as my personal experience also shows this. You may not have enough experience with Java, or especially with C#, and I suspect that you may even find some of the greatest features there mere annoyances.

After being an experienced C programmer and having same JS experience I can say JS has the much same problems. Bad design decisions initially. Then sticking to the legacy. Lack of expressive power.

Writing correct code in JS or C is a struggle. For some reason both are overrepresented here on HN.

Lack of proper module module system makes JS inferior to most modern languages (C#, Go, Rust,...). (npm solves some of it), and it could be continued for pages, but for a believer/zealot it wouldn't matter.

Strongly recommend you get used to it. JavaScript is the universal language of the future. What can be written in JS will be written in JS. This is just a fact my man. Not because it's superior to other languages, it's simply because it is more cost effective to use. For example, at my current company, we are now using a Node Microservices architecture, Cassandra, Redis, Relay, GraphQL, and React. We're doing all our mobile using React Native. We were a Rails Angular shop before. All our engineers are now full-stack JS. We were able to get rid of 75% of our engineers using this stack...and then hire much higher quality engineers...JS experts. I can't tell you what a pleasure it is to work with this stack vs. something like Rails + Angular. And as for performance, it moves like nothing I've ever seen before. Warp speed brother. JS is the future my man. It's the only programming language I would invest my time in learning...i mean if you're concerned about job security and all. If not, I would spend my time learning Elixir and Phoenix. Also TensorFlow.

FYI for anyone looking for the downloads, v6.0 technically hasn't been released yet. It will most likely be out within a few hours.

Edit: of course right after I say it isn't released, it is released. :)

Release post: https://nodejs.org/en/blog/release/v6.0.0/

But I want it now!

    $ nvm ls v6
            N/A

    $ echo ':('
    :(

On a more serious note this really is an awesome release. Kudos to everyone that works on Node.js!

Ever since the "reunification" of node.js/io.js there's been a whirlwind of great activity both in adding features as well as LTS releases (which are critical for long term adoption of the platform).

And it's now on nvm :)

    nvm install v6.0.0

    $ nvm ls-remote v6
         v6.0.0

    $ echo ':)'
    :)

Sweet!

I was just able to download it (for macOS) from the front page.

https://nodejs.org/en/

I just got it on NVM.

~ 10 minutes later

Looks like there is not yet a Homebrew PR: https://github.com/Homebrew/homebrew-core/pulls

Current formula still points to v5.11: https://github.com/Homebrew/homebrew-core/blob/master/Formul...

EDIT: PR created: https://github.com/Homebrew/homebrew-core/pull/633

Looks like a PR was created ~4min ago.

Sidenote - was just messing with Homebrew a few days ago, and found it a little bizarre that all of the recipes are in source control and require a pull to update, rather than being on a server somewhere.

Such things can get painful for github

https://github.com/CocoaPods/CocoaPods/issues/4989#issuecomm...

I think that's a different issue.

That issue says that Homebrew is doing just fine. Not painful.

Seems reminiscent of the BSD ports approach, which is one of the major reasons a switch to FreeBSD (from Linux) is still on my personal roadmap.

I think you meant:

> all of the recipes are in source control and require a pull to update AND so they are on a server somewhere.

For posterity, this was merged in https://github.com/Homebrew/homebrew-core/commit/b8b57c76523...

On a related note, does anyone know if there's a way to tell Babel that your compilation target is Node.js v6.0 and only have it compile stuff that isn't natively supported yet?

Edit: Thanks for all the answers. I just went through the list of unsupported features and as I'm not using any of the remaining 7%, I might be able to get rid of Babel during development if I'm lucky.

Edit 2: Oops, still no es6 module support :(

Isn't Babel 93% redundant on the server side now? If you're not very dependent on the last 7% I'd just remove it.

I use it to transform async/await into generators for Koa. The module syntax is also much nicer to use.

Maybe I've got Stockholm syndrome but I prefer the module.exports style.

Came to note the same... really like async functions.

There's one remaining problem: V8 ES6 support is quite new and less optimized. If you're looking for optimal performance, you'll be transpiling for a long time (or possibly forever, 'cause those ES7 features are tempting, aren't they?)

Can't wait on that Exponentiation Operator and A.p.includes!

As you indicated, almost none of what was once called ES7 made it into the final spec: http://www.2ality.com/2016/01/ecmascript-2016.html

At least exponentiation is slightly cool. Hasta la ES8 siempre I guess.

The big missing thing is modules, which aren't in the kangax compatibility table.

In fairness, the babel approach to module handling is probably better than an in-browser es6 module implementation, or what may follow... compatibility with npm packages (cjs) will be significant for a while.

My understanding is that V8 will provide hooks that parse the module imports, then delegate to the embedder to fetch the actual source code and hand it back to V8 to load. I'd expect that the Node implementation of these hooks would work the same way as the existing require() machinery, so that existing libraries will continue to work.

ES2015 did not include a loader specification, only a module specification. https://github.com/nodejs/node-eps/blob/master/002-es6-modul... is the interop that will be present for node but it is outside of JS spec itself.

The javscript version of the hedonic treadmill ensures there will always be a juicy new feature that node/browsers don't have yet but Babel/other transpilers usually will. Just because it's 93% of the way there on ES6 at this moment doesn't mean that a few months from now people, your team included, won't be clamoring to be able to write with the new sweet features from ECMAScript 2017 or whatever. The only solution is to keep Babel a part of your stack perpetually and really that's not so bad in my opinion.

Remember that performance with Babel transpiled code is still sometimes faster (in some cases, substantially so) than the native ES6 implementations, as optimizing continues on V8's end.

And be sensible about how much transpilation you want, you can use newer presets that don't need to transform the code as much, while still having the ability to layer in newer features (async/await, ES7, etc).

I don't know the answer, but this would be useful in general given that much of ES2015 is supported by Firefox, Chrome and Edge. It's enough that I can imagine having an "evergreen browsers" build and an "everybody else" build.

It'd be not super useful yet, because there's no good way to minify ES2015 code.

This should do what you want. Don't know if it needs to be updated for v6.0

https://www.npmjs.com/package/babel-preset-es2015-auto

Babel 6+ is configuration hell, you can do whatever you want provided you have the patience/knowledge to plug together the right plugins.

So take the Node 6.0 compatibility table, find out what features it supports and create a "Babel preset" that has those excluded.

It looks like the primary thing missing is 'iterator closing'.

http://node.green/

...or just use a preset someone else made:

https://github.com/jhen0409/babel-preset-es2015-node6

Now that's thinking the npm way

Especially since this preset is two lines long, referring to two other plugins

I've not tried it but there is this preset https://github.com/jhen0409/babel-preset-es2015-node6

Hmm... I get the same thing on the REPL. Can you share what you see?

Oops, I was mistaken about that. It looks like all core modules are in local scope when in the REPL which is why `os.arch()` was working.

As others have mentioned there are node and browser specific presets you can use.

Also opened a PR for discussion about adding an environment award preset in babel or supporting it in core at https://github.com/babel/babel/pull/3476.

I'd love to see a Babel sort of thing that backs away from transpiling as much as possible and functions more as execution time polyfill.

Maybe an http2 server that uses browser detection to push polyfills so that your app can just assume everything works without transpiling up front?

I'm super hopeful http2 with es2015 modules will make web dev tooling drastically more streamlined in the nearish future.

Instead of Babel, you might want to look at Rollup.js for ES6 module support. [1]

You can have Rollup spit out CommonJS require commands for things that aren't part of your project, or you can use rollup-plugin-commonjs to wrap your entire app into one big bundle, including the CommonJS includes.

And as much faster as Node 6 has gotten with module importing, it almost can't be as fast as Rollup's module loader, which is more optimal than Browserify and WebPack, in that ES6 modules don't even get wrapped in "requires", but instead included inline. It just parses the code to ensure no variable names collide.

[1] http://rollupjs.org

How will es6 module support work in the long run, will node.js have to support two modules systems?

https://github.com/nodejs/node-eps/blob/master/002-es6-modul...

Interesting how this is written as a traditional press release rather than software release notes like most other open source projects

Here's the changelog: https://raw.githubusercontent.com/nodejs/node/v6.x/CHANGELOG...

Notable changes summarized here: https://github.com/nodejs/node/pull/6383

That's because it is a press release. There is a changelog and release notes too, it just happens that whoever submitted this chose to link to a press release instead.

That's because this IS an announcement blog post, in line with other https://nodejs.org/en/blog/announcements/. There is an actual changelog

I've been a front end developer for, well, quite a while, and in that time we've gone from cycles of around a decade (thank you IE6!) for new versions of JS to something closer to a couple of years.

The future, as I see it, is incredibly bright.

NW.js v0.15.0 beta released with Node.js v6 : http://nwjs.io/blog/v0.15.0-beta1/

I'm really curious to see the kinds of things people will cook up with the new Proxy object

And now available on Google App Engine (Flexible Environment).

Example app running v6.0.0: http://nodejs600.appspot.com/

Is there a plan for Node.js to get `import` any times soon? Will we need babel in order to use this for months? years? ever?

It needs to be implemented in V8 before Node.js can support it.

Are there any plans for V8 to do that soon?

They're working on it: https://bugs.chromium.org/p/v8/issues/detail?id=1569

There is/was a vote on this pretty soon. We are deciding how modules would work - with a new file extension? With a module.json? With a separate entry entry in package.json? Lots of decisions to be made :)

Surely they should work the way they work in ES6?

Any solution that requires extra work (file extension, another file to maintain) is a non-starter.

Frankly it should work how Babel transpiles it - because there's no reason for it not to.

ES6 didn't define precisely how module loading worked, one of the reasons it isn't actually implemented yet. And there are actual reasons why the method babel currently uses won't precisely match the actual implementations (see hierarchal v flat dependencies)

Those problems are just as present in CJS as far as I'm aware though...?

Yet they were solved for that.

Vote was at: https://github.com/nodejs/node/issues/5648

https://github.com/nodejs/node-eps/blob/master/002-es6-modul... was merged today; v8 C++ API for node to truly support it has not been implemented yet, should be in next LTS at current pace (next year).

Wow, a new extension for ES modules? That seems really unfortunate.

Why can't node parse a file to detect if it's a module? The presence of a top-level import or export means it's a module. If it's not, then the parsed file can be kept if the file is also in strict mode. If it's sloppy, it'll have to be re-parsed. Seems like a small penalty if the goal is to enable migration.

Also, why worry about ES modules importing Common JS? Just disallow that and let projects migrate to ES modules bottom-up. Then you don't have to worry about executing a Common JS module to determine what its exports are or circular dependency problems.

There is a pretty epic thread that I suggest you just read the tail end of https://github.com/nodejs/node-eps/pull/3#issuecomment-21476... . Basically we tried detection via source code as the first proposal; ambiguities at runtime that do not throw errors make it absolutely impossible to do safely, performance problems, and tooling integration problems.

Subjective, but .mjs just sounds horrid..

We looked at several alternative extensions and it was the least egregious of them: https://github.com/nodejs/node-eps/blob/master/002-es6-modul...

For those curious about the performance improvements, https://benchmarking.nodejs.org has you covered.

Any idea why the node-compat-table says 96%? http://node.green/

probably because the 3% is behind feature flag

Not sure, but http://node.green tests against nightly, which might be farther ahead than 6.0.0.

Uncheck "requires harmony flag " and it falls to 92%. I'm guessing the extra percent is a rounding issue.

I'm using webstorm to write a node app. I'm using ES6 and webstorm transpiles it to 5.1. Details here:

http://blog.jetbrains.com/webstorm/2015/05/ecmascript-6-in-w...

I'm using node 5.9.1 and webstorm creates a -compiled.js and -compiled.js.map file for each transpiled file.

If I use Node 6 which I understand is now up to 95% support for ES6, do I still need to transpile to ES5.1? Is anyone else using webstorm with ES6 and are you also going through this transpiling step?

"Fastest Growing Platform"

Does this refer to growth in number of users or in number of modules? Or maybe just counting the number of lines of code?

It makes me feel a little ill to think of all the new-ish devs jumping on the Node train, thinking it's the Next Big Thing in server code. It's a cool technology, and incredibly easy to get into, but then the curve gets so very steep as you try to make it behave like any of the robust and fundamentally sound language/framework app development ecosystems.

If I could offer any advice to anyone who is relatively new to all this, I would say choose anything else: Ruby/Rails, PHP/Symfony, Python/Django, Java/Spring, C#/.NET, whatever. You'll be doing yourself a favor. Learn how to do things correctly, in an tech stack that actually exists and works properly and makes sense, then see where things stand for JS on the server in a couple years. The bad habits, mistaken assumptions, and rampant misinformation being spread in the JS world these days is just amazing.

"Choose anything else" sounds like some FUD to me. I'm not an expert with all the technologies you mentioned but I feel like Meteor has just recently truly come into its own and I would pick it over Rails, Django, or anything PHP any day.

I think another factor is the level of conservatism of the programmer in question: would you rather work on stable but somewhat boring platforms at a large enterprise, or do you want to be on that new-new at a hip startup? (These options obviously exist on a spectrum.)

If you want to be in the fastest-moving, most exciting ecosystem around, it seems to me that JS is the train you want to be on.

This is a great news.

Are there any tools that statically or otherwise checks any potentially breaking pieces in the Node v4+ codebase/dependencies?

Note that the require mechanism is quite flakey, and they are discussing a new release or even reverting https://github.com/nodejs/node/issues/3402#issuecomment-2151...

Released where? Download page still points to v4.4.3 (LTS)/v5.11 (current)

In terms of LTS, it looks like they are going to let this bake until October before it becomes LTS: https://github.com/nodejs/LTS#lts_schedule

But yeah, I'm not seeing where the 6.0 was cut. It doesn't appear on their releases tab: https://github.com/nodejs/node/releases

Looks like the blog post was done a bit too early, it should be ready momentarily.

Edit: It's released!

Release build failed - https://github.com/nodejs/node/pull/6383#issuecomment-214844...

New one is running, and should be out soon-ish.

It's there now, awesome! Going to take it for a spin now

The blog post states `Download version 6 (Coming soon)`

I assumed that meant it was not yet downloadable.

Why doesn't tail call optimization get any love?

Unfortunately it get's lots of pushback instead. It seems very likely that syntax will get changed to `return continue fn()` https://github.com/tc39/proposal-ptc-syntax

Somewhat related there is no optimization for passing arbitrary length arrays with `...` to function having `...rest` as the last argument, which means [].splice is still a footgun:(

That explicit tail recursion syntax is pretty gross. Is there a precedent in any other language?

Clojure's recur is kinda-close, I guess?

It is, but Clojure uses it, because it cannot really do Tail Call Optimization due to constraints on the JVM. Therefore "recur" is required to keep the Stack from overflowing.

Rust has plans for a `become` operator for tail call optimization.

Is it stupid to still use v0.12 ? Last time I've checked I've had compatibility issues with all new (now old) io.js versions.

What sort of compatibility issues? Most packages update to work with new Node releases fairly quickly. Usually the packages that have compatibility issues are ones with native C++ bindings. If you `npm rm` the package and reinstall it, it will usually build correctly for the latest Node/V8 release.

Further, if you have a project that for whatever reason is not feasible to update to run on modern Current Node, you can use `nvm` or `n` to choose which Node release you want to use: i.e. `nvm exec 0.12 node old-project.js` and `nvm exec 6.0 node fresh-project.js`. v6 (and the versions that preceded it) has made Javascript really enjoyable to write.

Our biggest issue is to get off node 0.12, we need to get off protractor 2, and some of our protractor tests fail on protractor 3 for reasons no one has yet figured out. The only clue is a note saying selenium webdriver 2.48 changed how its control flow worked, but nowhere is what changed from 2.47 to 2.48 documented.

You can't diff between 2.47 and 2.48 and see what changed? Or is that a binary part you don't have source access to?

"Showing 930 changed files with 13,029 additions and 10,187 deletions. "

Feel free to try: https://github.com/SeleniumHQ/selenium/compare/selenium-2.47...

It's a dependency of a dependency with multiple language versions in the one repository.

thanks, I will look deeper into it. I could not install certain packages even with a fresh and clean new node.js. NVM is not the issue (I know node version handlers like nvm or tj/n). I just wondered if I'm the only one who had this compatibility issues.

It might be worth trying to get to 4.2.0, which was the first LTS [1] release (due to the change in versioning, that's only six months older than 4.2.0).

1: https://nodesource.com/blog/essential-steps-long-term-suppor...

thanks, also thanks for the other comments. I will retry with LTS in future and do some more testing.

Is there a list of the remaining 7% features?

http://kangax.github.io/compat-table/es6/

http://node.green

http://node.green/

I like to see some benchmark for latency and throughput, as far as only official benchmark is exist.

Released where? It's not in the GitHub releases, not on the homepage either.

I'm assuming this is backwards-compatible with 5.X?

The major version bump indicates there are changes that could break some use cases. There's a partial changelog [0] in the v6 release pull request.

[0] https://github.com/nodejs/node/pull/6383#issue-151012738

Hope its not getting bloated

Why is there a press release for this sort of thing?

Do you have a problem with it?

interesting...considering JavaScript itself is a shaky language.

babel sucks - I never though I could hate something so strongly.

Just today I had to deal with the fact that babel wraps ALL your generators in some shit function.

Why ? just why ? generation function was supported in browsers longer then the age all the babel maintainers combined.

The worst part is I do not use babel myself - I wouldn't touch it with a ten foot pole but am forced to use it due to my stupid cowokers writing everything using babel - ( why does babel need .babelrc file ?? - is babel such a prominent part of your life that you need .rc files ?? and why does the .rc file need to be specified in every freaking folder ! )

1) babel's docs are also terrible

2) The people maintaining babel seem to actively market babel and then at the same time ignore questions and requests for better docs from the community.

3) Slowest compiler I have had the pleasure of dealing with - my babel watch process consumes a grand total of 150 MB of memory !!

Edit - had to follow HN guidelines

Generator functions do not have total browser support yet. IE11 does not support them. Node 6 is actually the first Node version with total support for them:

https://kangax.github.io/compat-table/es6/

Even if generation functions are not supported - its a tradeoff that is worth making since very few of our users use IE11.

That is not my main concern. Babel can wrap the code in 10 functions for all I care ( performance is also not a concern since we are not sending rockets to mars - just another technology sweatshops trying to sell viagra )

The wrapped function throws errors - since apparently you need to download some babel plugins for it to work. (ノಠ益ಠ)ノ彡

It's not just IE11, it's Safari 9 and older, iOS 9 and older, and Android 5.0 and older.

Generators are unsupported on all of them.

And if you're public facing, IE9-11 may be too big combined to not support.

>That is not my main concern. Babel can wrap the code in 10 functions for all I care ( performance is also not a concern

Babel code is actually faster than the native implementation of most of the ES2015/6 features atm.

>The wrapped function throws errors - since apparently you need to download some babel plugins for it to work. (ノಠ益ಠ)ノ彡

So you forgot to download some plugins and it's Babel's fault?

And, sorry, where does the entitlement come from? It's you who needs and uses Babel, even imperfect and buggy as it is, to get the job done, not the inverse.

As I have mentioned above, I do not write ES6/ES2015/ES2016...

Its the entire web community writing code in a barely function compiler.

>I do not write ES6/ES2015/ES2016...

So maybe not the best person to comment on the state of its tools?

>Its the entire web community writing code in a barely function compiler.

"I didn't include some plugins so the compiler couldn't work" != "barely functioning compiler".

- You can put the babel configuration in your package.json.

- babel by itself doesn't actually do anything. It depends on the preset you chose. There are now a bunch of presets that leave parts of ES6 alone (i. e. to use ES6 import with webpack).

- I have actually never looked at the docs :). Never had a problem with it (unlike the package manager from config file hell, i.e. webpack).

Yeah, webpack can be not fun at all... but, depending on your needs it can do what you want. Being able to configure CSS processed, with some stuff inlined, required from your components is pretty sweet...

From the HN Guidelines:

  Please resist commenting about being downvoted.
  It never does any good, and it makes boring reading.
  
  Please don't bait other users by inviting them to downvote
  you or announce that you expect to get downvoted.

sorry. I will edit it out.

I like the idea of Babel, but would prefer it as a sort of compile-for-production step. The performance and debugging complexity don't seem worth it as part of the development process. Seems like it'd now be possible w/ Node v6 and a modern browser to develop "live" in (93% of) ES6 and then just Babel-compile to ES5 for backwards compat at the end?

Which unfortunately loses the ES7 features.

you can have different configs for prod vs dev. Just compile the features your dev browsers don't support. Done.

You can use the env option to change the transforms per env http://babeljs.io/docs/usage/babelrc/#env-option

use babel-node (babel-cli) against src/ in dev, build and run against dist/ in prod.

I agree with you in part. Babel is not something I'm fond of (I can't seem to wrap my brain around phabricator as an issue tracker).

In fairness though, you can configure babel to use native generators if you intend to only support platforms which implement them. However, generators have also not been well supported for very long: http://kangax.github.io/compat-table/es6/#test-generators

You don't need a .babelrc file in every directory, your coworkers are doing something wrong. Also, in that .babelrc file you can customize the generator behaviour to your heart's content - if your coworkers have chosen bad presets then your issue is with them, not Babel.

I agree that Babel is slow. Hey, there's always Buble: http://buble.surge.sh/, but then you lose a lot of configurability. There's always a trade-off.

And yes, the generator stuff is far more verbose than it needs to be, but because Babel is trying to cover all browsers by default. It's like jQuery. Good news is you can opt out.

Lucky this post has nothing to do with Babel then!

I have the feeling Babel has a hidden lock-in.

When I look at the compat tables, everything is getting green, looks like a bright future, without the need of Babel anymore.

But I find myself using post-ES2015 features all the time, because, why not? Babel gets me the latest fix.

(static) class properties, decorators, bind... Also JSX! Even if all browsers are completely on ES2015 in the next months, I can't throw Babel out :D

But luckily it seems like the next ES releases are all much smaller, so maybe the browser-manufacturers will have caught up in 2016...

It'll probably be about 5-6 years until all of the features I use today are in supported in browsers and the last of IE has fallen off. I'm surprised SNI haven't pushed XP and Android < 3 out faster.

Whatever Babel is worth, between "hate this" and "stupid coworkers" that, this whole comment screams "unprofessional" and/or newbie.

Reply on news.ycombinator.com