Typescript is a completely different language advocating different paradigms so they are not comparable.
However I have to agree with you that the lack of support for local time is pretty unfortunate.
I've used both heavily. I think paradigm is the key word if you're thinking mind-expanding properties. While immutable types and combinators are less used in Typescript (you've got me there) you can certainly get 80% of the value of strong typing, and there are several variants of Virtual DOM support.
Elm's error messages and semantic versioning are still a class above anything else, though. Sad to see it rotting on the vine like this.
Re:Why Elm? [pdf]
by StreamBright on Tuesday May 09, 2017 @03:40AM
(#14298364)
In this thread Elm was compared to OCaml and Haskell, comaparing it to Typescript is really not that bad. :)
The roadmap priorities always baffled me too.
I mean, what elm needs now to be usable is surely not code splitting... Almost no one really need that, it's a late optimisation for top sites.
It makes sense if their strategy is to try to get at least one of said "top sites" to adopt them—which might, after all, result in development being sponsored or supported by full-time employees of whichever bigcorp runs the site.
They already have that. Evan literally gets paid a Bay Area salary to work on Elm.
In that case—if at least one bigcorp is using Elm (which one?)—then their roadmap is probably being heavily steered by the needs of said bigcorp.
https://github.com/elm-lang/core/pull/739
Basically, if you have to deal with local time, this isn't the language for you. If you expect to be able to add to the platform where you find it lacking, this isn't the language for you.
At this point, Typescript has the momentum to make it irrelevant