[hellofunk]

I agree with much of your points but a few things to add clarification:

While lisps do traditionally provide repl-driven development and you can do this in Clojure, most Clojure devs I know are not actively working right at the repl. If you do like some aspects of repl-like interactivity, Elm does have elm-reactor which has some similarities to Clojurescript's figwheel, though not quite as mature or comprehensive.

Aside from the repl, you are right that you can get a proof-of-concept going in Clojurescript extremely fast so if you want to see if an idea succeeds or fails before investing lots of time, you can't beat Clojurescript.

The Elm toolchain is slowly evolving to include things like dead code elimination (which it doesn't have yet but probably will in the near future). However, I think it will be a long time (if ever) that Elm will support global inlining, automatic variable renaming and some other optimizations that come for free with the Google Closure compiler support. The other important difference is that as the Google Closure compiler adds features or further improves its optimizations, these are mature and widely used and immediately available for free without much (if any) extra work on the Clojurescript team. It's a philosophical difference that the Elm devs prefer to solve these problems on their own rather than leverage existing tools in the industry, but since the Elm dev community is small (much of it is only one person), this means that lots of time must be spent on these solutions at the expense of features more specific to the Elm language.

Also I think you are right that Elm as a language is a little easier to learn than Clojurescript (though to someone new to FP, both Elm/Haskell style syntax and Lisp syntax might be equally bizarre). But I think that ease is made up for by some of the concepts in Elm that can be difficult to learn (decoding, Tasks, ports, etc), so it's probably a net flat difference on the learning curves between the two systems.

[Nekorosu]

Thanks for clarifications. I actually pay some attention to Elm evolution and check the official blog from time to time. I was much more interested in Elm several years ago and I even tried to get a job at Prezi (Evan Czaplicki was still working there at that time). In the end I like ClojureScript more. It has a good balance of agility and guarantees. It's more generic. REPL enables exploratory programming and live coding. Btw ClojureScript developers I know do use REPL.

I probably wasn't clear enough but I don't think Elm is easier to learn. It's quite the opposite. The good thing about Elm is great default libraries for SPA development (or isolated widgets) and great toolchain. You just use what's given and it works perfectly fine. In the end getting productive fast is easier with Elm than with ClojureScript. And it's easy to do all by yourself. Everything is pretty strict and official site has a lot of up to date tutorials. I also like that Evan values simplicity and Elm gets better and better in this regard.

Every language has its place. ClojureScript is my personal preference. It's just a good fit for things I like doing.

[mjaniczek]

I believe you can use Google Closure Compiler on Elm JS files with great effect the same as Leiningen uses it on ClojureScript JS files. (Although most people probably use uglifyjs instead.)

But of course ClojureScript's JS is generated carefully so as to be better optimizable by Google Closure Compiler, and that's not the case with Elm. IIRC, in version 0.19 Elm will change it's JS so that it's better optimizable by uglifyjs.

[hellofunk]

> I believe you can use Google Closure Compiler on Elm JS files with great effect

No, you can't use the advanced optimizations from Closure compiler in Elm. This is unlikely to change any time soon because Elm's compiler emits JS that directly violates one of the restrictions that Closure requires for advanced optimizations, namely the referencing of field names as a string.

[mjaniczek]

Good to know, thanks!