| "It depends". Are you writing a whole new app? or are you integrating with pre-existing js? Elm is designed around statically-typed functional reactive programming, and as part of maintaining that integrity at runtime, it puts some ceremony around js interop. Clojurescript <-> javascript interop is lower-friction, with all of the potential runtime failures that entails. So it seems that the less your component needs to interact with js, the more pleasant Elm would be, and vice-versa. What do you and your team already know? In circle ci's case, they already used clojure, so it was an easy choice to stick to that language on the front end. If you or anyone you know don't already have some familiarity with either an ML (in elm's case) or a lisp (in clojurescript's), consider looking into a language like that on the server at the same time. And of the two, clojurescript is more popular. This entails some confusion, sure (om? om next? reagent? wha? vs the 'just use the stdlib' of elm) but it is generally a Good Thing. In my experience, you're more likely to find answers to cljs questions, to have better tooling ('top speed'), and an easier time setting up that tooling ('acceleration'). You'll notice I compared Elm and Clojurescript, not Elm and Om/Om next. I think the attributes of the two languages probably outweigh any particular differences in app structure between Elm's "StartApp" recommended structure and om. |