start-app

nded Elm architecture, I couldn't use the debugger. But even some core APIs like Window.dimensions burned me more than once, with things like: https://github.com/evancz/start-app/pull/37 I've started porting the app to Purescript. I used the Purescript book, which is excellent: https://leanpub.com/purescript/read I'm especially happily with Purescript's FFI, and its generally pragmatic attitude. However, Purescript doesn't come with a "blessed" UI library, so you have to pick. I briefly tried the ambitious Halogen library, but the sheer type-system complexity ground me down quickly. I eventually went with the Thermite library, which is a very thin library wrapper of React (< 300 lines of code). So far, Thermite has been very nice, and quite easy to use, though it could use some enhancements and tweaks. Overall, I like Purescript a lot. My basic problem with Elm is that it tries to be very opinionated, with very few escape hatches, so when I got stuck, I tended to get stuck very hard. Whereas with Purescript, it's much easier to drop down to JavaScript, but also to "pop up" and pull a well-known abstraction out of the standard Haskell toolbox if I need one.

hes everywhere to destructure ADTs, and the fact that you can't define guard expressions (or destructure things nested inside record types), it tends to result in a lot of extra typing. 3. The Elm tooling is a mixed bag. The error message are the best I've ever seen, but the sweet time-travelling debugger just refused to run when I tried to use it with the Elm architecture tutorials. This pattern of brilliance and brokenness feels fairly pervasive at this point. 4. The Elm community can occasionally be a bit frustrating to work with as an outsider. Sometimes, when I run into an issue, I eventually find a GitHub discussion like this: https://github.com/evancz/start-app/pull/37 , where somebody is trying to address an actual issue (one that was biting me, too), and the community is more-or-less throwing up its hands. Also, the Elm community has an occasionally surprising tendency to close GitHub issues quickly, even if it's known that they'll probably need to fix something someday: https://github.com/evancz/start-app/issues/35#issuecomment-1... 5. For me, Elm feels considerably more restrictive than programming in Haskell. 6. Elm's type checker and design do have one huge payoff: Even very complicated apps with lots of tricky asynchronous state tend to work on the first run after they make it past the type checker. This is hugely valuable, and it makes me more inclined to forgive Elm's limitations elsewhere. Overall, Elm is exploring some really important ideas, and it's pushing the general React-style architecture to its logical limits. I think I'd consider it for small- to medium-sized apps with lots of tricky state, and with developers who are strong at functional programming.