21–30 of 62 posts
Am I the only one to not understand the question?
I'm not sure - which part is not clear?
Please add some text to your title when you post on "Ask HN" (context, details, why do you ask the question, etc).
Am I the only one to not understand the question?
"ES6" is what people used to call "ES2015". So whenever I see "ES6", I translate that to "JavaScript with a lot of features that JavaScript used to not have"
In the JavaScript world, some people "target" an older version (usually ES5) because for a long time, browsers and Node.JS didn't support "ES6" features. So while many have written "ES6", at least in the past they would have to "transpile" (read: compile) it, and the output is ES5 JavaScript (which many browsers can read).
But in recent times there has been an increase in people who aren't transpiling down to ES5; in other words, they give browsers their "ES6" code, and just hope the browsers understand it. OP is wondering why people would do that, and many responses here provide spectacular explanations.
EDIT: reading through responses, it seems many people interpreted the title to mean "Why do you write JS using things that debuted in ES2015 or after ES2015?". In other words, people ignore "targetting" and assume that everyone is still using a transpiler that targets ES5
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/ ).
Presumably you mean in the browser, rather than node.js? When you can compile and use polyfills with babel and webpack, then why not?
Babel and webpack make debugging with the v8 debugger a nightmare. How do you approach that and avoid using console.log everywhere? console.log can be great and 90% of the time it's enough but for that other 10% I'd rather my debugging observe the execution context instead of being part of it.
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.
Earlier quoted context omitted.
In addition to sourcemaps, another option that I've been meaning to try is to skip most of the babel transforms for typical development builds. Chrome has had full ES2015 support for a while now and it looks like it now has async/await on stable, so it's getting to a point where it should be possible to just debug your ES2015/ES2016/whatever code within Chrome without needing source maps. You'd still need to do some…
(I feel like i'm all over this thread...) I actually tried this for a bit. I found that it really increased the complexity of the build system for not that much of a gain. Instead of having a "dev" build and a "prod" build, we needed a "chromeDev", a "otherBrowsersDev", and a "prod" build. So now you have 3 separate environments for your babel configs which you need to keep in-sync, and you run the risk of the semant…
What I've been doing is just writing in ES6 and testing on Chrome, then after its towards V 1.0 I'll add webpack to the staging branch.
Very little work to switch from a bunch of script tags to a bundle towards the end of active development, much faster than bundling every single time I change the code a little bit.
That is, of course, unless I have to compile typescript, then I'll just target ES5 anyways.
IMO, you should set up an analytics funnel to measure landing page conversion or (for web apps) usage metrics based on browser version. 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…