concur-static VS miso

There were some problems with the underlying Concur abstraction in concur-replica, but I have a local branch that I think fixes them. That said, I definitely don’t recommend concur-replica for production. Still, Concur is pretty unique in the UI space, so I definitely recommend at least trying out any one of the implementations. There’s also https://github.com/pkamenarsky/concur-static, which is an attempt at semi-dynamic UIs by exploring all possible state transitions and generating a static JS file that encodes all of them.

Patching jsaddle by applying this commit made JSaddle usable in Firefox for me, but it has the downside that preventDefault/stopPropagation no longer work (see this issue for more info).

Miso does support jsaddle, docs mention this under the "Live reload with jsaddle" section, although it could be more prominent.

For those interested in DOM-related benchmarks using GHCJS. Miso has some benchmarks here: https://krausest.github.io/js-framework-benchmark/current.html (Ctrl+F `miso`)

ghcjs is the way to go for you, and soon it might be asterius. i do not know how hard it is to set ghcjs up without a framework. but frameworks like obelisk (based on reflex-dom), shpadoinkle, and miso automate that for. i personally like obelisk for its functional reactive programming but it can get awkward and get in your way. so if gui programming is just a means to the end of this one small application and you are not really interested in it nor functional reactive programming, shpadoinkle or miso might suit you better. miso implements the elm architecture (also "TEA", "functional model view controller") and shpadoinkle implements something directly equivalent to the elm architecture. but shpadoinkle achieves more composable widgets by minimalizing the elm architecture. so i recommend shpadoinkle for its better concept although miso is more mature.