This is interesting. Today, when people say ES6, I feel like they actually mean esnext, as once you accept a transpile step from TypeScript or Babel, you might as well get the benefits of new language features in your codebase. I wonder how many people mean es2018 when they say es6, complete with some pretty dramatic code style shifts, including a tendency towards classes, async/await, and composition-first nameless but concise arrow functions.
There are some coding styles that are popular in esnext that just aren’t practical in es5 because they would be too verbose and not “read” very well.
Relatedly, I'm increasingly surprised how many people still think they need a transpiler for ES2015-ES2018. Browser adoption for them has been much faster than the once problematic ES3 to ES5 upgrade.
Especially for those that use the common suggestion for Babel of "last 2 versions of major browsers" presets, the amount of transpiled code has gotten extremely small, and increasingly so.
«There are some coding styles that are popular in esnext that just aren’t practical in es5 because they would be too verbose and not “read” very well.»
I like to check my code after downleveling in Typescript to ES5 from time to time. There isn't anything in ES2015-ES2018 that downlevels to "unreadable" in Typescript. The "worst" you get is async/await transpiles to ES2015 generators of promises (function*) which then transpiles to ES5 switch/case state machines, but even with all of that downlevel work I think you'd be surprised at how readable it stays.
