[kyllo]

Picking any compile-to-JS language (not counting ES6/7) is a risky proposition though. There are a lot of people regretting their five year-old "legacy" coffeescript applications today. GHCJS is improving at an astonishing rate, but at this point I still wouldn't use any compile-to-JS language for a serious production application. There's too high of a risk of building something that becomes unreasonably expensive to maintain in a few years.

[chadaustin]

While I use ghcjs for one of my projects, have been a big user of Emscripten in the past, and recently switched from a CoffeeScript project to a TypeScript project at work, I understand what you're saying, but I think it's an overstatement.

Compiling to JavaScript is totally okay if the new language 1) adds something meaningful (like a type system [TypeScript, js_of_ocaml] or the ability to conveniently deal with unboxed data [LLJS, Emscripten]) and 2) does not have a significant runtime overhead. GHCJS, in particular, adds a _huge_ amount of runtime overhead, largely because JavaScript doesn't (yet) support tail calls so the CPS transform must be trampolined. In addition, laziness doesn't make a lot of sense for frontend code, which generally should be as tight as possible. Also, look at the code produced by ScalaJS sometime and weep. :D

js_of_ocaml, on the other hand, produces extremely tight code, and is very suitable for building web frontends. Of course, OCaml probably has a similar learning curve as Haskell. I can't imagine people would get excited about the syntax.

TypeScript is a sweet spot: it's got some value over straight up ES6, but it's easy to integrate and has a very short learning curve.

[15155]

> largely because JavaScript doesn't (yet) support tail calls so the CPS transform must be trampolined

I wonder if any research has been done here as to "let the stack grow" and THEN trampoline before it overflows.