&gt;I love writing Clojure(Script) code, but I hate reading it. It fits perfectly with the way I think (when I&#x27;m writing code), but horribly with the way I try to understand code I wrote months ago.<p>I&#x27;ve used Clojure for 2 years - I feel the same way. It&#x27;s a wonderfull language that exposed me to great ideas and showed me that simple things can be simple but boy does it get nasty when things don&#x27;t fit the provided primitives and actually start getting complex - the language has no tools to deal with complexity it can&#x27;t simplify.<p>Also a - for CLJS from me is that they haven&#x27;t abstracted out the (do ...) macro from channels (ironic with all those talks harping on how simplicity is about disentangling things). The biggest pain in JS&#x2F;DOM ecosystem is shitty  semantics, poor standard library and callback stacks. ClojureScript fixes first two really well and does a half-assed job at fixing the last - channels are too much overhead for such task (from both performance and conceptual POV - putting a queue in front of every callback is silly in a single threaded model).<p>I feel like Elm is a language designed to explore an idea not to be practical, this is why I haven&#x27;t tried using it for anything serious.<p>TypeScript has potential in theory to bring ES6 + type safety to avoid semantic pitfalls - but in practice it&#x27;s supposedly biggest strength of leveraging the existing JS ecosystem is also it&#x27;s greatest weakness in that you&#x27;re still left there with shitty JS ecosystem with zero consistency, most libraries deal with JS pitfalls in their own unique way which doesn&#x27;t mesh well with other approaches or with TS, fragmented build, packing, dependency management, module loading tools - all trying to solve the same problem in different and incompatible ways - it&#x27;s just a pile of junk that wastes more time trying to reuse stuff than it takes to build anything - which is probably why most of it is in the state it is - and very few things are actually maintained so the argument that reinventing something means you need to maintain it yourself is not really convincing.<p>Dart has a built in package manager, has had tools for dealing with async code for a while now (both async&#x2F;await and streams), it&#x27;s familiar to the Java&#x2F;C# devs but it&#x27;s surprisingly concise (quite a few nice touches like constructor property-parameter mapping or =&gt; getter syntax for tedious stuff), the standard library is great and avoids all the JS pitfalls.<p>The downside is that you still need JS interop because there&#x27;s no way around it (for eg. emscripten) - and talking to JS from Dart is still nasty - much more involved than CLJS or TS.<p>Having used all 3 mentioned for non trivial work I like Dart the most and the new JS interop could make it even better.