People just adding cool toys not because they need it but because it is "cool" or "new".
Why do we need to "compile" our JS which just adds to our development time and then we have to dedicate time to debugging these when they break.
I like ES6 but sometimes I question whether it is worth the trouble.
Sure, some people only want to work with new things because they are novel. That's human nature.
However, that's not all of it. Many people strive for new tools not simply because they are new, but because they are better in some way. Of course, I understand that some people over-estimate how much better the "new" technology is, in practice. Transitions take time.
A side note: most "new" things are often based on combinations of "old" things. One of the big problems with some "new" tools isn't simply that they are "new" -- it has to do with their maturity. Applied person-hours, working on representative problems, helps shake out problems or edge cases with various technologies.
Take Clojure, for example. I reject the notion that calling it "new" or "old" is particularly useful. When it was released, it was based on many iterations of Lisp and the JVM. Clojure has been very stable.
Some people underestimate the importance of tooling and the ecosystem. Or they may underestimate integration; e.g. in the case of a new language, does it have a solid C or Java native interface?
Then you need to debugger your code, compiled code, sourcemap files, compiler, compiler options, the layer and layers of configuration JSON scripts and mobile browser.
Yes, transpiling es6 -> es5 is adding another layer of complexity to your codebase, another thing that could potentially go wrong, but the reality is that the development gains we get from being able to use es6 are far more important than a small chance of a problem. It works well enough that you don't even think about it after leaving webpack in watch mode.
Especially since ES6 is being converted to ES5 at the end of the day.
My team has been using it for most of this year now and we've had no problems so far.
es6 has become pretty well supported by modern browsers, so maybe after a year or so, we'll just be calling it "javascript" and running it without babel. I expect everyone to continue to transpile, though, to get newer features as they come, as the plan for ES is to release new language updates on a yearly basis.
This seems like you're deliberately trying to make things sound way more complicated than they actually are. If there is a bug in the code on a certain platform, you examine the bug on that platform and add the appropriate feature detection code to fix it. There is no need to debug the compiler and every other tool in your stack, it all compiles to javascript at the end of the day and assuming you're not running a minifier in development, 99% of platform specific bugs are readily apparent and almost certainly the developer's fault (i.e. not the tool's fault)
After with, do your team do automated regressive tests the oauth support and all other functionalities on all the regular browsers and mobile browsers?
+ Older version browsers?
+ Older browsers in older version of Linux, Mac, Windows?
+ Browsers with plugins such umatix, unblock origin, noscript that blocks scripts from your own domains + other domains?
Also that for the 10 other 'not any extra trouble' things
Until of course something breaks. Or is not giving you the result you wanted.
Or you need to urgently again and one of the hundred requires you need got a new bug or npm is out.