Don't forget about reflex[0], you can try it here[1].
I also use purescript[2] with purescript-halogen[3] as does slamdata[4]. There's also a video on Purescript halogen[5] that's very interesting.
Purescript is great because the JavaScript it generates is so readable, that if you really need to you can understand the output and make micro-optimizations.
Thanks for the links! I'm really curious about what Haskell can come up with for a front-end story.
Do you think that Purescript's row typing (as seen in records and the Eff monad/effect system) is a viable replacement for monad transformer stacks? I "get" MT stacks but I find them heavyweight when what is most often desired is commutative set building of capabilities rather than MT-style stacking.
Monad transformers and PureScript's row-based effects are two complementary approaches to the problem of extensible effects.
Some effects in PureScript look a lot like the effects provided by certain monad transformers (StateT/ST/Ref, ExceptT/Exception, etc.), but there are differences in terms of how things compose. Take StateT and ExceptT for example: you can compose them in two ways, and get two different monad transformer stacks, with different behaviors (surrounding how state propagates when an exception occurs). There are valid use cases for each, but with the ST and Exception effects, there is only one way to combine them: the way the underlying (Javascript) runtimes chooses for us.
There are things which each one can do which the other cannot. Fortunately, we can mix and match in PureScript since we have the purescript-transformers library. A typical arrangement is to stick Eff on the bottom of a monad transformer stack.
_Edit_: of course, everything you can do with a monad transformer can be done more verbosely with pure functions and the underlying monad, so you _could_ replace monad transformers with Eff in many cases, but in practical terms, it might not be all that useable in some cases.
Consider mtl then. It provides commutative capability set building semantics from the user's POV and then only asks the consumer to make final stack-ordering/effect specification decisions.
I find mtl pretty close to a sweet spot. The one thing I wish for is to be able to constrain effect order as a user (using your terminology above) when I'm writing code where one ordering or another is incorrect. The closest I can come is to fix the top of the stack, which suffices for correctness but puts some unnecessary burden on the consumer.
My solution is to make a new typeclass which implies the order you demand. It'll all be social contract driven, but until we have dependent types one cannot ask for more.
There are a number of Haskell-to-JS compilers and Haskell-alike languages which more directly target JS. This is growing quickly but major issues remain and the toolkits are quite immature.
On the other hand, much of React is a natural play out of Haskell's sweet spot. The challenge will be in making Js-alike APIs which handle the flexibility well while maintaining sufficient typing. React-like rendering, virtualdom, data flow... this will all be incredibly naturao.
I find it pleasant every time I get something working in it... but significantly far away from anything I'd like to support in production. At least for now.