I’m going to be starting a new job soon. The company is at a unique point where I’m going to be able to help decide on tech for UI (all greenfield, they have no front-end infrastructure at this point). It’s a medium-sized company, with a lot of enterprise customers.
I’ve used Elm on a couple side projects and have found that it lives up to the hype (recently upgraded a 2k loc side project from 0.14 to 0.18 and it was remarkably easier than my previous company’s React 14 to 16 upgrade), but that’s just for me. I’d like to propose using Elm at this company, but I know things are very different on a team than working by oneself.
I’m curious to hear thoughts from those who have watched teams acclimate themselves to Elm. Have you seen a significant reduction in production bugs (enough that it was worth the learning curve?) How was the learning process? What were the biggest hurdles to adoption, if any? And once adopted, what were the most challenging things to do with Elm that would have been easier with straight JS?
I feel pretty confident that even without any native code, Elm seems like a good choice for the vast majority of “line of business” applications (especially with 0.19 supporting non-deferred Cmds - I think I’m phrasing that right) . I just want to gut check with the community to make sure I’m not missing something. Last thing I want is to steer the company in the wrong direction (although pretty sure I’m not)!
I would be very cautious introducing a new language to developers for a greensfields project. You really want your teammates to be already informed and sold on Elm before you start and they won’t be able to be if it’s their first Elm project.
If none of your team has previous Elm experience then any failure or difficulty in the project will reflect badly on Elm. If your team isn’t completely sold on the benefits then any difficulty encountered will result in immediate push back to use something the team is already familiar with.
Unless you’re in a position to hire people that already have Elm experience you’ll be much more likely to be successful by having the team work with something they’re more familiar with (perhaps React) and picking a small part to write in Elm. This way your team can get good experience with Elm at much lower risk.
If you don’t handle the situation carefully you can get yourself in to a situation where the experiment with Elm fails in a way that means the company and your teammates will refuse to try using Elm ever again.
I was actually going to suggest we try it on a non-mission-critical, yet fun project first. But would that give the team the impression that it’s a toy language, not yet ready for something real?
I do not think that’s the case at all. In fact, your first project probably should not be a mission-critical thing. In my experiences, we first wrote a small 500 line internal tool, then a bigger 2,000 line tool. Only after those were successful did we jump to making something mission-critical with Elm (a key user-facing feature that in the end was over 20,000 lines). This is exactly the process that Evan describes in his how to use Elm at work blog post.
I just said this the other day, almost word for word:
In Elm, doing what might seem hard can actually be quite easy, and the inverse is also true
All of Elm’s unique features often come together to produce a language that often flips the definitions of ‘easy task’ and ‘difficult task’ on their heads.
I guess I’d say dive right in. The benefits of Elm are so high, especially in a team environment. Go ahead, get people out of their comfort zone!
Probably the biggest hurdle is the whole function programming thing. That does take a while to wrap your head around. But then one day it clicks.
Your team is going to be super-psyched! Programming in Elm is the best. (ps also highly recommend Elixir for the back-end. It’s similar enough that it’s easy to go back and forth.)
I have zero regrets that we chose Elm, and really can’t quite imagine if we hadn’t.
If you are just starting with this company, advocating for and gaining adoption of a non-standard technical choice can make you a hero if it succeeds or permanently tarnished if it fails. There is less downside risk when you have a reputation to fall back on, but that doesn’t sound like it’s the case here. You also want to be wary of the issues you could run into since anyone who isn’t sold on Elm will use any and all “problems” to declare loudly that it was the wrong choice. For example, Elm 0.19 may sound great, but it isn’t even officially announced yet, so your bet right now is on 0.18. If there are critical JavaScript libraries at the company, you need to figure out how interop with them is going to work because ports can easily lead to a lot of complaints that Elm is getting in the way. These issues are workable but there is a big difference between personal projects and corporate strategy. So, I would recommend surveying all of these issues and assessing your personal feelings around risk in deciding whether to go big or to try to slip Elm in and let it grow.
