Elm with Lindsay Wardell
Lindsay Wardell explains Elm, a functional language compiling to JavaScript, and why its type system and guarantees make it a compelling alternative to React and Vue.
Episode Description
Lindsay Wardell joins to explain Elm, a functional programming language that compiles to JavaScript, and why its type system and guarantees make it a compelling alternative to frameworks like React and Vue.
Episode Summary
Lindsay Wardell, host of Views on Vue and developer at NoRedInk, walks through her programming journey from PHP and jQuery to Vue, and eventually to Elm, a pure functional language that compiles to JavaScript. She explains that where JavaScript developers typically cobble together a stack of tools — a framework, TypeScript, a linter, a state manager, a build tool — Elm bundles all of that into a single cohesive language with built-in types, a package manager, and a compiler that produces famously helpful error messages. The conversation centers on how Elm's type system goes further than TypeScript by actually validating data at the boundary, catching issues like a backend silently sending numbers as strings. Lindsay argues that the real power of Elm lies in the combination of pure functional programming and strong types, which together virtually eliminate runtime exceptions. The hosts explore whether Elm is suitable for beginners, how it coexists with JavaScript through interop and libraries like Lindsay's Elm Vue Bridge, and why the Elm community values stability over rapid growth. Lindsay closes by pointing to NoRedInk's years-long track record of near-zero Elm errors in production as concrete evidence that the language delivers on its promise of reliability.
Chapters
00:00:00 - Introductions and Lindsay's Path to Vue
Lindsay Wardell introduces herself and traces her route into web development, starting with building Sonic the Hedgehog fan games and eventually needing a place to host them. She describes spending years with HTML and CSS while deliberately avoiding JavaScript, then rapidly moving through raw JS, jQuery, and finally Vue in a compressed three-week evolution.
The conversation touches on how Lindsay became a host on Views on Vue in 2019 and what she's gained from podcasting, particularly the chance to hear how other developers found their way into the Vue ecosystem. Christopher shares his own background moving from PHP and WordPress to React Native and back to the web, and the hosts briefly debate the differences between the virtual DOM and the shadow DOM.
00:05:30 - What Is Elm and Why Use It
Lindsay lays out Elm's core pitch: a pure functional language that replaces the JavaScript developer's typical grab bag of tools — framework, TypeScript, build tool, linter, state manager, test runner — with a single unified language and toolchain. She walks through how Elm's type system validates data at runtime boundaries, not just at compile time like TypeScript, and shares a real example where converting a Vue front end to Elm immediately revealed that her backend had been sending numbers as strings.
The discussion covers Elm's guarantee of virtually no runtime exceptions, the absence of null, and the use of result and maybe types to force developers to handle every possible case. Christopher observes that Elm requires unlearning JavaScript assumptions rather than just adding a compile step, and Lindsay agrees that crossing over to thinking in Elm represents a genuine paradigm shift.
00:12:06 - Adopting Elm at Work and in the Community
Lindsay explains how NoRedInk, her employer, began experimenting with Elm in 2015 after Richard Feldman championed it internally, grew the codebase feature by feature, and now runs essentially all front-end code in Elm. She recounts her own rocky start with the Haskell-like syntax, how building a side-project strategy game finally made the language click, and why Elm's compiler makes large-scale refactoring dramatically easier than in JavaScript.
The hosts discuss why Elm's type system and functional purity work as a pair — neither alone provides the same guarantees — and Anthony draws a comparison to refactoring tools in Java's IntelliJ. Lindsay emphasizes that the compiler acts as a guide: add a feature in one place and it tells you every other place that needs updating, so once the code compiles, it works.
00:19:27 - Elm's Growth Philosophy and Community Culture
Christopher asks whether sudden mass adoption would help or hurt Elm. Lindsay explains that Elm's creator, Evan Czaplicki, prioritizes stability over popularity, and the community doesn't chase the kind of explosive growth seen with frameworks like Astro or React. She notes that an influx of JavaScript developers would likely push for closer JavaScript interop, which Elm deliberately restricts because arbitrary JS calls break type safety.
Lindsay also reflects on how learning functional programming retroactively made object-oriented principles click for her, and references Richard Feldman's talk on why functional programming isn't the norm. She argues that the biggest gap in functional programming communities is clear explanation for developers coming from imperative backgrounds, and hopes broader adoption would help close that gap.
00:25:51 - Elm for Beginners, Vue Comparisons, and Elm Vue Bridge
The hosts ask whether Elm works as a first language for someone new to web development. Lindsay argues it can be an excellent choice right after HTML and CSS because beginners won't carry the baggage of JavaScript's mutable, dynamic patterns — concepts like returning immutable state feel natural when you haven't learned to do it another way. She then compares writing Vue and Elm, praising Vue and Svelte as approachable JavaScript frameworks while noting that Vue's reliance on mutation for reactivity makes it fundamentally different from Elm's approach.
Lindsay plugs her Elm Vue Bridge library, which lets teams embed an Elm application inside a Vue component with familiar props and events, lowering the risk of adoption. She encourages teams to experiment by rewriting a small feature in Elm within an existing codebase rather than committing to a full migration.
00:32:20 - Where Elm Shines and Closing Thoughts
Christopher asks for Elm's ideal use case, and Lindsay turns the question around to highlight JavaScript's flexibility versus its lack of guarantees. She argues that Elm excels anywhere a browser application needs reactivity and reliability — from her side-project strategy game with AI decision-making to NoRedInk's education platform with complex nested state. She cites NoRedInk's production record of only two Elm errors over several years compared to the constant stream of JavaScript errors visible in most major web apps.
The episode wraps with Lindsay sharing where listeners can find her online, promoting NoRedInk's open positions for developers interested in Elm and Haskell, and the hosts thanking her for a thorough introduction to a language many listeners may not have encountered before. The final timestamp is 00:40:11, marking the total duration.
Transcript
00:00:00 - Christopher Burns
Do you want me to come along? No, no, no. I'm okay going by myself because I'm actually going to take time to listen to a podcast.
00:00:16 - Anthony Campolo
Lindsay Wardell, welcome to the show.
00:00:18 - Lindsay Wardell
Hey, thanks for having me.
00:00:19 - Anthony Campolo
Great to have you. You are the host of your own fantastic podcast, Views on Vue, and you are a developer in various ecosystems. You are, of course, a Vue developer. You're also an Elm developer, which will be really interesting because you haven't talked about Elm at all on this show. But before we get into all these topics, why don't you give a general introduction of who you are and what you do?
00:00:43 - Lindsay Wardell
Sure. My name is Lindsay Wardell. Pronouns are she/her. I live in Portland, Oregon. Growing up, I was fascinated with video games and Sonic the Hedgehog in particular, so I tried to make my own fan games with Sonic. Eventually, I needed somewhere to put them, so I got into web development.
I spent a good chunk of time just with HTML and CSS and actively avoiding JavaScript because it's JavaScript, and that was scary in the 2000s. It took a while to get into the full front-end experience, but in 2018 I needed a front-end framework.
It's kind of funny. I went through the entire history of JavaScript in like three weeks. I went from raw JavaScript, getElementById. I didn't even know about querySelector at the time. Just getElementById, all of that fun stuff that we used to do. Then I was like, there's got to be something better. I found jQuery and I knew of jQuery. I used it a little bit.
[00:01:30] I decided to dive in, so for two weeks I was all in on jQuery. Thought it was excellent, and then realized I was basically just writing HTML inside of template tags. So I switched to Vue because that was what I was doing anyway. Might as well actually use a framework that's built for it.
So I went through the evolution of JavaScript in three weeks, and then I discovered Vue. I found it phenomenal. I was coming from a PHP background; being able to write HTML, CSS, and JavaScript in a single file just felt natural, and being able to compose those things together.
I just started using Vue. About a year and a half after that, a call went out for new hosts on the show, Views on Vue. I applied, about five of us were picked to be the new hosts. At this point, there are two of us from that original group that are still left from 2019.
00:02:11 - Anthony Campolo
That's Steve is the other host, right?
00:02:13 - Lindsay Wardell
Steve is the other host. Yep. Shout out to wonder95 on Twitter.
00:02:16 - Anthony Campolo
Yeah, that's on the Devchat TV, which is now, I think, Top End Devs or something like that.
00:02:23 - Lindsay Wardell
Top End Devs. Yeah.
00:02:24 - Anthony Campolo
Top End Devs. Yeah, they do JavaScript Jabber, React Roundup, a whole host of shows led by Chuck. I'm a really big fan of all the shows he does. I've been on JavaScript Jabber myself twice and have definitely had my eye on making it on some of the other ones as well. What do you think has been the biggest value add you've gotten out of hosting a podcast?
00:02:47 - Lindsay Wardell
I think the biggest thing for me is getting to chat with a whole bunch of different people about a whole bunch of different topics. Given that it's a Vue show, we're still mostly focused on Vue. Occasionally we've brought on somebody who's more React specific. We had one developer come on who'd written a book about Svelte just to talk about Svelte and the differences of it. But in general, we're talking about Vue.
Even within that ecosystem of talking about Vue, there's so many different folks to talk to and get their perspectives. Like, I was just telling my story of how I got into programming and how I got into Vue. That's typically how I start a show, asking, how did you get into Vue? And just hearing that exploration of, I started here, I moved there, I discovered Vue at this point, this is what I've done with it since then, has been really fascinating. I feel like it's extremely useful to get that perspective on what we, as developers and as humans, where we're coming from when we approach the development ecosystem.
00:03:41 - Anthony Campolo
Chris has recently been learning some Vue. Actually, he was a React diehard for the longest time and has dipped his toe in just a little bit.
00:03:49 - Lindsay Wardell
I won't hold React against you. It's okay.
00:03:51 - Christopher Burns
Look, I wouldn't say I'm a React diehard because I had very similar experiences to you. I started with PHP, WordPress, CMSs, all that kind of thing. I built websites that way, then took a break from web development and went over to app development. That's where I learned React well, React Native specifically. And then obviously when I came back to web development, I was like, oh yeah, I must just use React. That's how web is these days. Nothing else exists.
I got so entrenched into React that when people say, like, there's no shadow DOM, it's literally scary. It's like, what do you mean there's no shadow DOM? That is scary. I do not want to even go touch that. You make that sound like a feature, but to me that sounds scary.
I was building some examples for everyone in the company I work at, and I was like, I can't just build React examples. I have to go build a few examples and a Svelte example. I started with Svelte and found it easier, and then when I got to Vue it derailed me to a certain extent. I felt I had to learn the framework before I could just make an example. Unlike Svelte, I just couldn't make an example using my prior knowledge.
So I do know a little bit of Vue now. I know a lot about it on a higher level. Obviously like Nuxt is next, and plugins and all these kinds of things, but it is scary to think of a world without a shadow DOM, and that sounds weird.
00:05:10 - Anthony Campolo
You mean virtual DOM?
00:05:11 - Christopher Burns
Virtual DOM? Yeah, depends on what you call it. Everyone calls it different things.
00:05:15 - Anthony Campolo
Yeah, shadow DOM is a whole other thing related to web components and stuff.
00:05:19 - Christopher Burns
Oh my god.
00:05:20 - Lindsay Wardell
To be fair, there is no shadow DOM in React typically either.
00:05:23 - Anthony Campolo
Yes, that's correct.
00:05:24 - Christopher Burns
Whatever it is, it's just complicated logic. The more you think about how it works, the more it scares you.
00:05:30 - Anthony Campolo
Today, though, you are doing less Vue development and more Elm development. So why don't you talk a little bit about what Elm is and how the transition from Vue to Elm has been? What have been some of the big differences there? I'm sure there are some pretty key differences.
00:05:45 - Lindsay Wardell
Before we begin, I'm just curious for both of you, what general understanding do you have of Elm, especially since I've been talking about it on Twitter. I know a lot of people that I've talked to for years have been like, wait, what's Elm? What's this thing? I've never heard of it. So I'm just curious what both of you know, real quick.
00:05:59 - Anthony Campolo
Coming from the perspective of someone who listens to tons of podcasts, that's been kind of my main exposure to Elm because people like Richard and others in the community go out and do lots and lots of podcasts. I've heard Elm core team members talk about Elm a bunch, so I know that it's a functional language that's roughly based on Haskell that compiles down to JavaScript, and it has a very nice compiler and gives you these highly detailed error messages and type safety and the types of things that people really want out of JavaScript but can't get. So they use things like TypeScript or other compile-to-JavaScript languages. I've never actually written a line of Elm, but I think I get the value prop. That's basically what it comes down to.
00:06:45 - Christopher Burns
I know of it. I know it's compiled to JavaScript. I know that there are some particular diehards around me that will only write it and will not write anything else, but that is pretty much it on my side.
00:06:58 - Lindsay Wardell
You basically got the high-level view. Elm is a pure functional programming language for writing reliable web applications. It can be used in the same way that you would reach for something like React or Svelte to build single-page applications.
The main value proposition of it, if you're looking at it as a JavaScript developer, let's use React as an example. If you're using React, great, you've got React. Typically you're also going to be using npm to install your dependencies, not using something like unpkg. You're going to need a build step at some point, so you're going to need a build tool of some sort. You're going to need to reach for TypeScript eventually, because TypeScript is the thing that we go to when we want stronger type systems. If you're wanting a less dynamic language, you need those types.
React also, despite its very functional approach, does, at the end of the day, live in JavaScript land. So you need to be careful with immutability. You might reach for something like Immer or one of the other immutable libraries that's out there. At some point you're going to need global state, so either you're going to reach for context or you're going to reach for Redux or one of the global state options available within the React ecosystem.
On top of that, you're going to need ESLint, and you're going to need Prettier, and you're going to need Jest for all the testing. That's just unit testing, obviously. All of this gets orchestrated into a single application. So you're reaching across all of these different tools, plugging everything together in a very much JavaScript way. This is how JavaScript works.
When you approach Elm, the first thing you notice is you don't need a framework. You're just writing Elm. Elm provides all of the tools that you need to write an application for you. You don't need anything third-party in that regard. If you want to build your Elm application, Elm comes with that because it's a language. You can just run elm make and you're done. If you want to install a package, you're not reaching for npm or a third party. You're running elm install, which uses the Elm package repository.
Elm comes built in with types, so you don't need a third-party language superset. You have it built in, and so on and so on. All of the things that you really need to do to build an application are present in the Elm language itself. The only things that I would say are not there, that get added on afterward, are like testing, but that's, again, just built in Elm. You just write tests in Elm for Elm, and you can install those dependencies.
From a JavaScript perspective, you're already thinking of much less tooling. You have a single tool that does everything that you need to do. On top of that, you then get the benefits of functional programming. Elm is a pure functional language. It has a certain number of guarantees that you don't get in JavaScript, even if you reach for something like TypeScript.
For example, if you make an HTTP request to a server, which is pretty common in the web development space, in React you're going to get that payload back. Let's just say we're using fetch. Then you translate that into JSON. You can set a type on that in TypeScript saying, I expect this type to be coming back from the server, but TypeScript doesn't actually guarantee that the type you got is the type that you expected. All it's doing is putting an annotation saying, I think it's this type, so don't throw errors if I try to access these keys. That's all TypeScript is really doing at the end of the day for you.
In Elm, if you want to do something like that, you're going to actually parse the JSON that comes back and turn it into an Elm type, and it's going to run through a validation to verify that all of the data that you're getting is exactly what you expect. This cuts down on a whole bunch of different kinds of errors when communicating from Elm to the outside world.
I'll give an example. I had a side project where I've been working on this thing for two years. It's got a Vue front end and a TypeScript back end using TypeORM for talking with Postgres, and I decided I'm going to convert the front end to Elm because I'm having a lot of issues with this Vue app. I feel like I've painted myself into a corner. I can't really do anything with it. I have to refactor anyway. I might as well start from scratch.
Once I implemented this pattern with Elm of fetching data and having to parse it, I discovered that my back end had been sending all of my numbers as strings, which explained a whole bunch of errors that I'd been having with addition, because JavaScript and addition with strings is a thing that you can do. Elm immediately threw an error and said, hey, I expected a number and I got a string. What's up? I was able to prevent that error from ever getting further, and I never ran into it again. I went back to my server and I was able to fix it.
Elm also provides a very restricted level of language, which, again, if you're coming from JavaScript and you're very used to its dynamic structure, can feel restrictive. But the type system that Elm provides guarantees that your application is always going to work. Elm has a guarantee of basically no runtime exceptions. You're not going to run into an issue of undefined is not available or cannot read null of undefined. Null doesn't even exist in Elm. If you want to have a null type, you're out of luck. If you say something is going to return a string, it better return a string.
Elm does have a concept of maybes. So if, let's say, an HTTP request, you're going to get a result. A result can either have an error, which is an HTTP error in this case, or it will parse through the JSON to an Elm type. It's one or the other. It's never going to be both, but you have to handle both cases. Values are not going to be missing that you never expect to be missing. Those are some of the high-level guarantees of Elm and why somebody would reach for it. The ecosystem is much more unified.
The language ensures that you're not going to have some of the errors that even TypeScript can't catch, because all of its safety is running in production rather than just during development. I'll pause there and let you ask any questions about what I just said.
00:12:06 - Christopher Burns
This is actually really, really interesting. We say at the beginning, oh, it compiles to JavaScript, so we expect it to work similar to how TypeScript works, for example, because that compiles to JavaScript. But it kind of feels like the whole pitch that you've just said is you've got to unlearn your knowledge of JavaScript to relearn your knowledge of Elm. It's completely different, even though it compiles to the same thing, basically.
00:12:31 - Lindsay Wardell
I think that's fair. It's not completely that you have to unlearn it because Elm does interact with JavaScript in some ways if you need it to, because of its restrictive nature. There are some things that Elm just can't do. It's not going to catch up with all of the browser APIs. We're getting new APIs every year at this point. Elm is not going to do that, and there's no guarantee on what those APIs are going to return. They could return undefined. They could return something sometimes. So Elm just isn't going to go there. If you need JavaScript, you're going to use it.
But as far as the patterns for building an application, I feel like, for myself, I crossed this line at some point in the last few months where I was able to say, Elm makes sense and I like it, but I'm primarily a JavaScript developer. And now it's, JavaScript makes sense and I like it, but I'm primarily an Elm developer. That's kind of the feeling I have.
00:13:14 - Christopher Burns
How have you converted from, obviously, a JavaScript developer to more, you feel like, an Elm developer? Have you got any buy-in from the company you work at? Have you persuaded them to convert that whole codebase to Elm?
00:13:30 - Anthony Campolo
This is something that we should talk about because you were hired to write Elm, so the company was already doing Elm, and they actually have Richard, one of the core team members, on. So I was curious, did they start with Elm and then hire Richard, or did they hire Richard and then Richard got them to write Elm? What came first?
00:13:47 - Lindsay Wardell
There is a whole video on that, which I will send you a link to, and you can put it in your show notes if you'd like. The name of the video is From Rails to Elm and Haskell by Richard Feldman. I believe the talk is from 2017 or 2018.
The gist of the story is, yes, I work at NoRedInk. NoRedInk is a company in the education space, working on teaching English and writing to middle and high schoolers. By the way, we are hiring, so anyone who wants to apply, you are more than welcome. NoRedInk has been writing Elm since about 2015. This is, at this point, a six- or seven-year-old Elm application that has been expanding over time.
The core story is originally when NoRedInk started in like 2012 or 2013, they were primarily writing in Rails and CoffeeScript and eventually adopted React because React was new and cool, and it did a lot of things that they wanted to do to make things better on the side. Richard, who was already working at NoRedInk at the time, discovered Elm and started playing around with it and thought this was a great technology to try out and use, but it's not production ready. Why would we ever do that? That's a risk. We're a startup.
But in 2015, he kept showing it off to his team, and they kind of looked at each other and were like, why aren't we using this in production? What's actually stopping us? So they did an experiment. They just took a small feature in their codebase, wrote it in Elm, and it worked. So they started writing more features in Elm, and more and more and more, and it just kept growing from there. At this point, basically our entire front end is written in Elm. I don't have the quote on lines of code, but I'm sure it's in the tens of thousands, if not hundreds of thousands.
I was hired in October as a developer to be working specifically in Elm at that point. I discovered Elm myself in 2019, listening to, I think, a JS Party episode where they were just checking in with the language. The way it was described in that episode was like TypeScript, but hard mode.
[00:15:29] At that point, I was thinking, oh, that's a challenge. Challenge accepted. I'm going to learn Elm. So I was joking with my team at the time because we were ahead of schedule: Hey, over the weekend I'm going to rewrite our thing in Elm just because. And I started learning it and it made zero sense. The syntax is completely different. Looking at it like you said, it's a Haskell-like syntax, so it doesn't have the same core structures that you see in C-based languages.
You're not going to have a function declaration saying function blah. You're not going to have extra parentheses and curly brackets all over the place for your declarations. When you declare a function, you just give it a name and you say equals, and then you do the thing you want to do. If you have arguments, you just put those after the name of the function and before the equal sign. Nothing is in parentheses unless it's an actual tuple. It looks a lot different and you get used to it after a while.
But the first couple times I tried Elm, I didn't know what I was doing. None of it made much sense. At some point I was working on a side project. A side project I do is this turn-based strategy game. I was trying to rewrite it in all of these different things. I first wrote it in React, then I wrote a CLI using TypeScript, then I ported it to Svelte, and this time I was writing it in Elm and I started making that work. That's when the syntax made sense, and that's when the language started to click.
I was able to start running and I could see the benefits of writing code in Elm rather than writing it in a JavaScript or TypeScript way. One of the huge things I didn't mention about Elm is because of its type system and because of how it's structured, it is super friendly to actually refactor an Elm application rather than a JavaScript application. If you're using JavaScript, you kind of have to guess and hope that you did it right, and you have enough unit tests and you're able to catch all the edge cases. In Elm, the compiler is super friendly and super helpful for doing this. If you add a feature in one part of your codebase, it will then just tell you these are all the other places you need to fix that. And then you just walk through the compiler and once it compiles, it works.
00:17:15 - Anthony Campolo
Yeah, it's a little bit like I used to do for a very brief amount of time, some Java development when I was in my bootcamp.
00:17:22 - Lindsay Wardell
My condolences.
00:17:23 - Anthony Campolo
Yeah, it was the worst. I would never do it again. It's a bad time in my life, let me tell you. But you get a similar thing with IntelliJ IDEA. You can just kind of click a button and refactor all of your methods, just immediately refactor it throughout your whole project.
This is interesting because when I had first heard about things like Elm and heard about the benefits you get from it, people would always stress the functional part. This is a functional language, and that means that it's immutable and that your inputs get you the same outputs every time, and you hear kind of the same pitch every time with functional languages.
But now when I hear people describe it, they describe it the way you have and they compare it to TypeScript, and it sounds like the typing is actually just as important or even more important than the functional nature of it, because then you get the same inputs and outputs, but you also know the types of your inputs and the types of your outputs. But if your inputs and outputs are still undefined, then it's not very useful, getting it undefined every time because it's still undefined. I think that's pretty interesting that the type system seems to be more of the real value, or that the combination of the type system and the functional language is the real value.
00:18:32 - Lindsay Wardell
Yeah, I'd say the two go hand in hand. Without the type system, the functional aspect, like you described, is kind of useless. Whereas if you just have the functional aspect and you don't have the type system, you still have the dynamic nature of JavaScript. You don't have any strong guarantees about what your application does. I think putting the two of them together is the secret sauce of good functional programming languages and functional programming frameworks.
If you're going to use them in other languages as well, you need to have those two pieces in order to get the benefit. I was talking with Richard the other day and he said this in a talk: pure functional programming is basically a lookup table. If you replace the entire set of code that you write with just a lookup table, with I give you X, you give me Y, and that works, that is functional programming. But that only makes sense in an application if you can also guarantee I give you Y, Y is always going to be a string, or Y is always going to be a number. That's really where the power comes in.
00:19:27 - Anthony Campolo
Yeah. Other questions, Chris, related to Elm?
00:19:31 - Christopher Burns
Yes, I have a controversial question to ask.
00:19:36 - Anthony Campolo
Never.
00:19:37 - Christopher Burns
I've been brewing this one for a moment. Obviously, over the last few years we've seen tons of frameworks go from 0 to 1000 overnight. Astro is a perfect example of this, but it looks like Elm is much more of an organic growth. Slowly but surely, it's growing momentum, growing bigger, not injected by VC money. So if Elm was to magically grow exponentially overnight because it's such a radical way of understanding JavaScript, do you think it would be a detriment to the project, or do you think it would just take it in its stride and everyone now writes in Elm?
00:20:18 - Lindsay Wardell
That is a difficult question to answer. Obviously, Elm and the Elm community have a different view on success than I would say something like Astro or React or Vue do. The creator of the language, Evan Czaplicki, is really the one that's driving the development of the language. It is open source. People can make contributions, but it is really Evan's project. If I remember correctly, this was his thesis paper at some point. He's been working on it as a passion project since 2012. If I remember the dates correctly, I believe it predates React's public release.
Having mass adoption is not something that the Elm community is looking for. It's more about providing a stable and reliable tool. I think that answers the first question of why it has not happened. Because we have had React, we have had Vue, we have had who knows how many frameworks in the interim that have come and gone that we don't talk about anymore. Elm doesn't see itself that way.
It sees itself as this stable thing. If you want to use it, great. If you don't, well, it's still there. It's happy without needing the accolades of all developers.
I think if there was a sudden influx of developers moving from React or Vue into Elm, I don't think it would negatively impact the language itself. I think those developers would, kind of like what I was talking about at the beginning, be bringing their perspective, their experiences in programming, and providing yet more flavor and diversity into the language. I don't see a case where a sudden influx of developers would derail the language, because Evan and the team that's been working on Elm have been very consistent about what they want in the language and why they want it.
There's been some discussion over how closely should Elm allow you to interact with JavaScript, because other languages, such as ReScript or PureScript, or some of the other functional languages, allow pretty close interop with JavaScript, where Elm has it very often in a corner: if you want to do it, this is how you do it, but you shouldn't because it's not type safe. That's one of Evan's main points. It's not type safe. You can't guarantee what an arbitrary JavaScript function is going to do, even if you're the one that wrote it. You can't guarantee what it's going to do most of the time because JavaScript is, by nature, mutable. Things can be changed. Things can be altered.
I think you could import Vue or React or something and then modify it directly if you wanted to, because it's just JavaScript. Everything is mutable at some level. Things aren't safe in JavaScript. So there's been some pushback from Evan and the Elm team to making those kinds of changes. That would be the only thing I could really see an influx of JavaScript developers wanting: a faster way to interact with JavaScript because they're still thinking from the JavaScript perspective.
But I don't see any other issue with a mass influx of people joining the Elm ecosystem. I think it would be of great benefit because then we would have more people who are able to look at Elm. I think the one thing that's missing in functional programming communities in general is a way to explain it to people who aren't there. That's really what I'm trying to help solve myself, is how do I explain functional programming to people who haven't seen it, who haven't experienced it?
I'm getting off topic from your question now. I hope I answered it. Happy to keep going if it's good.
[00:23:12] When I was getting into programming, I went through a bootcamp. I did a four-year degree at the same time, and I kept learning object-oriented programming and the SOLID principles, and none of it made sense.
00:23:39 - Anthony Campolo
That's because the SOLID principles are dumb.
00:23:42 - Lindsay Wardell
I did not understand why object-oriented was important. None of it worked in my head. I'm just writing code. And sure, I'm writing a class and it's got some methods, and I get that I could extend that class and have inheritance, but what? None of it made sense.
Then when I was learning functional programming and I was learning about types and data structures and why you would want to encapsulate certain methods in a module with a type in Elm, suddenly object-oriented made sense too because it's the same thing, just from a different perspective.
And actually, going back to Richard, Richard Feldman gave a talk, Why Isn't Functional Programming the Norm? He kind of drills down through this same thing of object-oriented and functional being actually really close, especially when you follow the best practice of object-oriented, which is to not do most of what object-oriented offers. I feel like that's what's missing in functional programming communities right now, is explaining functional programming.
I would hope that if, let's say, the entire React ecosystem suddenly dropped React and picked up Elm because they decided functional programming was the way forward, they would find the way to explain it to more traditional, object-oriented, C-based developers.
00:24:51 - Christopher Burns
It's a really interesting question because I also did a CS degree for three years. I got taught C++, C, C#, and did it ever make an ounce of sense to me? A little bit, enough to get through it, but I wouldn't say I wrote a program in those languages since because they just didn't resonate in my mind.
I did tweak with Haskell on a tiny assignment that was like 100 lines of code, and it just made more sense. Where I was trying to go with this is we are constantly living in a world where things are becoming more web-based and obviously still moving more to the web. Do you think Elm is a great language for somebody who has never touched web dev? As in, this is my first experience of making a website before even thinking about React or any of that. Should they learn Elm first if they've come from a more traditional, say, C++ background?
00:25:51 - Lindsay Wardell
I think if somebody was coming into web development today, Elm is a fine first language to pick up after HTML and CSS. I think that's something to note. While there are ways to do those things in Elm, and obviously if you're writing an application, you're going to be doing HTML and CSS, I would start with HTML and CSS.
If you want to go toward Elm, I think you're going to have a pretty good experience because you're not already thinking in the JavaScript dynamic imperative way of programming. You're able to start just really quickly describing an Elm application. When you create an Elm application, you are creating an application. It has a main function. That main function has a view that it's rendering. It has an update function to change state. It has an initialization function to create your initial state. That's the basics of an Elm application.
So I think somebody coming to programming for the first time would be like, okay, we're going to create a program. Programs look like this. They have structure. I think that would make sense.
Then talking about how instead of updating state, we're returning a new object. I think conceptually for someone who is a new developer, if you just tell them this is what we do, they would just say, okay, that's what we do, and they wouldn't think twice about it. Whereas when you're talking to a JavaScript developer and saying, okay, we're returning immutable state, suddenly our brains go, oh, this is complicated. How am I going to make sure that my deeply nested values aren't references and they're actually new objects? How am I going to do this and that?
There's so much in that one statement of, we're going to return an immutable object as our result, that for a new developer, none of that would come up because they don't have that experience.
So I think Elm would be a good first language. That said, to do certain things you do have to reach outside to JavaScript, so JavaScript would probably be the second language.
00:27:31 - Anthony Campolo
I'd be curious, now that you have gotten very deep into Elm, what it feels like when you go back to write Vue code. Do you think about it differently? Do you feel like, this is dumb because I can't do all these things I can do in Elm? Are you able to take some of those principles into Vue, or do you just not even want to write Vue code anymore because Elm is just so much better? What does it feel like having to transition from one to the other?
00:27:58 - Lindsay Wardell
Is it just the three of us in the room? At this point, if I'm going to reach for writing something, I'm going to write it in Elm. I feel like Vue is still an excellent JavaScript framework. I actually just had this conversation on Twitter earlier today. Somebody from the Elm community was asking, what do you like about Vue? I've tried it a few times, but it doesn't have the guarantees that Elm has. What do you like about Vue?
I feel like Vue is fantastic for somebody, again going to that new developer, somebody who has never touched web development before. If they did want to go the JavaScript route, I would suggest either Svelte or Vue as the first framework because they feel like JavaScript just working in the way that you're already used to. You don't have to think about the bindings. You don't have to think about React providing a lot of power, but it also doesn't hide the complexity. If you're a new developer, I feel like React can be a good choice if you get used to it, but then you're thinking in the React way rather than just the JavaScript way.
I feel like Vue and Svelte tend to lead more toward the JavaScript way of doing things, and having a single-file component where you can have your HTML, CSS, and JavaScript feels natural. There's a lot of structure that Vue provides when building an application that is phenomenal. Looking at something like Nuxt for server-side rendering, being able to pull data from the server and then render it into the HTML without having to do an API request on the client, things like that are fantastic in the Vue ecosystem.
But then the difficulty is when you want to get some of the guarantees or some of the plans that you typically would make in an Elm interview, it just doesn't work in the same way. Vue is very specific on using mutation for how to trigger its reactivity. You're not going to just return an immutable object and hope for the best in Vue in nearly the same way. Even in Vue, you're mutating the global state.
So I think a lot of the patterns can apply. I definitely feel like I was doing functional programming in Vue for a while at one point, but they are complementary. They can harmonize really well using Vue and Elm together, but they're not going to be one-for-one replacements with each other as far as your coding style or methodology of writing an application.
Like I mentioned earlier, I was refactoring an application from Vue to Elm. In Vue, that's all in JavaScript. I wasn't even using TypeScript on that one. And I got stuck. I got painted into a corner. I couldn't actually make any refactors because it was too complicated. The JavaScript was too dynamic.
Refactoring it in Elm, it's taken me about three weeks to do the kinds of changes I needed to do in Vue, and I have a full application, so it's complicated. I feel like there's a good place for both of them, and I feel like there's a place where you can use both of them together.
I'm going to plug a library that I wrote called Elm Vue Bridge, which actually allows that, where you can stick an Elm application inside a Vue as if it were a Vue component, and just pass props to it and listen to events just like you would if it was a regular Vue component.
00:30:43 - Anthony Campolo
Yeah, it's pretty cool that you are building ways to interop between the two of them, because I feel like there are probably ways that you can get some of the benefits of something like Elm without having to go all in on it. Just so many people know these UI front-end libraries and not as many people know functional programming languages, but people have been getting more into them through things like React. I feel like the Vue and Svelte ecosystems have less of that bridge to a functional language. So having something like this, like an Elm Vue Bridge, is probably actually quite unique and not something you see very often.
00:31:20 - Lindsay Wardell
I'm going to give a shout out to Kevin Yank, who created a React component that does something very similar. This is what inspired me to do the Vue Bridge, because rendering Elm is as simple as binding it to a DOM node, just as you would in React or Vue. At the end of the day, it's JavaScript that compiles to JS and you just bind it to a node.
What the Elm Vue Bridge does on top of that is just providing that extra API to make it feel more like Vue. So it's a component. You can define props, you can define emits. It's all in Vue 3. You can just render it as a component, which is super helpful.
I think teams, if they want to look at Elm and want to look more at functional programming, could use this. Find a small aspect of your application, even if it's a large React application or a large Vue application, just find a small aspect of it, rewrite it in Elm, or write a new thing in Elm. Wrap it in one of these types of components. Stick it in your application and just see how it does. See how it feels to work with. There's a lot of risk in doing a full refactor from one thing to the other, but having this room to have a small experiment within your existing codebase is a lot safer.
00:32:20 - Christopher Burns
Super good information. I guess my final question is, obviously this sounds very particular because everything is web, but what would you say is a really, really good use case where Elm really does shine? Places where there's a lot of data or places that are more dynamic?
00:32:42 - Lindsay Wardell
I am going to ask a return question first. Where do you feel JavaScript shines? Because JavaScript is a highly dynamic language. Do you feel like JavaScript is really good for data applications or for building UIs? What's your thinking there?
00:33:00 - Christopher Burns
My thinking is the best thing about JavaScript is how much it can be molded. You can do an API, you can do a website, you can do a CLI, you can do anything. It molds into anything.
But when you were saying earlier about having problems with numbers, I have had this problem myself, like why is this number coming out like this? It made no sense, but it's only if you truly understand. Oh, it's because JavaScript is putting a string and a number, and it's now making its own number out of it.
I would see that benefit in things like an e-commerce shop component, as in working out the costs of how everything should be because you know what you want to come in: it's numbers, and you know what wants to go out: it's numbers. You don't want strings inside the situation.
But JavaScript is really interesting. When you say what's the biggest thing I think JavaScript is really good at, it's obviously, like I just said, being able to be molded into a lot of things.
Why is it bad at, does it even do anything really, really well? That's what I would say. And I don't know, there's always things coming out that do it better than JavaScript. Deno, for example, does JavaScript better than JavaScript. But it's a very open question for sure.
00:34:18 - Lindsay Wardell
Yeah. So the tagline for Elm is, "A delightful language for building reliable web apps." I think that really sums it up. You can build CLI applications. There are tools for doing that. You can, if you really want, stick Elm on the server side. But it's not the ideal. It's not where Elm shines.
Where Elm really shines is being in a web application where you don't need to worry that your application is suddenly going to break on your users. So I would say Elm is best suited for building an application that is going to be used by people on the internet. And I would say that it is a better language for building those kinds of applications than JavaScript is because you have stronger guarantees that your code will not fail to run properly on the client, and you can ensure that they have the experience that you actually intended for them.
00:35:08 - Christopher Burns
It's a good answer. I guess my final question, but it's not a question, it's more of a hypothesis, is like with all these kinds of things of like, how do we even measure it? How do we even measure all these things? It's like X is better than Y. How is it? Well, I write less code in X than Y. Okay. But it's all such a gray box of JavaScript. There's so many ways to do everything. Like I said about moldable, it's just which ways are better.
I think certain ways stand out for certain things, like server-side rendered stands out for things that are changing every single reload, but then things that should just be static like blogs and portfolios, that's where static site generation is amazing. Throughout this whole conversation, where it really came together is, if you're building something like a dashboard, Elm may be something that you want to think about.
Is that what you would say would be a really good abstraction of our whole conversation?
00:36:10 - Lindsay Wardell
Some of the kinds of applications that I've worked on in Elm: I've built a turn-based strategy game in Elm where there's an AI processing the state of the board and has to make decisions, as a side project. At work, we're building an application that allows you to navigate, and this is an Electron-based application, but you're able to move around in the application, add data, change rows, dive down into deeply nested bits of state. We're building an application for teaching English and writing, so there's the teacher aspect, there's the student aspect, there's being able to write essays and do quizzes.
I feel like Elm is suitable for anything in the browser that needs reactivity, so that you can guarantee that the users are actually able to do what they want to do.
How many JavaScript applications have we used, as in big ones? Google, Netflix, or Hulu or one of those big-name brands that's using JavaScript, often React on the front end, and we open up the dev tools and we just see the list of JavaScript errors that are being fired, because that's what JavaScript does, unfortunately.
As far as how do we measure this, I can give the example again, NoRedInk. Richard has given this talk a number of times. Whenever he's presented about how we use Elm, he'll show the number of errors we've had in Elm compared to the number of errors we've had in JavaScript, and you can't actually see the bar of errors in Elm compared to JavaScript because it's almost zero. I think at this point it is two in the years since we have been using Elm, and that was because we coded something wrong and we were using a feature that has since been removed from the language.
So if you want to ensure that your users are getting the experience that you're planning on, Elm is a way to do that. Whereas JavaScript, because of its dynamic nature, just will not provide that level of guarantee. You can hope for the best. You can have all the unit tests, end-to-end tests, QA, but somebody, somewhere is going to click the button in the wrong way and it's just not going to work.
00:37:54 - Christopher Burns
It's not even click the button in the wrong way. I hate to say it, but many people in my life are button mashers and it's every web dev's worst nightmare.
00:38:03 - Anthony Campolo
Can't fight the button mashers. They want it to happen now, and if it didn't happen the first time, clearly clicking it five more times will make it happen, right?
00:38:12 - Christopher Burns
Exactly. The button mashers always win. It didn't work. Mash, mash, mash. It worked. Done. But it's just the first request coming back slower.
00:38:22 - Anthony Campolo
All right, well, this is about the end of our time here. Lindsay, thanks so much for joining us and telling us about Elm. That's been a really great conversation. I'm sure some of our listeners probably don't know a ton about it and have gotten a good 101, and may want to try it out themselves. Why don't you let our listeners know where they can find you on the internet, and then feel free to plug your company's socials as well?
00:38:46 - Lindsay Wardell
Sure. So I'm on basically everything at @lindsaykwardell. Find me on Twitter, on GitHub. I also hang out on the Launch Dev Discord, so feel free to reach out to me there.
Like I said earlier, I work at NoRedInk. You can find NoRedInk at noredink.com. I think their Twitter is just @noredink. And like I said, we're hiring. If any of this sounds interesting and you want to write Elm or just learn it, we don't require that somebody knows Elm ahead of time. If you're just fascinated by functional programming and want to build applications, come apply.
00:39:15 - Anthony Campolo
Nice. Yeah, that's probably a good hiring pitch for people who want to learn cool new programming languages.
00:39:21 - Lindsay Wardell
Also, for the fun of it, we're also doing Haskell on the back end, so if you want to do 100% functional programming at work, this is a cool place to be.
00:39:29 - Anthony Campolo
Yeah, we'll have to bring you back on to talk about Haskell for sure. It's a very, very interesting programming language. That's about all the time we've got for today. So thank you so much for joining us.
00:39:40 - Lindsay Wardell
Yeah. Thank you.