You apparently mean to have separate builds for different browsers, which you will presumably serve up depending on some kind of user agent sniffing, or dynamically load after browser-side feature detection. That sounds complicated and error-prone. You'll also need to constantly rebuild your browser-specific versions as new browser versions come out, such as a version of Chrome that supports fat arrow.
What is the problem you are trying to solve? Do you believe that the native implementations will be faster? That's possible, but not necessarily the case, and if there is a difference it is likely to be minimal. Are you worried about payload size, since ES6 syntax is often more succinct? That difference is also likely to be negligible once JS is minified and zipped. I'd much rather have the same ES5 transpiled code running in all browsers, and avoid having to track down weird bugs where a certain browser's support of a certain ES6 feature, which you thought would allow you to avoid transpiling, turns out to be shaky.
I'll give you a concrete example. Let's say you decide that the code you compile for node does not need to transpile fat arrows, since you heard that node supports them with the --harmony flag. So you write
var foo = {
x: 42,
bar: function() { setTimeout(() => console.log(this.x)); }
};
foo.bar();
But then you find out that node does not support the lexicalization of this in fat arrow functions:
> node --harmony test.js
< undefined
Wouldn't you rather have a transpiler like babel reliably transpile this into correct ES5?
var foo = {
x: 42,
g: function g() {
var _this = this;
setTimeout(function () {
return console.log(_this.x);
});
}
};
> babel-node test.js
< 42
Once you are comfortable that all the browsers you want to support have implemented a particular ES6 feature, then most transpilers provide feature-by-feature flags that allow you to tell it to skip it.
A modified version of your proposal would be to have two builds, one fully transpiled, and one non-transpiled for browsers with complete ES6 support. That would allow you to avoid having to include the transpiler's runtime (such as babel's browser-polyfill.js) in the latter case. However, it would also prevent you from taking advantage of babel's support of ES7 features, some of which are very useful, such as async functions.
