“How’s Interop?”

This was the first, and pretty much only question at an Elm meetup I went to last November. It’s an important question. We’ve probably all heard stories of front-end technologies that fight with each other. If I were to answer the question in the form of a blog post, I’d probably say something like this:

Interop between javascript and Elm is so simple and straightforward that it’s not even really worth talking about. You might encounter friction wiring Elm to another library or framework, but the friction won’t come from Elm. It will be the friction inherent in wiring anything to your chosen library or framework. The React documentation claims – and in my experience this is true – that “React can be used in any web application. It can be embedded in other applications and, with a little care, other applications can be embedded in React.” Such is the case with Elm. Embedding Elm in React is no sweat because React has chosen to play nicely with the other citizens of front-end land.

But instead of jumping straight to an answer, let’s reflect on the question a little more. Why would we care about interop with Elm? At this point in the history of the world, we’re probably wondering about interop with Elm because we’ve heard of Elm and we’re wondering if it’s worth looking into. If interop is a chore, then we can just forget about this Elm thing all together. But interop with Elm is not a chore, so let’s explore the broader question here: Is Elm worth trying?

Elm does a lot of important things really well, but none of that matters if you don’t like Elm. So would you like Elm? Here’s a series of questions to help you figure that out:

Question 1: Do you like to learn new things?

If not, then you probably won’t like Elm. It’s a functional language. Functional languages are significantly different than object-oriented languages, and if you just want to keep doing what you already know then you won’t like Elm because Elm is different.

Question 2: Do you enjoy modeling things with types and classes?

Here are two designs for a type that represents a tic tac toe board.

Which one do you like better? In the type on the left, a TicTacToeBoard is a collection of squares, and a square can have one of three possible values: X, O, or empty. In the type on the right, a TicTacToeBoard is a collection of strings. If you favor the one on the left, then you would probably like Elm.

Next we’ll model a data structure that I have named “SomebodysData”. There are two rules for SomebodysData. The first (and most obvious) rule is that it must belong to somebody. The second rule is that the somebody must be a group or an individual. The data cannot belong to both a group and an individual. Given those two rules (and your own past experience with classes or types), which SomebodysData do you like better?

Both of the above choices are generic types, with the “a” being the part that makes them generic. The design on the left constrains each instance of SomebodysData to be either a PersonalData or a GroupData. With the design on the right, you manage the concept of ownership by setting the appropriate Id to zero. If SomebodysData belongs to a group then the personId should be zero. If SomebodysData belongs to a person then the groupId Should be zero. And if you favor the design on the left then you would probably like Elm.

Question 3: Do you value type safety, static type checking, and friendly compilers?

This is what it looks like when I intentionally misspell the name of a property in my Elm code:

My model object has a property named “greeting”, but I’ve omitted an “e”. And this is cool because Elm will do the same thing when I accidentally mistype a property name. It will tell me, in very friendly terms, what I’ve done wrong, and try to give me a hint that will resolve the problem.

Question 4: Are you like me?

If you understand The Simpsons reference in this image, then we’ve got that in common. But you might be like me in other ways. Do you know several programming languages? Do you have experience using lots of different dev tools? How many of those languages and dev tools would you say that you love? If you are like me, then your list of loves is short. There are lots of languages and tools that I enjoy using, but only two items on my love list: Elm and git. That’s all.

For my job I write C# for .NET, and it’s a good, enjoyable job. For fun, I write Elm, and I love writing Elm because it expands my mind. It makes me a better developer. It helps me to write better C#.

That’s it for the questions, so what do you say? Want to try some Elm? Maybe you don’t. And that’s fine. I just don’t want you to turn away from Elm because you are concerned about interop. Interop is not going to be a concern. Whatever you’ve decided, thanks for reading! Everything beyond this point is for those intrepid souls who want to start using Elm at work.

Using Elm at work

Using Elm at work starts with persuading other people. Are you any good at persuasion? If not, then please think of persuasion as another skill that you can learn. Do you love Elm? Is Elm really that good? Then this is a perfect opportunity to practice pitching a great idea!

In addition to the persuading, you will probably need to know or learn Webpack. Or its equivalent. There’s an elm-webpack-loader on npm, and this is, most likely, how you’ll bundle your compiled Elm with the rest of your application’s javascript.

If your app is built on top of create-react-app or the Angular CLI or something similar then you’ll have to blaze your own trail. I’m talking about cases where your development tools hide the webpack configuration stuff from you (so you don’t have to worry about it). There’s probably a good solution for bundling your compiled Elm in situations like these, but I cannot tell you what it is. You will just have to know and understand your build process and adapt. Assuming that your build process isn’t needlessly complex (and sometimes they are, sadly), it should be pretty straightforward. In case it might be useful, I’ve posted some info about how your compiled Elm fits into the world of javascript modules at this link.

In addition to knowing Webpack (or its equivalent), you’ll need a better-than-average understanding of the dominant technologies that comprise your current front-end. We probably all know devs that stop learning right after they reach some level of basic competency, never pressing forward towards mastery. Given that you are interested in Elm, I doubt that this describes you. Just know that there will be some challenges in grafting Elm into your current front-end. The better you know that current front-end, the better you can meet those challenges.

Potentially useful links

I’ve published some simple interop tutorials on github:

Elm plus vanillajs

Elm plus React

Elm plus Angular