A number of posts and comments on reddit have objected to Elm because it is not exactly like GHCJS or Haskell, I wanted to talk about why.

TLDR: Elm and GHC/GHCJS are aimed at different project domains and have very different history

There are three key factors to consider here.

1) Age of of the eco system, Haskell and GHC are about 25 years old, Elm is about 4 years old. So this has some benefits to both languages. So in those extra 21 years Haskell has grown a very large eco system, it has been used in a wide range of places etc. This means that many things have wandered into the core library and language. There are a lot of extensions that are available, these give Haskell a lot of power, but at the cost of some complexity.

This complexity has several implications. First of all GHC is slow, given 500 lines of Elm code vs 500 lines of Haskell code the Elm compiler will compile it much faster. Now of course the Haskell compiler can do many things that the Elm compiler can’t.

In addition it places a load on the compiler, as you add language extensions like Template Haskell and libraries like Lenses it becomes harder to read code. More sigels in the code can make it harder to read for someone who is not familiar with the project. WTF Does =$=> mean in the context of this project? It seems that Haskell like many lisps tend to want developers to create abstractions in the language, new syntax, new symbols, code rewriting, one cost of this is that for someone who is not familiar with a given code base it becomes much harder to get up to speed.

On the plus side for Elm it means that Elm can do some things that Haskell can not, because it does not have to be backwards compatible. For example Elm was able to enforce semantic versions in its package library because it did not have to back support old versions. It also means that Elm can learn from Haskell. The Haskell Either type calls its cases Left and Right while Elm calls them Ok and Err. Now maybe Haskell folks are OK With Left and Right, but to someone new to the project they are not useful identifiers. Unlike say Just and Nothing they do not shout out semantic meaning.

In the case of Elm, there has also been a deliberate effort to be very careful about keeping the language simple. As of now there is really no meta programming in Elm. This makes some things much harder, but it also makes understanding code much easier as something is not about to rewrite an entire module. Elm seems to take after Python in that it wants there to be one simple and obvious way to do everything and not the old Perl “There is more than one way to do it” Theory. Haskell has a lot of semantic sugar, while Elm has almost none.

There has been some talk about adding in features for working with AST’s. This is not yet available , but hopefully will be soon.

2) Focus. Haskell is a general language that is used for a wide range of software development tasks. For example the Elm compiler is written in Haskell. Elm is however laser focused on making web front end development better. If you want to write code to test the avionics of a new airplane you will not do that in Elm, if you want to build a new SAAS app front end then Elm maybe a good choice.

There have been occasional comments that you can’t use Elm code to write a backend in NodeJS. These comments have some validity to them, but they kind of miss the point. Elm is designed to make the web front end development experience better. Web front ends have to be written in JavaScript (or compiled to it at least). Web backends can be written in any language. There are projects out there that use Elm with backends in NodeJS, Ruby on Rails, Haskell & Servant, Haskell & Yesod, Elixir, Erlang and others. That problem is well solved by existing technology, and an area of active development on many fronts. Elixir seems to be becoming a favorite in the Elm community. While lacking the type system of a Haskell it has the advantage of a rock solid VM in the BEAM.

Side note if you are using Haskell and Servant or some other libraries you can actually generate some Elm code from your Haskell code.

In addition Elm is really designed to take people who are developing in languages like JavaScript and bringing them into a typed language. after spending many years building front end code in JavaScript with a range of UI Libraries (ExtJS, JQuery, Backbone etc) I can honestly say Elm would be my choice. Its types are powerful enough to eliminate 99.999% of runtime bugs (YEA) yet simple enough for developers who are not used to Haskell’s types to grasp.

It has also been a fairly common experience that the learning curve for Elm is pretty shallow, while I at least have found that the learning curve for GHC and Haskell has been very steep. I would feel much more confident taking a developer who had only done other languages before and dropping them into Erlang, Elixir or Elm than Haskell.

Elm does not have the same features as GHCJS or purescript. All 3 of these languages sit in similar places in how they are used, just like Ruby, Lua and Python are used in overlapping ways. In the future they will all continue to develop in different directions and learn from one another. I think having several different languages out there in this space will in the long term be good for everyone.

3) GHCJS is lazy Elm is not

One final thing is that GHCJS is lazy, this is a very powerful thing in general but often not useful for web development. It also has a lot of overhead in terms of code generation and developer mindspace. Elm is not lazy. This makes understanding what is happening in some ways easier.

I wrote a book on Testing Elm you can pre order it now.