In mozilla-releng/services we are using Elm exclusivly

[garbas]

Currently, we have ~5000 lines in production. Not much, but good for a start. And since those 2 applications just got released this week, it makes a little less interesting that we have zero runtime errors.

We found it is easier to teach people Elm then teach them Javascript (with react/redux/<add 10 more libs here>). No more Javascript fatigue. Everybody can refractor

I could go on which problems we just don't have because of Elm, but maybe that would make this post too long and if somebody is interested then I can answer any question.

If somebody wants to give Elm a try we have some easy good-first-bugs tickets just so you can get a feel. We can also mentor you to learn Elm. It takes an evening/day to go through initial tutorials after that we pair program for few sessions and voila ... you are an Elm programmer.

https://github.com/mozilla-releng/services

[eliperelman]

5000 LOC in Elm is pretty respectable from what I've been seeing lately. For people that are already JS engineers from a traditional standpoint, probably the biggest barrier I see is learning the Haskell syntax and wrapping your head around functional programming.

For projects where they may be maintained by someone not familiar with JS, I think Elm is a good direction.

[garbas]

Haskell-like syntax is the least of the problem. Nobody complained about that, everybody was happy of a clean syntax.

The biggest problem is using existing libraries from javascript (javascript interop), but even those didn't show as a stopper.

[eliperelman]

By Haskell syntax being a problem, I meant from the perspective of web developers that have only done JavaScript; there will be a learning curve.

I understand that Elm has had some updates recently that have improved the interop story, which was concerning for me in the past. Do you know if that's true, and if so, what is different?

[garbas]

sure, there is a learning curve. You don't really want to measure how quickly somebody implements something, the metric you should really look at is, how quickly a newcomer to your project can make significant changes to your project. I found Elm gives guarantees that Javascript will never be able to provide. I can easily see anybody doing big changes to a project the second day after they learn Elm.

There is nothing new in the interop story, it was always working. I think (and I'm wrong all the time 😉 ) what was wrong with your approach is that you tried to convert all of a taskcluster client at once, which is hard, painful and gets you nowhere for some time. I don't blame you, I did few mistakes like this myself and probably will do more in the future. Moving things gradually into Elm is a much nicer experience.

One "new approach" of how to integrate with html+js widgets came up, explained here https://www.youtube.com/watch?v=ar3TakwE8o0

To give 2 quotes from a recent post on Elm -> https://www.pivotaltracker.com/blog/Elm-pivotal-tracker/:

• "To sum it up, our manager has mandated that all new code be written in Elm."
• "Elm contributor Richard Feldman once presented Elm by saying, “Make the back-end team jealous.” After our experiences using Elm, we can confirm that sentiment."

[eliperelman]

Closing as we now have directives about React over Elm.