------------------
Elm
------------------

[Pros]

- Good language design (immutable, based on haskell+OCaml, nice type unions/pattern matching, everything is an expression, etc)
Most people who write Elm are seduced by its elegance.

- Very, very typesafe. If it compiles, 99.5% of chances that you won't get runtime errors (baring a few bugs) handy when you're tired.

- It was made for beginners, it's easy to pick up, the tooling is simple, the compiler errors are easy to read.

- The "Elm architecture" provides a way to build simple SPAs, out of the box, without having to use 10 libraries like some people do in the JS world.

[Cons]

- The community is tiny

- Elm is... by far the most opinionated environment I've ever seen. More so than RoR/Ember.
Elm the language and Elm the framework have no clean escape hatches.
It provides guidance for newbies, but when you encounters problems, it stings.

- The Elm framework is entangled with the Elm language. One person pretty much maintains both; developments go at a very slow pace and potential contributors don't feel overly welcomed.

- Elm's type system is extremely simplistic. You won't be able to express many things with it, and your code will have a LOT of boilerplate.

- if you're a front end developer with a sharp attention to details, it's a pain to build complex things with it, especially SPAs who have a lot of state. You need hacks all the time as the language + the framework are fairly under powered and it gets new features once every blue moon. There are many things that are impossible to do in pure Elm, so you have to write javascript anyway. The official way is to use ports, but many teams seem to rely on the frown upon Native modules, which are written in awkward JS.

- Talking to Javascript (foreign interface) is a bit of pain (less so now than in the past though!) and so is reading/writing JSON, compared to typescript.

--------------
Typescript
--------------

[Pros]

- Extremely productive, you're never stuck with a problem

- There is an entire team of professional developers behind this project. beta and RCs are actually more robust than Flow releases, for instance. You can even depend on nightly builds... It's solid.

- Very typesafe (way more than Java for instance), if you know what you're doing.

- The type system is now very, very expressive (version 2.0 and 2.1 helped a lot)

- It's extremely easy to use JS libs in your typescript project

- Performances are good as the generated JS is pretty much just the TS without the types annotations. There is no runtime, shim, etc.

- You still have access to everything JS, so for instance you can use CSS modules with webpack just like if you were using JS. The community is enormous.

[Cons]

- It's still crappy old javascript underneath. Everything is mutable (worse, Array apis mix mutable and immutable styles), if/else are not expressions, the "this" keyword, prototypes, classes are complete madness.

- Not typesafe enough if you are careless. Lots of traps. Unlike Elm, you can actually shoot yourself in the foot by not knowing about certain compiler flags, using <any> too often (I use a no-any tslint rule) or generally not paying attention enough (you need to give hints to the compiler in the right places)
It's always going to be less typesafe than Elm though. For instance, functions are bivariant, ewww.

So for me, Elm is interesting conceptually and it has the potential to become good in a few years (perhaps compiling to web assembly) but typescript is the pragmatical choice in the short/medium term, unless you're building something fairly simple, in which case you can use absolutely whatever you want anyway!