Elm in the Real World

For a moment I thought the article would be about the email client: http://www.instinct.org/elm/

I've been involved with the Elm community for a couple years now and I haven't noticed a recent push to get people to talk about it more. I think people are just trying it out and getting excited by it.

I really like Elm and have become an intermediate user of it (as well as Haskell). I felt like I really understood what Elm signals are about and made some optimisations to Helm [0] based on that.

I pushed to use it for a contract for an open source application [1]. Ultimately that wasn't a success due to various factors but it's interesting to note that the client dropped Elm after I left and hired people to re-write everything in JS.

In retrospect Elm really wasn't the right choice for that project because it wasn't mature enough (and maybe I hadn't been using it for long enough either). The lack of any kind continuation monad for managing effects at that point (later added to the language as Tasks) and the cumbersome interop with JS (still an issue) were real sticking points. It's just frustrating when you have a problem that can be solved trivially with a state-mutating for loop and you have no easy mechanism to do it. The boilerplate required to use Chrome's messaging within the app was really painful.

I tried to use Elm again for a personal project, a kind of gallery website with a JS search function [2]. After starting an initial prototype in Elm I switched to using React (which I had never used before) and found I was much more productive (even though the code is messier). Having a much bigger repository of re-usable modules and being able to take short cuts is really valuable at this stage of development (and the server-side compilation ability is really cool).

These experiences have made me wonder about the real-world place for Elm and how long it would take for it to rival something like React. I definitely think there is a lot of value in learning Elm to help you think about state in your application in a more higher level way but I would really hesitate in advocating to use it for real-world project at this stage (it does depend on the project of course).

[0] https://github.com/switchface/helm

[1] https://github.com/kasbah/mooltipass.hid-app

[2] http://kitnic.it/ | https://github.com/monostable/kitnic (work in progress)

I strongly believe that for any language that compiles to JS to be successful, seamless integration with existing JS is absolutely required. This is the main selling point of Clojurescript which, while I enjoy Clojure a lot, is a dynamically typed language like JS itself, and I wish I could interact with JS in a stricter way. If Elm can improve on its interop, it has potential to be a strong force. But this is true of any new language. If you can't easily interop with the lowest common denominator language in the platform you build for, your language is too restricted for meaningful use. This is why Rust integrates well with C, because it has to, or it is irrelevant in many cases. This is why Clojure interops seamlessly with Java. Elm needs to get this point, or it will remain a niche hobby language avoided by professionals.

I think that's a bit unfair as Elm is already seeing some professional use.

Though on the subject of inter-op, Purescript might be what you are looking for if you want a strongly-typed, Haskell-like language, compiled to JS with a less cumbersome foreign function interface.

Your point still stands though, I hope Elm comes up with some good ways to say "trust me I know what I am doing" and "here is some JS, run it".

EDIT: Though it might be that that goes against the whole premise of the language.