For kicks I tried the online Elm demo. Offhand it doesn't seem like Elm highlights errors inline(?). The syntax also looks a little foreign, whereas TS generally still looks like JS with a few exceptions.

I imagine Elm/Flow both have this, but another thing I like that TS does in VSCode at least with a watching task is collecting errors project-wide in a "problems" window.

- 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.

In my experience whenever I worked on a JS project on my own, there was an upper limit to how far I could keep writing the code on my own. After that, I had to spend time in doing other things (like writing Integration tests, lots and lots of unit tests, or refactor existing code because I realized that there are many issues unveiled).

But now, with Elm, it's like a whole set of unit tests are being written at the time of writing code which take care of plenty of common errors usually made due to lack of a good type system.

Add to that the usage of Maybe types (which are very beneficial in avoiding some UI antipatterns[1]), and the Reactive Programming pattern, I feel like I am writing a lot less code than what I am used to writing in JS projects.

I highly recommend Elm to anyone who wants to write a personal project, you'd see what benefits I'm talking about.

1. http://blog.jenkster.com/2016/06/how-elm-slays-a-ui-antipatt...