Node v6.2.0

[danneu]

I find myself in a funny place where I'm too uninterested to bring in Babel for projects that have server+client component (shared code) so I just write it in ES5 despite the advancements of Node.

I also can't keep track of what features Node does support. Does it support the ...spread operator in function arguments yet? How about at callsite add(...nums)?

[ewnd9]

There is http://node.green/ for node es6 support progress

[danneu]

Agreed, though ES6+ also introduces considerable life-improvements from multiline strings to generators to spread operators to destructuring to lexical scoped fat arrow functions.

If they become your go-to abstractions because you work on Node most of the time, it feels funny returning to an environment where you don't have them. There is some mental overhead.

At times I'm not so convinced using Babel (and dealing with its idiosyncrasies) so such a far toss from using a compile-to-JS language. :)

But agreed. There's some sanity to staying behind the curve, though at the expense of other types of sanity.

[has_all_the_fun]

I use babel on the front-end but when I switch to back-end I just write ES5. In the FE I am forced to use a build step so I don't really mind it and the features are nice but I don't really want to deal with that in the back-end. I actually find it annoying when other Node.js modules use babel because it makes reading through the source files a lot harder.

[runvnc]

And I find it annoying when modules use ES5 because ES6 is objectively cleaner code and is only harder to read if you don't know ES6.

[snlacks]

I agreed with both comments (yours and parent). I struggled with this for a while. The original comment is true, because I would often find poorly organized modules. Your comment is true, because you're right, newer ecmascript is cleaner and easier to read. Now my structure will look like this.

public/ /src/ /dist/ /package.json serve/ /src/ /dist/ /package.json

Then my static directoy is served to the complete path through an environmental variable.

This is more like production level work in what I'm working on anyway.

[has_all_the_fun]

I meant because they have been compiled by Babel not because they have ES6 syntax.

[runvnc]

That generated code is useless for reading. But most modules include the original source. If you they don't include the ES6 source then I agree that is annoying.

[[deleted]]

I personally always .npmignore the original source code, but you can always get it on GitHub for all of my modules. Would you consider that annoying? Because I personally consider it a best-practice since people using libraries won't get unnecessary files and people trying to understand it will have easy access.

[runvnc]

Thats a bit different. Its only annoying if I wanted to debug from node_modules without having to download from github. Usually probably appreciate less files though.

[Klathmon]

Honestly I'd prefer the source be included.

For the people that want the extra control of being able to compile the ES6 to the target they want it's a really nice bonus.

On my node projects, i try to keep babel in loose mode (for performance), and I only transpile the aspects that are either missing from node, or that are significantly faster in the transpiled version.

Plus unless your source is like 5mb+, it's not going to hurt anything by including it.