"I'm convinced one of them (or something similar) will be the future"
I don't think so.
Elm is too much in its own world.
Purescript is too Haskell for mainstream.
I had the impression that Reason/ReScript was on a good way, but the I think the renaming and split of ReScript from Reason confused people, and now nobody knows what's happening anymore. (Im still confused myself, haha)
Maybe Rust has a chance in the frontend world if it gets just a bit more ergonomic?
It's Typescript for the immediate future. It's where the resources are (Microsoft, etc), it's where the type definitions are for the libraries you want to use (don't underestimate this one!), and it's where the developers and jobs are. For a lot of people it's a big enough step up over JS (while still being very familiar) that it's more than good enough.
Elm, Purescript, and Reason will likely all remain niche, or die off. Some developers will springboard from Typescript into these languages (but probably not Elm, sadly I think it's doomed, and not for being a bad language) but most people will I think be fairly content.
Perhaps something will come out of leftfield, but I can't see something like Rust-with-better-ergonomics taking that much mindshare from Typescript. A JS dev can start with Typescript today, in their existing codebase, and be productive either immediately, or within a few days. It's pretty hard to beat that, though I'm sure there will be niches for the various other compile-to-JS or compile-to-WASM options.
I think as someone who has evaluated functional Typescript, ReasonML, and purescript, I can say that ReasonML provides the best developer experience (interop with the JS/TS ecosystem) while providing the next generation of type safety and composability for backend development. Unfortunately the ReScript branding is probably going to be a lot more confusion (more-so than the dual bucklescript/reasonml branding). To make it even more confusing, ReasonML technically isn't dead (only Reasonml.org is) and is now a third syntax (in addition to rescript and ocaml).
Also I don't know why these languages aren't being promoted more for backend development as it's a perfect fit for the paradigms espoused in https://pragprog.com/titles/swdddf/domain-modeling-made-func.... I would say Ocaml/ReasonML is even more ergonomic than F# (polymorphic variants are great for composable error handling).
Even in the current state, ReasonML can be used to progressively enhance a JS or even typescript codebase with no need to fully buy into a rewrite or even heavy toolchain modifications.
> To make it even more confusing, ReasonML technically isn't dead (only Reasonml.org is) and is now a third syntax (in addition to rescript and ocaml).
It is?! I thought I was following the changes there - clearly I was mistaken
Hell I was confused by bucklescript vs reason before. This sort of thing just puts me off. One thing Elm got right is just to have one way not to fragment.
I'm really confused by what Rust has to offer to frontend. A systems language, sure. Memory safety when no garbage collection, fine. But we do have a garbage collector in the browser. And are expecting to get it for webassembly too. And when I compare Rust code to typescript, I want to howl in agony and ask, why would we inflict on ourselves this punishment. At least I can see the elegance and the beauty of Purescript, although I can't write anything useful in it. But Rust is just so horrendous for frontend, where the existing languages are so much nicer!
I don't think so.
Elm is too much in its own world.
Purescript is too Haskell for mainstream.
I had the impression that Reason/ReScript was on a good way, but the I think the renaming and split of ReScript from Reason confused people, and now nobody knows what's happening anymore. (Im still confused myself, haha)
Maybe Rust has a chance in the frontend world if it gets just a bit more ergonomic?