Ask HN: If you targetting ES6 by default, how did you rationalize that choice?

TL;DR - automate your Babel config options based on targets.

babel-preset-env: A Babel preset that can automatically determine the Babel plugins and polyfills you need based on your supported environments.

It takes the data from compat-table [1] to generate a mapping [2] between a Babel plugin and the first version that a browser/env supports. We calculate the least common denominator of your targeted envs to determine the final set of plugins to compile with.

(Feel free to ask questions, I help maintain Babel and the preset). Just released a 1.0 a few weeks ago and looking for more help and usage! Looking into more help with removing unnecessary polyfills, and determining plugins based on performance via benchmarks of native/compiled.

And yes there is a lot of work that goes into making this work correctly (and in the foreseeable future with ES2015+). Would appreciate any help moving forward. And maybe we should just replace/recommend this preset instead of anything else to fight the fatigue..

[1]: https://kangax.github.io/compat-table/es6/ [2]: https://github.com/babel/babel-preset-env/blob/master/data/p...

* 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.

Working on a team of experienced non-browser devs, ES6 syntax allowed them to take the language seriously and actually try to do the right thing rather than 'commit atrocities of Javascript' (actual statement).

I think it all depends on your context and use case. If you're running code on the server, there's no reason to compile down to ES5 if you know that your node version can run your code without modification. At my company, we write browser-based tools for scientists, so we have a bit more flexibility in asking users to use modern browsers. We still use babel and target ES5, but we may move off of it before normal consumer websites do.

Whenever the cost of supporting old, ES5-only browsers (measured by the amount of time spent debugging/adapting code * dev hourly rate) surpasses the income brought in by users on those browsers, it's probably time to make the switch.

For the web app case, you obviously don't want to just cut out access to those users (that would be pretty bad customer service! that can totally ruin your reputation), so you also need to factor in the costs of educating your users about the upgrade, giving them enough time and/or providing an alternative means of using your app. (ex: an Electron-based app installer)

Considering how good the polyfills and transpilers currently are (assuming you already have those set up) the maintenance costs of supporting ES5 are very low. It makes very little financial sense to not support it for existing applications ATM.

If you're just starting with an app, that is going to launch in one year or more (assuming you're focused on a general audience , instead of a specialized market like corporate where browsers are updated more slowly) then I'd probably already start without worrying about ES5 at all.

I can write ES6, stick babel.js on it and my code will be both present-proof and future-proof.

Two things: template strings and arrow functions. Async is life-changing, but lack of support - can't use it yet.. Greatest feature since XMLHttpRequest IMO.

I limit myself to ES5 code on the client side for now and probably at least next year too.

By writing code that is compatible with the platform it runs on I'm able to avoid having a slow, lengthy or complex build process to reach that state.

If that's not what you meant, perhaps "justify" would be a better word to use. Or maybe just: "Why?"

[1] https://www.merriam-webster.com/dictionary/rationalize

You simply have to ask yourself, who do you want to sell your stuff to.

If you got a rather technical audience for example, chances are hight that most of them are using current browsers. So you simply develop for them and get a very simple build process, which eliminates many potential bug sources.

If you want to sell to Siemens, Bosch, Daimler. Chances are hight that they use IE11.

You can also start building for current browsers and if too many people complain or you get the feeling that you lose too much users by ignoring IE, you simply add Babel or something.

ES6 also nudges the code toward a bit more uniformity that can lead to better medium term maintainability.

There are several big reasons:

1) ES5 "classes" cannot extend ES6 classes (it's not possible to emulate a super() call in ES5), so:

1a) All the extendable built-ins are basically ES6 classes. If you want to extend Array, Map, Set, HTMLElement, Error, etc. you really should use ES6, and deal with emulating extending those classes in the compilation step.

1b) Really useful patterns, like ES6 mixins ( http://justinfagnani.com/2015/12/21/real-mixins-with-javascr... ) don't work when ES5 and ES6 versions are mixed in a prototype chain. That is, an ES6 mixin, compiled to ES5, can't be applied to an ES6 superclass. So if you distribute ES5 you're forcing everything above you on the prototype chain to be ES5.

2) It's much easier to debug uncompiled code, and all major browsers (as of Firefox 51) and node support ES6 well. Shipping uncompiled ES6 is a dream to work with comparatively.

3) ES6 is a much better compilation target for things like async/await because of generators.

4) ES6 is easier to statically analyze, so tools like TernJS and TypeScript (which can do analysis of regular JS too) can give better completions, etc.

5) It makes the pipeline from source -> packaging -> depending -> building for deployment much simpler.

Packages shouldn't assume too much about their eventual environment. That used to mean not assuming that the environment had ES6 or things like Promises. But times change and now that all the current environments support ES6, packages shouldn't assume that environments _don't_ support it.

So packages shouldn't directly depend on polyfills that most current environments have (Promise, Object.assign, new Array methods, etc.). Instead they should target standard ES6 and let the app developer who knows what they're targeting choose the necessary polyfills and down compilation. There's really too much bloat from packages forcing the inclusion of multiple Promise polyfills, or versions of core-js.

Also, it used to be that compiling dependencies was a major pain. You'd likely have to write custom build rules that compile and stage each dependency - because each dependency might have different language features and polyfill they might use. Now the packagers like WebPack and Rollup are so good at finding all dependencies statically, and we have a new stable plateau of language features in ES6, that the packager can compile everything it needs.

Of course if you use features beyond ES6, then those should be compiled to ES6. This implies a rule of thumb to move forward: Once all major browsers and node LTS have a feature, start assuming that feature and don't compile it out. For example, once Firefox and node LTS get the exponentiation operator, start distributing ES2016 (see http://kangax.github.io/compat-table/es2016plus/ ).

As a developer, the new versions of EcmaScript include good features that make easier the development of our applications. Also, ES6 is not a beta, it's a new version of the language. We are talking about frontend, so the execution environment of our application is unknown. However, the benefits of using the new features are big.

For me, the most important one is the new methods on basic types. With old versions of EcmaScript, I needed to rely in third party libraries to add some functionalities to my project. With the new versions of ES, my code is more independent from external sources.

Also, Babel provides backward compatibility for old versions of the language. As I mentioned, we don't know the execution environment of our project, but the TC39, the committee behind the decisions of the new features, has thought in this. Adding backward compatibility is a requirement for new features in the language.