All of these compile-to-JS efforts are great, and as much as I love things like CoffeeScript I have to say I definitely worry about language fragmentation.
In today's fast-paced development environment, the ability to hit the ground running is key, and I worry that fragmentation will introduce unnecessary friction in the industry.
Equality (and that portion of type coercion) is pretty much solved by using === and the rest of type coercion is solved by only using + when both sides are numbers or strings. I don't see how that gets as much ire as it does
Depending on who you are you can also complain about scoping rules, the object model, semicolon insertion and more general syntactic complaints, speed, access to native APIs and so on. One language is never going to be all things to all people.
I think it means the language forces designs and eventually an ecosystem that's optimized around having cooperative multitasking as the only option. That makes dealing with concurrency an easier task since every library you depend on also takes concurrency seriously. And since cooperative multitasking is much much more efficient than preemptive alternatives, you end up with applications with great efficient concurrency support by default.
E.g. node.js + socket.io. The event-driven concurrency model makes it easier to write servers without worrying about race conditions and thread locks while also having less overhead from a heavy thread implementation. For some applications this has been quite good. The downside is that it can be a bit tricky to scale node.js larger but it's not too hard to run multiple processes or do other load balancing. It's not good for all applications, but very good for some.
> The event-driven concurrency model makes it easier to write servers without worrying about race conditions and thread locks
Well, no, you're just writing the locks yourself in an ad-hoc way. Every time you have a callback calling another callback, you have a lock and all the race condition/deadlock issues associated with that. Of course, writing an application that doesn't have complicated synchronization requirements (streaming fileserver) can often require less boilerplate in an evented system. However, you run into a catch-22 here: by definition it's an application with fewer synchronization requirements, so you'd have to use fewer complicated locks in a 'heavy thread' implementation as well :).
Ultimately it's an engineering tradeoff problem, and you have to weigh lightweight node-style cooperative multitasking with the ability of a traditional thread system to better handle highly complicated scenarios.
Or you can be Russ Cox and argue that this is a false dichotomy and that we should all be using CSP. I'm in that camp.
> makes it easier to write servers without worrying about race conditions
So how do you handle concurrency without race conditions without using isolated processes or pure message passing? Ok so you don't have thread locks, big deal, but you still have shared data structured that could be updated in a non-deterministic order depending on which file descriptor gets fired first by epoll (or whatever select thingy is being used lately).
> In today's fast-paced development environment, the ability to hit the ground running is key
actually, i think one of the major flaws in the current programming job market is overrating the ability to hit the ground running. that leads to a dangerous level of short-term optimisation, where, say, you'd choose an employee who has experience with your current stack over someone with a better track record but requiring a month or so to learn their way around the specific languages and ecosystems involved.
This same fear of fragmentation is what kept Java from progressing for so many years and look what happened there. Things 'fragmented' by people just switching to other languages. I say roll the dice and see what happens.
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.
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.
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's also compounded because the majority of front-end developers write their code procedurally for each application component, which creates a terrible nest of repetitive and error-prone code.
They feel the pain, don't know how to solve it, so switch to a different syntax, blaming that as the root cause of the problem.
But feeling enough pain to viscerally HATE a language, as many front-end developers do, is not something that can simply come from the syntax of the language and the fact that the equality operator does type conversion and whatever small list of gripes users have. Most other languages (including CoffeeScript!) have a similarly-sized set of flaws and aren't nearly as derided.
Overall, cross browser js isn't really that difficult anymore and I rarely see people complaining about that. Of course, I've been part of the AltJS community for a while, and the people I follow closely are not front end developers.
Of these developers, how many of them have any real experience with languages like C++, Java, C#, Scheme, Haskell and Erlang?