I’m working in team that does back office apps for my company. We tried Elm and wrote few apps but now we advice against using it.
It boils down to the fact that Elm is a middle ground between typescript and advanced functional language and we don’t get much benefit from this.
On the one hand it is really difficult to create composable and reusable library of widgets. Anything interactive leads to a lot of boilerplate and weird patterns. And to be honest, Typescript type system is enough for widget library. We still don’t get runtime errors. Reported errors are mostly about rendering and here Elm also does not help.
On the other hand, Elm type system is limited and we can’t express our domain through it. Our apps deal with complex information and we’d like to have more tools at our disposal than records and tagged sums. We’d like to enforce laws and relations between data, even if we need to pay with steeper learning curve.
Few months ago, when we decided that pure Elm is not a viable solution (due to it’s focus on purity and lack of FFI, which we understand) we decided to test three approaches:
- Elm + WebComponents
- Reason for logic and React-Typescript components through genType
- Reason with ReasonReact for components
We ruled out first variant, because it brings us very little. If we start using a lot of web components we’re losing Elm guarantees. WebComponents are transparent for Elm and “string typed”.
But we also have team focused on marketing pages and they are very pleased with Elm + WebComponents approach. Domain logic is not very complicated there and shelf time is shorter.