So I wrote this paragraph (http://www.haskell.org/haskellwiki/The_JavaScript_Problem#Ot...) in 2012 in a reply to a reddit comment. Around that time the Haskell community was growing in its web dev circles, and we as a community were cultivating a sense that writing our web apps was not fun in 50% of the task, which was the front-end.
There were actually a bunch of alternative attacks.
* Using so-called widgets which are compiled by Haskell and contain very minimal pieces of JavaScript that the user of the library never sees. This is okay. But if you're developing something more complex, you start to wish you were back in Haskell.
* Some were also thinking, perhaps it's just the framework that makes this work awful, we just need to pick the right reactive-MVC kind of framework.
* Use HJscript, an EDSL of JavaScript embeded in Haskell. This is not bad, I used this in hpaste and it's still running today: https://github.com/chrisdone/lpaste/blob/master/src/Hpaste/V... However, you're still left with the semantics of JavaScript, it doesn't really improve upon it. Although, if you're interested in this approach, definitely checkout Sunroof https://github.com/ku-fpg/sunroof-compiler which is like a new and improved version which has continuations out of the box.
* Some thought maybe CoffeeScript was enough, but it quickly becomes obvious that the problem is nowhere near syntax-deep.
In the end, I think everyone pretty much agreed just using Haskell would be better. But there were no viable transpilers, so we were continuing with JavaScript feeling that things could be better.
After that I decided to start trying out the bitrotted crop of compilers. I tried GHCJS first, and reported my findings: http://chrisdone.com/posts/ghcjs The first couple paragraphs are now on the wiki. I thought this community "feeling" should be documented, and copying “The Expression Problem”, thought it would be catchy to make a “The JavaScript Problem” post that is concise, opinionated and comprehensive. Ask any random Haskeller and they will pretty much agree with both paragraphs. It's easy to point someone to a wiki article to have a common understanding of the problem.
I'm not one to simply whinge about things, however. I wrote down alternatives and tried a few out myself. I experimented with GHCJS (above) and UHC (here http://chrisdone.com/posts/uhc-javascript) and HJScript. Eventually, unsatisfied, I wrote the Fay compiler: https://github.com/faylang/fay/wiki which was inspired by the simplicity and small output of Roy and the FFI in UHC, and was a success (to some degree) because it was super easy to setup and its output was understandable. We're using Fay at FP Complete for the IDE, we have about 16k lines of code in Fay.
In parallel, the GHCJS codebase got a new set of very active maintainers, the Haste compiler appeared http://haste-lang.org/ and generally the community started to feel “hey, not only is compiling to JavaScript practical, but we're starting to feel this should become standard web dev in Haskell.” If you look at the crop of Haskell web frameworks (big three are Yesod, Snap, Happstack) they all support compiling via Fay and I'd expect haste, too.
I see some comments in this submission that the Haskell community is "snobbish" and "complaining". We're apparently among the people who “wish JavaScript was something else” and we shouldn't be one of those people, that we just don't really “get” JavaScript and how to write it properly. We want a car because we don't appreciate how to ride a horse properly. I'd say the opposite. Here we saw the problem (as we saw it), and started working on practical solutions and now people are getting paid to write Haskell that runs in the browser. If that's not putting money where your mouth is, I don't know what is.
Also look at the OCaml community with http://ocsigen.org/js_of_ocaml/ (also an inspiration for my endeavors) and the Clojure community with https://github.com/clojure/clojurescript They identified the same problem and got to work. :-)
Since I added that wiki article, a bunch of new compilers and languages have been added to the page (or invented). For the chorus of people asking "why isn't X listed?", it's simply because users contribute to the article, it was much smaller. So if you've heard of another approach, and, importantly, if you've tried it and can report practicality, please go ahead and add it. I think I'll add Opa to the list, it's like Ur in that you write front-end and backend code in the same language.