I love Gleam! I also really love its JS target and I even shipped a small one-off piece of UI for a client in Gleam. I’ve also contributed a bit (mostly docs) to Gleam’s Elm-inspired frontend framework Lustre.
For my startup I picked Elixir over Gleam on the backend mostly because the ecosystem was quite a bit more mature, and I’ve really come to appreciate its meta-programming model. It enables great things like Phoenix, LiveView, and Ash, which let us get to V1 very quickly. It’s not Hindlay-Milner but you get a lot of guarantees by making assertions about the shape of the data in Elixir. Ash uses metaprogramming to provide a lot of guarantees. They’re also working on a “set-theoretic” type system which I’m very intrigued by.
I am picking ReScript over Gleam for new frontend work, both because it’s more mature and because it has much better interop with the broader JS ecosystem, especially React. Especially, especially React.
Lustre is really good for building self-contained apps. But the specific feature I’m looking to build needs to listen to DOM events from outside the app. There are no community bindings for those DOM apis at present in Gleam (MutationObserver, IntersectionObserver…). So I felt like I’d be wading into extremely uncharted territory. The creator of Lustre actually straight up told me Gleam was probably not ideal for this use case.
It also blew my mind when I realized I could just do useReducer and basically turn ReScript into Elm. I was wondering why the ReScript-TEA libraries all seemed unmaintained until I saw that.
I feel very confident that as our app grows and grows, ReScript will be able to handle any situation we run into. As of now I can’t say the same for Gleam because its JS ecosystem is still quite small and lacks a lot of interop.