[hellofunk]

This is almost never a problem since you simply use normal externs file for whatever library you are using. You never take an external library and run it through the closure compilation process, only your clojurescript code is put through those optimizations.

[Skinney]

> This is almost never a problem since you simply use normal externs file for whatever library you are using.

"almost never" and "simply use externs file (which you may or may not need to write yourself)" does underpin my point that you have to take care. I'm not saying it is necessarily difficult or takes a long time to get right, but it does require that someone makes sure everything survives the advanced opts compilation.

This has burned me on a past cljs project, it's not even a concern on my Elm projects.

[hellofunk]

I guess it all boils down to how you want to spend your time. Elm typically requires at least 4x the lines of code and at least 10x the time of dealing compilation issues compared to Clojurescript. So ultimately I think this is just a question of a desired workflow in one language vs. another. Any time spent on Closure-related issues (which have never personally bit me on any project -- I just use the library itself as an extern file and everything has always worked with no effort), is made up for with the fast development cycle on Clojure projects. Even including the increased runtime debugging in Clojurescript vs. Elm, Clojurescript has always provided me a significant productivity advantage over every other JS-family toolkit.

[always_good]

Your whole reason for replying to the submission seems to be "heh, ClojureScript already had this, but better ;)" but I'll chime in to say that the differences between Clojure and Elm, having used both extensively, especially become apparent when it comes time to refactor.

I would say that Elm lets me refactor front-end code fearlessly. I can confidently rewrite abstractions that are so fundamental that I'd be stuck with them forever in a dynamically-typed language because the rewrite would be so much more costly.

It reminds me of when people say that Mongo is better than Postgres for prototyping because it doesn't have a schema. In my experience, the very concept of having explicit schema transformation as the schema changes is why I'd consider Postgres to be better for prototyping: it's precisely the time when your schema is changing the most.

Of course, if we could unanimously agree on these trade-offs, then we would all be using the same stack and there would be no dynamic vs static typing debates.

[hellofunk]

I agree there are valid tradeoffs. In my experience, because Clojure code is so concise and tiny by comparison to Elm or most other language's, refactoring is usually replaced by actual re-writing, since the small amount of code is just as easy to architect again, maybe just saving particular functions, rewriting others.

[Skinney]

Your experience is different than mine, but I don't believe externs inference was in last time I built a cljs web app.

I still use Clojure as a backend language (I'll never give up Datomic) and while writing code in Clojure is usually faster, I spend much, much more time in debugging, often because of type errors, and especially after re-factoring. In Elm I spend more time up front, but less time overall.

I've been writing Clojure for six years now, Elm for three. There are definitely usecases where I'd pick Clojure(Script) over Elm, but for those usecases where it doesn't matter which of those you pick, I'd choose Elm any day of the week.

This is not to say Clojure(Script) is bad. In my opinion, Clojure and Elm are the best languages around.