We've been wrestling with this exact same question quite a bit since we recently started a project with a substantial javascript front end. My anecdotal observation has been that we have a lot more bugs in the javascript application than we had with previous applications that just used Snap and generated HTML with Heist. We haven't decided on anything yet, but here are some of the possible solutions we've been considering:
Thin Javascript Wrapper
These are pretty unsatisfying solutions to me. The improve slightly on Javascript, but don't come close to giving me the things that I get with Haskell.
Much more functional and type safe front-end language
- Fay is a proper subset of Haskell that compiles to Javascript. It definitely has some appeal, but doesn't give you access to all of Haskell. Last I heard it didn't support type classes, which I imagine would become an obstacle pretty quickly.
- Elm
- Roy
The problem with these solutions (as well as with the previous group) is that if your back end is written in Haskell, you still have the impedance mismatch because your front end language is not Haskell. This makes your code less DRY because you have to end up defining the same data structures in Haskell and the front end language. And when you change them in Haskell, you don't get errors indicating where your front end code needs changing. The app just breaks.
Compile Haskell to Javascript
The new game in town here is ghcjs. This is a very promising project, but I don't consider it to be viable for production at least until GHC 7.8 is released. That will hopefully happen within the next week. Once 7.8 is out the door, you still have to take into consideration that ghcjs is still very new. And even in the hypothetical scenario that it was 100% feature complete and the first release worked perfectly, you still have to remember that a fair amount of infrastructure has to be built before Haskell+ghcjs is as effective as high level javascript frameworks like Angular, Ember, etc.
UPDATE September 2016: Now, almost three years after I originally wrote this answer, GHCJS has improved greatly. There is still room for more improvements, but I have used it for production applications and it worked very well. It's especially powerful when combined with the Reflex FRP library that makes it much easier to build reactive UIs.
Generate Javascript from Haskell with an EDSL
If you have a relatively constrained problem, it might be possible to do all your application work on top of an EDSL that generates javascript. We already have the fantastic jmacro package to take care of the low level concerns of generating Javascript. You could leverage that and generate code that uses whatever other javascript libraries are appropriate for your application. That could be javascript + jquery, D3.js, or even code using a higher level javascript framework like Angular or Ember. I tend to think that Angular would be much easier to generate code for than Ember because of its simplicity and stronger encapsulation.
Greenfield a bytecode VM designed for functional languages in the browser
This is just a pie in the sky idea of mine. I don't think it's really practical because it would take a huge amount of work and be very difficult to gain adoption. But I like to at least mention the idea for completeness. Others have pointed out that asm.js is almost like this already. That may be the case, but it would be nice to have things like tailcall optimization designed into the VM level from the start.