It's an improvement - but at this point ES6 is just another compile-to-JS language that needs to ship it's own standard library - except it's worse than all of the mentioned ones (it has no type checking, standard library is still meh, semantics are still good old JS semantics).
Same here; I guess it really depends on who your target market is. So far, all the ES6 I've written works just fine in Chrome, Firefox, Safari, Opera, and Edge. The only browser that breaks everything is Internet Explorer, but it seems like general consensus these days is that IE is only used in enterprise applications where you're locked into it.
I think ES6 is just in its in-between phase of adoption. The mainstream hasn't fully adopted it yet. As for the rest...
The Coffeescript converts have moved on from the 'one true language' now that ES6 cherry-picked most of the good parts and people started realizing that CS source maps are buggy/inconsistent.
Standards are for 'plebs' so they've moved on to the new shiney. By new shiney, I mean mimicing FP in Javascript and looking down on people who can't ELI5 monads and functors. Despite not being able to ELI5 monads and functors.
Typescript, is really geared toward OOP devs who live in an IDE and compulsively twitch an invisible set of CTRL-SPACE keys when they get nervous.
It's a well-known fact that Google is a OOP- heavy Java/C++ shop who have been developing algos in Java/C++ since their last CS course where they developed algos using Java/C++.
It's within their best interest to get all of there desktop devs to convert to writing desktop apps on the web before all that penis pills/local singles ad money runs out.
It's only a matter of time before we see the first JS AbstractFactoryFactoryServiceProvider class in the wild. Angular2 has made considerable progress on this front so far.
/satire
Honestly, I really enjoy ES6. The JS dev communities favorite past time is ragging on how ridiculously bad JS is. ES6 isn't bad so it's not worth talking about.
The new features introduced in ES6 are pretty conservative. They consist of good concepts poached directly from popular superset languages or sensible additions that fit in nicely with the usual JS style.
The really interesting additions are still in the specification phase. Additions, such as the new ES6 module and loader standard, decorators, native HTTP fetch, etc...
As long as new standards are being introduced, transpiling will continue to be a requirement. I think it's cool that people can create and use new supersets of JS. It beats having to listen to them whine about how 'Javascript isn't exactly like some other language that I really like to use.'
In a way it's the first democratic programming language. Instead of dictating what people should and shouldn't use, people are free to migrate around to different communities until they find one that more closely matches their worldview. Everybody follows the same baseline standard but there's a lot of legroom for differentiation.
Why axegrind over our differences when we can celebrate them and start working together.
Fair 'nuff. I probably fall into the "mimic FP" section above, as I REALLY like functional abstractions. Although I don't do much pure FP. And I don't look down on anybody who can't ELI5 monads and functors. Monads and functors are confusing.
It's all good. My comment was more of a friendly jab than a direct criticism. I agree that FP concepts are amazing.
I just don't see the utility in trying to translate pure FP concepts directly to JS. Same goes for the Typescript folks with OOP abstractions and design patterns. It's like watching a pissed off New Yorker rant about how the pizza shops in LA suck. Live a little and try a California burrito. It might change your life.
The point being, neither approach has provides measurable benefit to runtime performance/stability. They're nothing but really complicated abstractions whose sole intent is to protect devs from themselves. Why don't we build better tools to assist devs instead of inventing yet-another-feature-specific-language?
I think FP abstractions translated to JS could work as amazingly useful design patterns. Hopefully, decorators will make it a lot less painful to define higher order functions in JS.
Likewise, static type alike languages are very useful as a bridge to traditional OOP devs. I think gradual typing is a better long term approach.
...Don't you mean arrow functions? Decorators don't seem like they'd help with that.
And yeah, I don't think that monads are that useful JS. And OO is different in JS. Deal with it.
Also, if you use Strategy, Iterator, or Visitor patterns in JS by writing classes for said things, you deserve to be punched in the face really hard. Repeatedly.