I'm curious about this as well so I did some searching.
Fay[1], a subset of Haskell that compiles to JavaScript, seems to be the primary choice. There are DOM and jquery bindings for it and this blog post[2] looks like a great introduction.
There are other options, this [3] article outlines a number of them as a greater overview of both server and client side programming with Haskell. I also found an intriguing article [4] on the Haskell site but it appears to be out of date, referencing libraries that are no longer in development.
I've played with Elm for a toy project before and I do have high hopes for it. I also think it's the greatest monad tutorial ever - you don't truly miss them until they're gone.
(To clarify: At the time that I last used Elm, the Signal type was a functor, but was intentionally being kept from being a monad for design reasons. Working around this restriction tought me a lot on why I needed monads.
I didn't really understand applicative functors until I was playing with Elm. Working with Signals was pretty fun, and when I found out they were applicative functors, it was like a light bulb going off above my head.
Elm is a really fun way to start exploring purely functional programming.
I assure you that it's not a trick question, just a poorly worded one.
Imagine that I'm making a page that converts meters to millimeters. The obvious part of the haskell code is
convert :: Double -> Double
convert = 1000 *
The part which isn't obvious to me is how I get input from the user or display the result. I know how to do that in the IO monad through standard haskell, but I wouldn't know how to handle it in Haskell compile to javascript for the web browser. I would have thought that you would need a binding to the DOM to read from forms and the like.
I think fay uses its own FFI, but with haste you just use the normal FFI to call normal javascript functions the same way you would interface with C code from haskell. There's no need for special bindings or anything. You could certainly make a wrapper for jquery if you were crazy (and I'm sure someone has already done so), but this idea that you need some special DOM library to do things that javascript already does out of the box is kinda odd.
Thanks for the clarification. The key part that I was missing was the FFI. I'd encountered projects like this in the past with either no FFI or no documentation for the FFI and I couldn't figure out how to talk to the DOM. I'm more than happy to drop down to javascript for those parts, but I wasn't sure that I'd have the option.