Elm VS reflex

I get it. However, the whole point of using Unions to narrow your types, ensure only a set of possible scenarios can occur, and only access data of a particular union when it’s safe to do so. That’s some of what pattern matching can provide, and 100% of what using switch statements in TypeScript with their Discriminated Unions can provide. Yes, it’s not 100% exhaustive, but TypeScript is not soundly typed, and even Elm which is still has the same issue TypeScript does: You’re running in JavaScript where anything is possible. So it’s good enough to build with and much better than what you had.

The beauty of a language like Elm (and other lambda-calculus / functional programming inspired languages) is that there's very little transformation involved in going from an idea to code. And that seems to have a big impact on getting things done.

I think the most fun and approachable way for beginners to build games with functional programming is with Elm [1].

See a few (small, demo) games built by the community in [2] .

Notice Elm has abandoned the FRP approach in favor of Model-View-Update [3].

[1] https://elm-lang.org/

Also check out some "compiled to JS" langs like https://elm-lang.org/.

Elm has an impressive take on how to model front-end apps and claims to avoid a whole category of issues.

For one, it's been over 2 years without an elm release. And there are many open bugs untracked in GitHub. https://github.com/elm/compiler/issues

Unrelated to your question but for those curious, here's a comparison between Gren and Elm :

https://gren-lang.org/book/faq.html#what-are-the-differences...

Not to be confused with Reflex, allowing web apps in pure Haskell: https://reflex-frp.org/

FRP solutions sound very attractive. But reflex seems to be stuck on the outdated GHCJS, and I haven't been able to get it to build. The newer JS output in GHC doesn't yet have DOM support. And even if I used one of those, figuring out how to interact with a LaTeX renderer might be tricky.

I only have experience using Reflex, which I regard as the main contender for FRP UI libraries in the Haskell sphere. It's got a flashy website, but I think the documentation is a bit disorganized -- it took a long time for me to figure out how to get going with the library (you find some pieces of knowledge scattered here and there, if you look hard enough). My plan was to learn it well enough to onboard other people, but I don't think I could convince anyone who hasn't already decided that they're gonna make UIs in Haskell no matter the required effort.

Once someone has spent a bunch of time with Haskell and sees the value, they will find Nix if it makes sense. Maybe they'll want to play with https://reflex-frp.org, or they'll discover they want a better way to package 3rd-party dependencies, or they start using NixOS and want to nix all the things, etc. etc. Or, maybe they'll never find a use for it, and that's okay.

Now, I've been convinced to take another look at reflex. This quick reference seems very useful, most other resources seem to always discuss reflex-dom specifically. I'm not really interested in that.

Have a look at https://reflex-frp.org/, or https://owickstrom.github.io/gi-gtk-declarative/, they are an interesting and different way of working with UI in a non imperative way.

At present, here at Typeable we develop frontend in Haskell and use the web framework Reflex and the functional reactive programming (FRP). The source code in Haskell is transpiled into the JavaScript code using GHCJS.

Reflex is the framework that allows creating reactive web applications in Haskell.

Also you’re the Haskell guy no? Found this while reading a Wikipedia article