Why use transpilers/shims when ES6 is more supported in Chrome and other Browsers anyway? [duplicate]

Question

Judging by the ES6 compatibility table foundhere

Most shims and transpilers only implement below 70% of ES6 features, so why should someone use Babel/Traceur when Javascript ES6 is pretty much supported now in Chrome/Safari and Firefox by default.

I mean, if I was a developer at say Babel - surely it would be your number 1 priority to make sure you have ES6 and even ES7 features implemented before your competition.

Or am I missing something here?

Answer 1

Most shims and transpilers only implement below 70% of ES6 features, so why should someone use Babel/Traceur when Javascript ES6 is pretty much supported now in Chrome/Safari and Firefox by default.

Because some of my applications still need to support down to IE9 (we finally got your client to raise the bar to IE9). And it's not because of the lack of knowledge due to our client, it's because the users of that platform actually use this Browser.

Especially when your users are companies (or their employees) IE (not even Edge) is often still the standard.

"am I missing something here?" -Yes. You are missing decades of arguments about the relative merits of dynamic and static typing. Get to reading. – Jared Smith

@Daniel, none of your edits does change anything at this point made by Jared.

JS will probably never provide static type checking or compile time errors; because this is a substantially different approach to writing and publishing code.

I mean, if I was a developer at say Babel - surely it would be your number 1 priority to make sure you have ES6 and even ES7 features implemented before your competition.

Yes, I like using ES6 and use a transpiler when I need to, but I still consider ES7 features as unstable and work in progress. If the final implementation will differ from the current version I'd have to revisit and check every project I would have used it on. That's too much uncertainty to actually use them in production, so ...
I (as one of Babels's users) actually don't care wether one transpiler or the other already supports these latest features, unless there's a final standard published.

Although sometimes I like playing around with these new features and take like to take a look at their benefits, possibilities, limits and problems, and how to transpile them into current code.

Answer 2

In general, transpilers exist to convert code written for one environment to code written for a different environment. This can be done for converting code between entirely different languages, or merely between different versions of a language.

So early on when ECMAScript 6 was new and the browsers didn't support much or any of it, there were transpilers developed to let you use ECMAScript's new language features in browsers that only supported the "legacy" ECMAScript features.

Even though the newest browsers now support most or all of the new features, little has changed. You'd still use a transpiler to support those same previous implementations that didn't support those features.

At some point, a developer may drop support for certain browsers, which would mean that at that point they could stop transpiling the code. This decision is going to be made differently by different individuals, and so the transpilers will continue to be used for years to come.