Honestly, it's nothing alike. Refactoring in Elm is different, as the compiler will tell you if you did the correct thing when refactoring. The typescript compiler can only do a fraction of that, even if you type your stuff correctly.

Needing to type stuff in elm is mostly optional too. The compiler will still check it for you anyway.

I suspect not. With Typescript even with strict typing, mutating state is still possible (I believe, correct me if I'm wrong..). This adds an extra layer of complexity to the refactoring process.

With Elm, mutation is impossible - everything goes through the update loop. There are no escape hatches. This does mean you have to jump through a number of hoops to use FFI. It can be a pain at times, but does make for much easier refactoring.

> This does mean you have to jump through a number of hoops to use FFI.

TBH, I thought the pain of FFI in ports (the only mechanism available in Elm 0.19) was kinda overblown. Function input goes into a command, function output comes back as a message. That's just a few extra lines of standard code.

I think they become annoying if you do lots of small, synchronous, safe calls, like using a JS math library. In that case I suspect I would prefer writing a larger JS function instead of having an Elm function full of JS calls, even if I could use a more permissive unsafe FFI, because every JS invocation is still a chance at runtime errors due to type conversions (even with ports).