[1971genocide]

Babel has way too many errors.

I do not care if I am a grandpa for using 2014 tools - but I am not pushing ahead until things calm the fuck down.

[mikemaccana]

I was really slow on picking up Babel too. But I've been using Babel 5.x in production for six months without errors - main things were docs that referred to old versions of babel and babelify.

I needed to plug this in the package.json of my private modules:

    "browserify": {
        "transform": [
            "brfs",
            [
                "babelify",
                {
                    "presets": ["es2015"]
                }
            ]
        ]
    }

[krisdol]

Node.js is moving pretty fast at this point, after the io.js merger. I can understand using Babel to provide a unified, modern language API for browser applications, as there are so few guarantees you can make about a client's browser, but there already is a single API target for server javascript for any given version of node. Unlike browser JS, you can guarantee that the server development environment and the production environment will execute on the same runtime. Meanwhile, I don't trust that every Babel implementation of an unstable language feature will match the final official implementation. If it did, someone would just merge babel's shims into node and call it a day.

[sotojuan]

That's not "grandpa". Babel's creator himself has said he cares little about new syntax. Node 4 or 5 is more than fine.

[mattkrea]

Node 4/5 (really arrow functions alone) largely eliminated the need for Babel on backend code IMO.

[mercer]

To some extent, yes. In some of my projects I decided to avoid using Babel and just limit myself to Node's (new) features. The advantages of not having a build step for the backend js is sometimes worth it.

However, there are so many cases where Babel is useful, or turns out to be 'necessary', that I'm considering just using Babel by default again.

Some examples:

  - JSX for using React in the back-end (almost a default for me nowadays)  
  - async/await for async-heavy code  
  - a miscellaneous few still-unsupported ES2015 features that   occasionally are sorely missed

And finally, it's happing more and more regularly that I end up wanting to use some server-side modules on the client-side, in which case I need to set up Babel anyways.

That said, if I'm pretty sure I'm not going to need Babel, I still try to leave it out. It adds complexity that I'd rather avoid.