Elm is very different from typescript and is generally a much more involved choice than just "let's make our usual JS strongly typed". - You need to like Elm t

Elm is very different from typescript and is generally a much more involved choice than just "let's make our usual JS strongly typed". - You need to like Elm the language (it's pretty good, but limited, not expressive) - You need to like purity. Time.now or Math.random returns an asynchronous Task. I know why it's done like that, I just don't agree with the tradeoff. - You need to like Elm the ecosystem or be prepared to write lots of awkward JS glue code - You need to like Elm, the architecture (it's simple, but has tons of boilerplate and limitations) - You need to accept Elm, the roadmap made by a benevolent dictator. The progress is slow. Compared to a good typescript codebase, you will get like +5/10% type safety. Typescript is way more flexible, but that also mean you will have to rely a bit more on human code reviews, etc rather than the Elm compiler just telling you "no, there is only one way to do this". On the other hand, you have just typescript on one side, Elm + javascript/typescript if you want to achieve anything serious on the other :) Go with Elm if you like being in a very, very controlled environment (frameworky) and you're afraid to make mistakes. Go with typescript if you're a hacker who like to mix and match architectures, libs, etc and accepts things change fast in the frontend orld right now.