I have not used Elm other than to play with it briefly. I see a lot of great praise for it though. It seems like a great set of concepts (including design choices for functional, immutable, and static support -- a bit like Clojure in the first two) and is very Mithril-like in its vdom and redrawing approach. I think I would enjoy programming in it. I can see why many people have the reaction you have -- especially if they come at Elm from, say, using ES5 JavaScript and some complex UI library like AngularJS or Dojo/Dijit or whatever else.

Why have I not switched? It is useful to disentangle the value produced in Elm by using vdom (similar to Mithril) versus the value produced by Elm being a better language than JavaScript. Both are true, but which one provides more value in different contexts?

When I researched Elm in the past, I also read posts by a few people who moved away from Elm due to integration issues with the rest of the JavaScript ecosystem (as well as a miscellany of typical other issues any new language has related to bugs/tooling/libraries/platforms/etc.). Whether those criticisms of Elm by past users were fair -- or whether they still are true -- I do not know. But those issues were about the language, not about the vdom/redrawing paradigm.

It seemed to me that TypeScript was a safer bet three or four years back for me to choose for myself over other compile-to JavaScript languages because I would also be learning plain JavaScript better at the same time -- and learning plain JavaScript well seemed like a good thing to do.

These are really tough choices given moving targets for languages and libraries -- including trying to predict where communities and designs will be in a few years.

JavaScript is a badly designed language because in trying to make things "easier" for non-programmers writing a few lines of code (like making vars global by default) it made programming much more difficult for anyone doing anything more complex. Languages like Elm (or many other compile-to-JavaScript languages, even C++ now given WebAssembly) can fix those core issues in JavaScript (given no need for backward compatibility) and are appealing for that reason even as they may have their own challenges.

And as a negative, TypeScript only goes half-way there to a better language -- leaving many of JavaScript's warts in place. Just one example of such a wart is the many globals defined on "window" which make it appear a local variable might be defined when it is actually some global value being referred to (e.g. "length" or "name" are defined as globals on window as in "const x = length"; for more gotchas see: https://developer.mozilla.org/en-US/docs/Web/API/Window ).

But that said, typically issues comes up in any framework or language that involve a "leak" in the abstraction. And then you need to learn about the surrounding system to make your application work well. While things may change in a ten years, right now, to make a good Single-Page Application for the web, you need to learn the basics of HTML, CSS, and JavaScript fairly well. I don't feel there is any substitute for that. I've tried (e.g. using Dojo/Dijit) and gotten burned. One thing I like about Mithril is that, vdom aside, it keeps you close to the "metal" of HTML/CSS/JavaScript with just enough support to handle repetitive issues well while not getting in the way and being relatively easy to debug.

Decades ago when I learned BASIC, I had already learned assembly language before that, and digital electronics before that. The combination of BASIC and Peek-ing and Poke-ing assembly language was great. But just knowing BASIC would have left me pretty mystified about what was going on under the hood of the computer.

I think the same would be true for someone whose first browser-based language was Elm or Java/GWT and not JavaScript. After learning the basics of HTML/CSS/JavaScript (the assembly language of the web), then sure, learning and using other languages like TypeScript or Elm can potentially help a lot -- though with tradeoffs (like Elm integration issues mentioned above).

For simpler things, I find just plain ES6/ES7 with Mithril actually works fairly well given JavaScript has improved a lot with ES6 and ES7 (especially with "let", "const", and "async/await").

For Elm and me personally, it is undoubtedly better to use than JavaScript/TypeScript in-and-of-itself, but having gone up the learning curve on those, whether it would be worth a switch at this point, I don't know. It clearly is "better" as a language -- but I am not convinced it is so much better as to make up for other possible downsides. There are a lot of great languages out there.

Personally, I am tempted by Elixir as a next language to learn (given Erlang's fundamental design beauty). But I feel productive enough in TypeScript and ES6/ES7 at this point (years into the learning curve on "the good parts") that I don't feel an urgent need to do that. Likewise for Clojure/ClojureScript which many developers also love and is also tempting. Or even Scala which can compile to JavaScript.

Anyway, for all my complaints about herd effect, I am sorry to bring up those sorts of issues as negatives for Elm given how entrenched plain JavaScript is right now. One of the problems with making choices like these is that people rarely switch languages because the alternative is 1.1X or even 2.0X better for some task overall. They tend to switch when something is 10X better. And that is a high bar -- especially if you compare Elm against TypeScript+Mithril+Tachyons and not ES5+AngularJS.