How does Elm compare to ClojureScript?

Question

I'm reaching a point where GUI coding with Backbone.js object-oriented MVC pattern is getting quite complex, and looking around at other paradigms. MDV, FRP, ECS, oh my.

How does Elm compare to ClojureScript? Where do they overlap?

Both are languages very different from JS that compile to JS. I understand that Elm is a functional reactive programming (FRP) language. ClojureScript isn't necessarily FRP, but you can do FRP with it. Elm compiles with Haskell and ClojureScript with the JVM, so both of those are extra requirements for a Node shop.

Maybe it just boils down to Clojure vs Haskell.

Tirado

This question might give some help: https://mcmap.net/q/343248/-what-are-the-advantages-and-disadvantages-of-angular-js-vs-elm/90874 – Curet

Answer 1

Both force you to use a more declarative/functional programming style than pure JS. ClojureScript is more like a JS replacement, whereas Elm is more like a replacement for the entire web development stack (HTML/CSS/JS).

Other differences:

• Elm syntax is much more Haskell-like
• ClojureScript is much closer to traditional Lisp syntax
• Elm is highly optimized for time-varying values ("signals" in Elm)
• ClojureScript is more mature and you can find some sweet development tools for it (Eclipse plug-ins, LightTable, etc.)
• Elm is statically typed, ClojureScript is dynamically typed

Hope this helps. I'm still learning both of these languages so I may have missed something.

Paduasoy

This misses the biggest difference: types. ClojureScript is dynamically typed, which is very flexible, but Elm is statically typed, less flexible but eliminates nearly all uncaught runtime errors. – Limelight

@jmite good point, I updated my answer. Although I'd argue it's not the biggest difference, it's still a big one. – Paduasoy

Answer 2

Just to update this for 2017.

Elm is no longer FRP, that went away a few releases ago in favor of the Elm Architecture.

The major win of Elm is that it has a static type system that allows the compiler to make many assertions about program correctness at compile time. For example, you know for a fact that there will never be a time where a case statement does not cover a specific case. Or that the HTML from the view function will produce an event that the update does not know how to deal with.

Other Elm advantages

• Great Error messages
• Packages have enforced Semantic Versioning*
• Packages and tools tend to have really obvious names

*Semantic Versioning is a convention described here. It is a numeric version identifier of the form major.minor.patch that can be compared like 2.3.4 <= 2.5.0, so developers can see at a glance what kinds of changes were made.

In Elm, if FooModule 4.2.3 introduces a backwards-incompatible change to a function (Foo : Int -> Bool becomes Foo : Int -> String -> Bool), then the package will not be accepted to the official repository unless the major version is also incremented to indicate a breaking change (e.g. it can be uploaded as FooModule 5.0.0). In Elm 0.14, the elm-package tool was introduced to enforce this rule.

Charcuterie

What is "Semantic Versioning" and why is it important? Real world examples much appreciated. Thank you. – Eisen

Answer 3

They are both FRP (Functional Reactive Programming) at their core - meaning they have a tree mapped out to the DOM and only render that component or children that need be rendered. (as someone pointed out earlier, Elm has abandoned the FRP principles to pursue its own idea of them)

They both compile in JavaScript (although with ClojureScript/Om library or Reagent you could get actual React objects in your js) while Elm does its own thing. I don't like that Elm has to be installed through npm although czapliki as I understand is working on a standalone installer)

Elm is nicer in my opinion because it manages state a little more coder friendly and it has a very nice (as was mentioned --) Haskell-like syntax and also you move the RuntimeErrors into the CompileTimeErrors which is much more agreeable as a developer - plus it has easier code maintainability.

On the other hand, cljs has lotsa libraries - some of them as I mentioned return actual React Components (cljs/Om matches 1:1 with R.js LifeCycle) - others simply respect the FRP and LifeCycle mentality without becoming encumbered by it. Might want to look into Om/Next with has a GraphQL way of calling for data from an endpoint and has dropped the async chans that were used in plain cljs/Om.

It's a matter of taste to be honest, but I for one would prefer Elm (having written in both languages). If you do however go with cljs make sure you get a nice library and don't do stuff in vanilla cljs or you'll be sorry when you want to maintain 5k+ LOC.(look up Fulcro, Reagent, om, OmNext, hoplon, etc.)

Reversion