This debate isn't simple. I'll try to distill it as best I can.

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?

I don't know. Once you have ES6 -> ES5 in your pipeline, it's not really any extra trouble.

Sure

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.

Until it is.

But it isn't. There's no aspect of it that would be extra trouble. It's just mechanical transforms. That's like saying true refactoring is "trouble".

Until one found the code failed on some version on browsers, or worst - mobile browsers...

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.

I've been working with es6 for two years now and never even heard of this happening to someone. Given the huge number of people who use babeljs, if there were to be a bug in it, it'd be reported and fixed rather quickly.

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.

Really curious about the tangible gains of using ES6 over ES5.

Especially since ES6 is being converted to ES5 at the end of the day.

Block scoping (using const/let instead of var which is scoped to the function) alone is really nice, but I also make heavy use of destructuring, arrow functions, template literals, export/import syntax and promises. Es6 makes javascript more pleasant to code with, and can greatly improve readability.

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.

It adds some extra nice language features to JS. It really is a good productivity improvement, especially with JSX which enables HTML literals: pretty much essential when working with a complex React front-end in my opinion.

My team has been using it for most of this year now and we've had no problems so far.

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

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)

Have you tried add OAuth support to your web app?

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?

I'm not really sure what your point is. If OAuth integration is a requirement for your project then its your responsibility to test it across the platforms you intend to support and that's a universal truth no matter what development stack you're working with.

Dealing with sourcemaps absolutely causes extra trouble. Transpiler errors and bugs can also pop up at the worst times. Any time you add more steps to your compilation and deployment process, you're adding risk and potential trouble. That's just a fact of life. I'm not saying not to use es6 because I do and it's awesome, but I am not under the illusion that it's all sunshine and rainbows.

Care to elaborate?