JavaScript is forever stuck in design-by-committee hell, which dooms it long-term. Developers who do nothing but pure JavaScript and don't at least play around with the other options (Dart, TypeScript, Haxe, CoffeeScript, et al) are just going to be hurting themselves long-term.
It is always a bad idea to tie yourself too strongly to any single language.
Conversely it's a bad idea to spread yourself thin in multiple languages but master of none.
Having said that, I'm pretty much tied to Java since 2000 and haven't seen anything wrong... yet. In fact, I'm determined to get better in Java everyday (memory model, JVM, concurrency, better design, etc).
Side note: I'm also learning pure "modern" JS just because there's no choice on the client-side.
Actually, it's quite easy to write for the client in most languages targetting javascript. Certainly it's the case for CoffeeScript, and TypeScript looks even better in that regard since it's a strict superset.
I've done GWT for about 2.5 years from version 1.x to 2.x. I'm not sure I prefer one or the other.
GWT development is a bit painful to setup and to work day-to-day.
It's nice to have the similar Java structure and to be able to write unit-tests to test the app via MVP patterns but I'm still not sure it's a big win for me going forward. Especially when the founding members have left the team.
ECMAScript 4 looked a lot like ActionScript 3 up until the whole thing was suddenly killed. I don't care too much what a language is supposed to look like years from now if everything goes right. This goes double for languages with a tortured history of failure when it comes to big changes.
First, Firefox and Chrome (under a flag, to be removed) already ship great pieces of ES6. JSC (Safari) and IE prototypes coming too. This is necessary to test interop and design soundness.
Second, we don't do "Design by Committee", we use the "Champions" model where 1 or 2 people design a proposal and a larger number beat it into consensus shape without "redesign".
Nothing's perfect, least of all with multi-browser standards, but if you have an alternative for evolving the actual JS language implemented by browsers, lay it on us.
Compilers on top are great, and many. Good to see MS do one that tries to build on ES6.
Wow. Didn't expect a reply from "THE Eich" itself. Honoured.
>Nope, spec finalization follows shipping.
Still, shipping ES6 is also scaled back at this time, and it requires special flags and hoops to be enabled.
This means actual mainstream use (the way we know use HTML5, IE7 be damned) will be possible 2-3 years in the future at the minimum, which would be like 6-7 years from the beginning of the whole process.
This is W3C-level waiting times, especially considering that ES now is essentially the same it was in 1999, with minimal changes to the language or the standard libs.
>Nothing's perfect, least of all with multi-browser standards, but if you have an alternative for evolving the actual JS language implemented by browsers, lay it on us.
I would wish for a "one guy sets them all straight, it's his way or the highway" benevolent dictator model, but I understand that while it works for Ruby or Scala or whatever, it doesn't work in JS case where you _have_ to have 4 different implementation by 4 browser vendors to have it adopted.
I think what those vendors need is something to force their hand, but don't know what that could be.
Device turnover on mobile is 2-3 years. Things are picking up with more balanced competition and the rise of mobile to dwarf desktop.
You can't get an interoperable spec of a new edition of a language the size of JS in less than three years, for any such language. Not for Dart (which is still changing and by Google's own plans nowhere near ready to standardize) or TypeScript (also new, and tracking ES6). Java, C#, Python, Ruby, etc. were built to today's state over years or decades.
Bite-sized specs are much better. Small libraries on github and universal edge-caching, even better. Could we have bite-sized specs for JS?
As I speculated at Strange Loop last week, with a few final gaps in the language filled (Object.observe, slated for ES7, weak refs and event loops, and definitely macros! see http://sweetjs.org/) by a future JS standard, we will be "all but done".
It is always a bad idea to tie yourself too strongly to any single language.