That is a good summary of the options for Haskell web development. The author of this slide deck also wrote "Beginning Haskell." I bought this book and like it. That said I have an addiction to buying Haskell books :-) Personally, I use Yesod for complicated apps, otherwise Spock.
I'll also chime in and say the same. I've been meaning to go back and complete the exercises I couldn't at first.
I almost got stuck not reading on because I couldn't figure out how to do some exercises but I'm glad I didn't because hindsight shows me that would have been a mistake.
Based on your recommendations, just now, I went to go check out the book and found they're having a one-day half-price sale on it at Apress, the publishers:
I'm somewhat new to web dev and new to functional programming. Can someone tell me how this is fundamentally different that ClojureScript + OM (https://github.com/omcljs/om) ?
ClojureScript also, I think, has a better front-end story for squishier front ends at the moment (although there are a number of projects working on changing that).
It looks like a good start. I've been trying to learn Haskell and F Sharp and other functional languages and always wondered if there was a web option.
(Author here) There is a set of exercises that come with the slides at https://github.com/serras/lambdaconf-2015-web In particular, they introduce the Aeson library for both producing and consuming JSON.
I believe the HTML templating stuff is pretty optional in all the major Haskell web platforms. I know in Yesod it is trivial to serve JSON rather than HTML from an end-point, and pretty easy to serve multiple representations of the same resource.
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.
