Hacker News new | ask | show | jobs
by Klathmon 3471 days ago
* It makes the language much easier to work with

* Most people familiar with JS will pick up on them very easily

* It makes "patterns" like immutable data and some straightforward async code MUCH easier (object spread, async/await, etc...)

* node.js supports it (with a slight speed penalty, however it hasn't bottlenecked us yet so we aren't worrying about it yet)

* Most modern browsers support many of the features, and those that don't the polyfills and compilation is pretty much "drop in" with the rest of our build system.

* Dead code elimination has completely changed how we architect our projects for the better

* const gives us less bugs by preventing overwriting and scope confusion

* One of the main applications we are using it on only supports newer browsers that support ES6 natively anyway (due to needing certain browser APIs), so using the full extent of those browsers doesn't seem like it's going to cause any issues.

and finally...

* There doesn't seem to be any downside. We are only using stuff which is already in the spec, or close enough to being finalized that we are comfortable. If performance is an issue we can just not use it in performance critical code, and it's just nicer to work with.

I will say that it's not all daisies and roses though. We are worried what will happen if the module loading spec goes in another direction than we think it will, not to mention that interfacing with external ES6 libraries is either done through transpiled common-js code (which loses most of the benefits of ES6), or through "hacky" solutions like a "nonstandard" field in the package.json which lets something like webpack load the ES6 version (which we have no idea what features they are using, might need transpiled, might need fixed, etc...).

Like anything, it's a bit of a gamble. But I'm confident that we will save more time and have less bugs by using the new features than we will lose to fixing modules to be inline with the spec or dealing with incompatibility problems.

1 comments

One interesting counterpoint to what you're saying: async/await are not ES6.

Although I'm 100% on board with ES6 adoption, there's a slightly worrying element of everyone having a different definition of what it is.

Some NPM packages have a "jsnext:main" attribute allowing you to redirect the "main" JS file to load, but it requires you to only use ES6 modules + features currently supported by Node. So you end up transpiling two versions from the original source. It's messy.

Neither is object spread, but yeah I've stopped worrying about those labels. For the most part people treat "ES6" as "all new JS features", and that's not going to go away soon.

Though when I see ES2015, I tend to take it literally.

But moving forward it's going to be important to see what version of the language people are using in their libraries. I can already see github badges for "ES2015 only" or "ES2016+" or something.

Or maybe a plugin which will scan the sources you import into your project and give you warnings if a library is using a feature you aren't supporting/transpiling...