Upgrade Your Front-end Game – Be an Elm Wizard
You need to be signed in to add a collection
Elm is a purely functional language that compiles to Javascript in less than 4 seconds. We sat down with Richard Feldman, author of the book "Elm in Action" to understand how learning to code in Elm can help software developers whether they work with it on a daily basis or not.
Transcript
Listen to this episode on:
Apple Podcasts | Google Podcasts | Spotify | Overcast | Pocket Casts
Elm is a purely functional language that compiles to Javascript in less than 4 seconds. We sat down with Richard Feldman, author of the book Elm in Action to understand how learning to code in Elm can help software developers whether they work with it on a daily basis or not.
The GOTO Book Club’s mission is to help you learn from the experts and innovate.
The current episode was made possible with the support of Humio, the only multitenant solution that enables organizations log everything to answer anything in real-time — at scale, self-hosted, or SaaS. Humio’s modern architecture enables complete observability to answer any question, explore threats and vulnerabilities, and gain valuable insights from all your logs in real-time. Humio’s front end is developed in Elm, a functional language selected for its strong emphasis on simplicity, stability, and speed, which are all important capabilities in working with large data volumes in real-time and with high user interactions where data is being continuously explored. Humio offers low total cost of ownership and unlimited plans, with easy deployment at any scale, self-hosted, or SaaS.
Learn more about Humio from Kresten Krab Thorup, CTO of Humio
What is Elm?
Preben Thorø: What is Elm?
Richard Feldman: What is Elm? So, Elm is my favorite programming language. It's a language for building web app UIs. So, specifically, like, building UIs in the browser. And generally, it's used for building web applications as opposed to, for example, just adding a little bit of interactivity for a static page. So, Elm compiles to JavaScript so you can use it instead of JavaScript. Also, it has a JavaScript Interop. So, if you want, you can use it in conjunction with JavaScript. The most popular way that people introduce Elm to an existing codebase is that they will start off with an existing JavaScript codebase in, like, React or Angular or View, or something like that. And then they'll introduce just a little bit of Elm and then see it grow and grow and grow. And then maybe eventually it sort of shifts where their codebase becomes majority Elm and then eventually, you know, almost all or entirely all Elm. That's what we did at my job back in 2015 and so now five years later we have somewhere around 400,000 lines of Elm code and almost no remaining Legacy JavaScript code. Still a little bit. It's purely functional and it's got a lovely user experience, I think.
Will Elm take over the world?
Preben Thorø: Feeling that popularity has just been increasing. Will Elm eventually take over the world?
Richard Feldman: That's a good question. Personally, I think that Elm will become popular, but not the most popular. I think it's sort of seen slow and steady growth, kind of like Python did. So, Python came out in, like, the 90s. But, initially, it was not a very widely used language. It just kind of slowly and steadily grew and then it became used in more and more different domains, then eventually it became quite popular. Now it's sort of among the most popular languages. But, I think when it comes to building applications in the browser, it would take something really serious of a change for something that's not a JavaScript dialect to, like, take over the world, as it were. JavaScript has so much momentum. Having said that, for me personally, like, having spent a lot of time with Elm now, I just can't imagine myself taking a JavaScript or TypeScript, or CoffeeScript job ever again. It's really, just I mean, if I'm building a web app I'm doing it in Elm. And I think that while also thinking that Elm's not going to take over the world. Because as we all know, popularity is determined by a lot more things than just sort of technical merit. So, I think it's a great tool for me to use and I'm very happy to teach it to other people. But, at the same time, I don't think it's going to be number one in terms of popularity. That's my prediction anyway.
Thomas Angarius: Well, maybe comparing it to Python is not the best comparison either, right? Because that's a general programming language, whereas Elm is a functional language. I think that's, really, one of the big strengths for Elm is that it was tailored to doing web applications, right?
Richard Feldman: That's very true.
Thomas Angarius: So, I think you're right. I don't think Elm is going to take over the world, either. I think that it's a somewhat niche language.
Richard Feldman: It's focused.
Thomas Angarius: It's very focused and it's very deliberate and it's very opinionated in how it does things. And I think the very popular things that you see out there are more general, right?
Richard Feldman: Yes, they have a similar or broader scope.
Thomas Angarius: On the web platform is that JavaScript is the assembly language of the web, right? And as long as it remains that, people are going to write in JavaScript or things that are close to it because there are so many benefits to just being able to run the code directly in the browser. You don't quite get that in Elm, right? You are quite far removed, actually, when you execute the code. The code that's being executed from what you write.
Richard Feldman: That's something I like about it is that it. It's sort of an escape from JavaScript and TypeScript and that whole ecosystem and all the complexity of it.
Move away from the dependency nightmare
Thomas Angarius: Definitely, I mean, one of the things that struck me a couple of months ago is that at Humio, we have a codebase of, you know, 100,000 plus 200,000 lines of Elm code and we have, like, 12 dependencies, some of them, like, Elm tests, for instance, right?
Richard Feldman: Nice, nice.
Thomas Angarius: But in a similar JavaScript application, you would have hundreds of thousands probably of dependencies. I'm not even joking there, right?
Richard Feldman: Yes.
Thomas Angarius: And, I mean, personally, you know, when things go wrong or when I start to hack in my code is usually because I need to hack around something that comes from a dependency, right? So, when it's your own code, you don't really need to do that. And, sure, it's a little bit more effort, but in the long run, it's worth it, right?
Richard Feldman: I would take that on a case by case basis. I mean, certainly some packages that I get, you know, are really valuable. But, yes, definitely there's a cultural difference. Where in Elm, I think, you don't get this micro package thing that you see in the MPM ecosystem where people write left-pad being the most famous example of that. Where you have this, like, it's like a one-liner. Someone made a package out of that. It doesn't really happen in Elm, at least not from what I've seen. And, yes, I appreciate that. If it's just a one-liner, I'd kind of rather write it myself and not have this ballooning explosion of dependencies. I don't know if we've quite crossed it yet, but we're very close to 400,000 lines of Elm code at work. And we still have under 100 total dependencies, like, direct dependencies as well as their dependencies. Like, if you add up all the dependencies we download on a clean build, it's less than 100. I think that's normal for Elm. You don't really see that same explosion of dependencies which is kind of funny because considering you've got Elms dead code elimination that's just, like, so much better than what's possible in JavaScript. You would think the downside of getting more packages would be less. Like, because you don't pay for it in terms of compiled asset size. And yet we have that great benefit as well as not having to deal with, like, mental complexity of having so many dependencies to keep up with.
Key Takeaway no 1
"Elm is an escape from the complexity of the Javascript ecosystem, having a significantly lower number of dependencies."
Why does Elm seem so hard for beginners?
Thomas Angarius: I think it might also be one of the things that's a little bit scary about Elm for new people. Like, I often encounter people when they're just starting out, like, why is everything so hard? Of course, I don't think they're so hard.
Richard Feldman: If something's new, then, you know, of course, it's unfamiliar. It's by definition harder than what you were doing before.
Thomas Angarius: Yes, but I think there's more than that though, right? Elm is a very, as I said before, opinionated in how it does things. And it's very restrictive. You can't just go out and touch the DOM, right?
Richard Feldman: True.
Thomas Angarius: And, like, you're used to in JavaScript. So, hitting these roadblocks, I think, is a source of frustration for people because you don't understand it, right, as you said.
Richard Feldman: Sure. That's kind of one of the motivations for writing the book is giving people, beginners, in particular, a way to understand how to not just learn the syntax of the language and the concepts behind it, but actually, learn how to build things with it. Because, as you said, I mean, it is different from, you know, what you're used to for if you're coming from a JavaScript background. And hopefully, the book has made it easier. At least that's the feedback I've been getting.
Thomas Angarius: So, in the book, you take people from learning the basic syntax, because it is not a seed family language, right? So, the syntax is quite, some would say exotic, some would say arching to what people are used to. And that can definitely be a factor as well.
Richard Feldman: I think it depends on your background.
Thomas Angarius: It's such a simple language at the same time, right?
Richard Feldman: It is. I would say the syntax is closer to Python than JavaScript, but it's also not quite the same as Python either, in the sense that you have fewer parentheses, for example, than you do in JavaScript or maybe even Ruby actually. But there are definitely differences. I've taught Elm workshops as well as, like, online courses for front-end masters and the book and it seems to me based on my workshop teaching experience that syntax is actually the quickest thing that people get used to.
Thomas Angarius: Oh yes, exactly. More of the way of interacting. That's what I meant, right? That you don't get to go out and touch the DOM. You do things in a very strict manner and very strict order.
Richard Feldman: And I think before React got really popular… Like, the virtual DOM thing was a very unusual thing. I think now people are more familiar with that and maybe even that's the most common thing, I would say that the people are used to it. But, yes, like you said the difference is that that's all you've got, right? That's the only way to do things. There is no, like, alternative fallback. Oh, let me just reach out and you take this one thing. Yes, you can do that with JavaScript Interop but that's not until, what, chapter 5, I want to say in the book. Like, halfway through. But, yes, that's considered very normal in JavaScript to be able to do that whenever you want. And in Elm, that's very advanced… you need to learn several different techniques before you can do something like that. And it's of course strongly discouraged. It's not, like, the language doesn't want you to do that. The language really wants you to buy into the virtual DOM concept and use that as your exclusive way of rendering things. But, if you do, you get all sorts of benefits. So, yes, like you said it's, like, restrictive but there's a lot of benefits that come from those restrictions. They're not sort of arbitrary restrictions. They're restrictions on a very good purpose.
Thomas Angarius: Right. It's about getting people to appreciate what those benefits give you, right?
Richard Feldman: Totally, yes.
Thomas Angarius: Which is hard to see when you're just starting out.
Richard Feldman: True.
Key Takeaway no 2
"The book teaches you the language syntax by focusing on building things. "
Benefits of using Elm in a large organization
Thomas Angarius: When you reach a certain size, like at Humio, we're a lot of developers on a big codebase and I'm never afraid of breaking the codebase because I trust in the compiler. If it compiles it works. And that's a feeling, a sense of security you don't really see even in other strongly typed languages. Because they allow you to escape that safety, right?
Richard Feldman: Right, right.
Thomas Angarius: Elm really does not.
Richard Feldman: Yes, people ask me what's the difference between Elm and TypeScript? Is Elm a typed language? Well, TypeScript has types. What's the difference? And one of the easiest differences to point to and maybe the biggest one is any. In TypeScript, you have any, which is the escape hatch that means that any possible types could be alive. It's not achievable to have the same level of trust in TypeScript as you do in Elm. And that sounds like kind of an abstract thing. But, as you said, I mean the real benefit there is this feeling of invincibility of “I can make whatever change I want and once I get it to compile again,” it's probably going to work again. And I've gotten so spoiled by that. As you said, we have this huge codebase and we just make big changes to it whenever we want to. If we think that the code's going to be better if we reorganize it in a particular way, we just do it and then we follow the compilers until it works again.
And usually, we don't even need to change tests unless, you know, there are also corresponding type errors in the test. But it's not like we need to lean on handwritten tests to give us that same confidence. We do have tests, too but the compiler is 90% of what's getting us back there and we didn't even have to write that code. You know, the compiler just did it for us just because we were using Elm. And the amount of code cleanup that we can do so much faster has really been for me just something I can't imagine giving up again. The ability to just say I want to clean my code up in this way, I'll just do it and it'll be fine. Whereas even in other typed languages that I've used, in a lot of cases I'm, like, "Well, if I change it is it going to work again afterward? Am I going to cause a bunch of regressions?" I just never have that fear in Elm.
Thomas Angarius: Especially when it's someone else's code, right?
Richard Feldman: Oh yes, absolutely, right. We have almost 100 employees at NoRedInk where I work. That's not a huge number of people. There are obviously companies with thousands and thousands of employees. But, I don't know if any of my coworkers are even aware of the code that I'm writing, and I may not be aware of the code that they're writing. There are parts of the codebase that I haven't ever seen before. Maybe somebody is writing it while I'm having this conversation.
Key Takeaway no 3
"The compiler ensures that no one breaks the code base, which is a great help in large development teams."
Benefits of functional languages
Thomas Angarius: That's a good point. In functional languages, one of the key differences I think is that what you see is what you get. What you're looking at right now is what's going to happen, right. You shouldn't be afraid of changing something in the invoicing part of the code and it all of a sudden breaks the carousel on the front page, right?
Richard Feldman: Right, right.
Thomas Angarius: Because of side effects. Because there are none when everything is a pure function, right. That is such a game-changer for large codebases, I think.
Richard Feldman: Absolutely. I usually don't mention that one when people ask about the difference between Elm and TypeScript because it's a little bit harder to explain. But, yes, I really felt that one when I have been comparing Elm and Rust. So, I've been spending time with Rust as well. I like it a lot. There's a lot of great things about Rust. But, the refactoring ability is just not on the same level as what I get in Elm. And, it's like you said, it's because of the side effects and mutation. Rust even has a first-class concept of mutation tracking and they don't have any which TypeScript does. And it was a typed language from day one. So, like, the whole ecosystem is, you know, typed.
So, in those ways, I would say Rust typed system is a lot more reliable to me than TypeScript's, but even with that, I've still had bugs where I took some Rust code, and I just habitually, because I can do this in Elm without any concern, I'll just rearrange the order in which things are happening. I'm, like, "Oh, actually, I think it makes more sense to, like, call this and then call this and then call this." Or I did some other refactor that resulted in code being in different places and it didn't work anymore afterward. It was broken. I was like, "Why? How could this have broken?" Because in Elm, you know, as you said, when you have the guarantee that functions don't have side-effects you really can just rearrange them however you want to make the code nicer and really have the full expectation that it's going to work again afterward. But even in Rust, that has not been true for me. I've definitely broken stuff just by reordering it. Whereas in Elm, you say let's reorder it. It's fine. If it compiles again, it's going to work. And it almost always does to almost a shocking degree. I mean, it's really ridiculous.
Thomas Angarius: You can still code the wrong thing, right. You can still code the wrong thing.
Richard Feldman: Of course, yes. It's not 100%. It's not possible to guarantee that if it compiles it just works. But it is just ridiculous how often it is. I mean, it's certainly most of the time. And it's, like, I don't know what exact percentage, but it feels like it's, like, in the 80% plus range. That, when it compiles I just expect it to work. And if it doesn't work I'm very surprised. I'm, like, "What happened? How did this compile and then not work?" Which is a hard feeling to convey because it sounds so ridiculous at face value. I mean, if you spend a lot of time programming in other languages that's not normal.
Key Takeaway no 4
"Functions done right don't have side effects. If it compiles, expect it to work. "
Elm is more than just a cutting-edge programming language, it’s a chance to upgrade the way you think about building web applications. Once you get comfortable with Elm’s refreshingly different approach to application development, you’ll be working with a clean syntax, dependable libraries and a delightful compiler that essentially eliminates runtime exceptions. Elm compiles to JavaScript, so your code runs in any browser, and Elm’s best-in-class rendering speed will knock your socks off. Let’s get started!
Elm CSS
Thomas Angarius: One of the interesting things is that for our application whenever we have bugs, it's usually due to CSS because we don't use Elm-CSS. Maybe you can talk a little bit about what that is?
Richard Feldman: Oh sure. Elm-CSS is a library that I made. We use it at work. Although, honestly, I feel like every time I bring up Elm-CSS I need to make a plug for Elm-UI which I kind of wish we were using at work except that we just have so much legacy CSS it would be a really big project to convert to it. But, Elm-UI is one of the most beloved and, like most popular Elm packages, it was made by Matt Griffith and basically, it's a CSS alternative. Where, basically, it's a way to do layout in the browser without even knowing CSS. Like, you don't have to know any CSS concepts. No flexbox, no grid, no float, no any of that. It's just a complete ground up, a scratch rewrite of, like, a layout system that works in the browser.
And the way that it works is, of course, that it behind-the-scenes compiles to CSS in the same way the Elm compiles to JavaScript. But, the point is it has a completely unrelated set of primitives. And, so, some of the funny things are, like, I saw actually on Elm discourse, I think it was yesterday somebody posted, like, "Hey, I'm entering the job market." And one of the concerns that they listed was, "I got into front-end web development and I'm learning Elm. And I know Elm-UI, but I don't really know CSS and I'm kind of concerned that it's making it difficult for me to get a front-end job." Because most places, you know, do use CSS. But, I love that implication. If you know Elm-UI, CSS is a lot harder.
But because we had a big React codebase before we started using Elm, we have Legacy CSS and, so, we sort of incrementally moved that over to Elm-CSS. It was originally styled-components, I think was the one in React. But, I think there are new names for it now. I think there's one that more closely resembles the Elm-CSS-UI or API. But, I forget what it's called. I want to say it's Emotion, but I might be misremembering that. I've been kind of out of the JS world for so long. I don't know the names of things anymore. But, the basic idea is that it gives you a way to do type-checked CSS in your front-end code, and also you don't need to have a separate style sheet.
So, I can basically just add an attribute to any of my HTML values, any of my elements that just have CSS, and then the CSS attribute takes a list of typed CSS properties. So, for example, if I want my button to have a one-pixel border, I can just say CSS and then square brackets, because you give it a list of all the attributes that you want. And I just say, like, you know, border one pixel solid, blah, blah, blah. And if I mess that up, like, if I mistype something in there then I'll get an error in compile time. And then it behind the scenes will automatically generate a class and then it's, like, a hash of all the styles in there and reference that and so on and so forth.
So, yes, it makes things a lot easier, but it is at the end of the day still fundamentally CSS. So, it's sort of a way to make CSS nicer. I counted it at some point. It's like 600 and some odd different typed CSS properties in there. So, it's not the entire 100% of the CSS spec, but, you know, it's a lot. And, yet, you know, I also think it's funny, whenever I see people complain about TypeScript compile times, I'm like, what's that? What's a long compile time?
Thomas Angarius: It's funny you said that because of one of the reasons, we went to have everything in Elm which is quite a big benefit, right? Thinking about your application is not just the behavior, but also the way it looks. Because you can't really separate the two, right, in a web application. But, at the time, which is now several years ago, the compile times were so excruciating long that it just wasn't feasible to, you know, when you want it to say how does this look when it has a rounded corner and you have to wait 80 seconds or something like that when you get to a certain size, right.
Richard Feldman: Yes, like, 2017 Elm compile times were not great. I think that was, like, everyone's favorite release of, like, the people who are using Elm today, but who were also using it in, like, 2017. Like, the one that just made the compiler ridiculously fast. Yes, that was a total game-changer.
Thomas Angarius: We went from, like, 2.8 minutes to 4 seconds.
Richard Feldman: Right, and that's, like, a scratch-build, right? The entire codebase in four seconds.. Because, like, incremental compile times are usually sub-second, but that was a nice release. Although, I guess, you know, getting back to the book, the amount of code that you end up writing in the book, even though it is one application, like, starting in… So, chapters 2 through 8 are all about building one application. So, like, chapter 1 is just basic syntax, but then throughout the rest of the book it's all about building an application from start to finish and then each chapter, like at the beginning, you get sort of feature requests from your manager. Then you implement that feature request over the course of the chapter. In the course of implementing that feature, you learn about the concepts necessary to do that. The entire time, I think, I guess I haven't tried it on, like, a Chromebook, but I would expect that all the compile times throughout the entire book would be less than a second. I would be surprised if someone's machine took more than a second to compile something.
Key Takeaway no 5
"Elm UI is one of the most beloved and most popular Elm packages. It is a way to do layout in the browser without even knowing CSS."
What does the book "Elm in Action" help you with?
Thomas Angarius: It's one thing that struck me about the book is that it really is a journey from absolute novice to being able to write a fully-fledged single page application, right, where you even cover things like web components and stuff like that. Could you talk a little bit about that, maybe? Like, what you said before is using JavaScript, and so on is a big no no, you know. Or at least you're discouraged from doing that.
Richard Feldman: It's discouraged, yes.
Thomas Angarius: Why do you do it? We do it as well. Anyway, at and outside work.
Richard Feldman: Yes. Elm has JavaScript Interop, but it's, generally speaking, it's a fallback. It's not intended to be something that you use all the time. It's just, like, you know, if there's something that you need, like, there's a particular… Like, there's one very specific JavaScript library and there's no Elm equivalent library of that thing. If the alternative is, like, well we'd have to write this whole thing from scratch in Elm or maybe it's something where Elm doesn't have first-class support for that, like, WebRTC or something like that, then, yes, you do JavaScript Interop for that. But the idea is that most people want to have a ratio of, like, 99.9% Elm to, like, 0.1% JavaScript in their codebase or TypeScript or whatever it is. It's not, like, you have, oh it's 70-30 Elm, JavaScript. It's, like, no, no, no. It's just…
Thomas Angarius: It's very much like that for us as well. There are some things that we use JavaScript Interop. We are a log aggregation management platform, right. We visualize people's logs. So, we have live charts and things like that. And Elm didn't have, like, a fully-featured, rich-featured chartering library. So, what we could do then is use a web component and just flop things in there and just wrap this little web component as like a micro-application running inside of Elm and talk to that through a type-safe API. This fits in perfectly with Elm or as close as you can get to it without breaking the model.
Richard Feldman: Yes, totally. The analogy I like to use is that talking to JavaScript is like talking to a server in a sense that you're sending immutable data, just sending messages, you know, back and forth.
Thomas Angarius: Yes, it's very much that feeling.
Richard Feldman: Yes. And, so, it's actually why the chapters are titled that way. So, I think chapter 4 is called Talking to Servers and then chapter 5 is Talking to JavaScript. And the reason the chapter titles are that way is because they're so similar. So, you learn the concepts of how to talk to a server and then the next chapter it's, like, okay, now we're going to do a very similar thing except instead we're talking to JavaScript back and forth. I guess that's how it is with ports. But then with web components, I've talked to people and I know people on, like, the React support team and view core team, Angular and Ember, and when I've talked to them about web components it seems like Elm users might be the biggest customers of web components or at least specifically custom elements and specifically just for JavaScript Interop because they're so convenient for that. Because in that case, if you're rendering something and you want to be, like, oh I want to take this JavaScript widget of some sort. Like, I have, I don't know, like, an embedded calendar or something that I really like. There are Elm visualization libraries. They're a lot more robust now than they were in 2017.
And then there's also, like, calendar date picker type things. But let's say there's some JavaScript thing that you really want… Oh, Google Maps, that's a good example. There definitely is not, you know, Elm… I can't imagine anyone ever going to all the trouble of, like, doing an embedded Google Maps in pure Elm, that would be very impressive. Actually, I think, there was an Elm Europe talk a couple of years ago about doing, like, a pan-and-zoom type map. But it's not, like, the full-featured, you know, map thing. But if you want to embed one of those, yes, I mean the way that I would do that is with a custom element. It's really convenient for that. The book goes into how to do that.
I used both a custom element and also ports in the JavaScript Interop chapter because I think they're both useful techniques to use. Like, you use them for different things. Like, custom elements are more for visual things, whereas if you need to just talk to a JavaScript library it's going to do some calculations or whatever or some sort of a… Like, a common thing that people will do is if they've got, like, an analytics provider, like, Rollbar or Bugsnag or something like that, that provider will provide some JavaScript library that just automatically does all the correct talking to their server thing, then people will just talk to that and out of a JavaScript port rather than writing an Elm specific wrapper. Like, there's a couple of wrappers, like, entirely Elm wrappers for like, Bugsnag and Rollbar. There's a lot of services out there. So, they probably don't all have pure Elm implementations.
Key Takeaway no 6
"The book is one big hands-on example of building a complete application from start to finish. "
Modeling with the Elm Programming Language
Thomas Angarius: One of the biggest takeaways, I think, that I have from using Elm: if I were to never touch Elm again, and I still think I've benefited from being an Elm developer because, the focus or the way that I write Elm is that I start by modeling things, right. Really modeling the problem. And I don't think that I've ever done that in any other language or platform. And I wonder whether that's because of necessity or because… why that is?
Richard Feldman: That's a good point. Yes. Just like getting the data model right. Getting the data, yes.
Thomas Angarius: Like, in Elm, it is so beneficial to, you know, the famous phrase, "To make illegal state unrepresentable." But it's not just for Elm, right. It's something that… go into Java and you can do exactly the same thing and get exactly the same benefits. But, you just don't feel the pain as much if you don't do it. And I think that's because in Elm you have to handle every contingency. If your model allows you to both have a field that says that you got a server error in it, and another where it says, here's the successful data. Like, those two are incompatible.
Richard Feldman: Well, you've got to remember to handle the failure possibility.
Thomas Angarius: But if you have both of them, you deal with them being there.
Richard Feldman: Right. I think it's because the compiler tells you about edge cases. It's not, like, you find out about them, you know, way after the fact after it's, like, a bug report. You find out about it when the compiler tells you you didn't cover this case. Then, yes, I totally agree. I would say Rust is maybe the only other language where I've done that because Rust and Elm have similar typed system capabilities in terms of sum types and product types. But, yes, it's definitely changed the way that I've thought about programming, like, for the better. I definitely think that the way that I write Elm code is just more robust and better. The language sort of guided me to do that. I think that was just like a cultural phenomenon that people just decided to do. The experience of using the language just makes me move in that direction and it's a good direction, yes.
Key Takeaway no 7
Elm has changed the way I thought about programming, for the better. Even if I wouldn't touch Elm again I still think I would have benefited from being an Elm developer.
Preben Thorø: Thank you both for the conversation.
Richard Feldman: Thank you for the invitation.
Thomas Angarius: Thank you.
Summary of the main takeaways
- Elm is an escape from the complexity of the Javascript ecosystem, having a significantly lower number of dependencies
- The book teaches you the language syntax by focusing on building things
- The compiler ensures that no one breaks the code base, which is a great help in large development teams
- Functions done right don't have side effects. If it compiles, expect it to work.
- Richard Feldman's Elm UI is one of the most beloved and most popular Elm packages. It is a way to do layout in the browser without even knowing CSS
- The book is one big hands-on example building a complete application from start to finish
- Elm has changed the way I thought about programming, for the better. Even if I wouldn't touch Elm again I still think I would have benefited from being an Elm developer"
Elm is more than just a cutting-edge programming language, it’s a chance to upgrade the way you think about building web applications. Once you get comfortable with Elm’s refreshingly different approach to application development, you’ll be working with a clean syntax, dependable libraries and a delightful compiler that essentially eliminates runtime exceptions. Elm compiles to JavaScript, so your code runs in any browser, and Elm’s best-in-class rendering speed will knock your socks off. Let’s get started!
About the author
Richard Feldman is the author of Elm in Action from Manning Publications and the instructor for the front-end masters 2-day Elm workshop. When he’s not writing about Elm, teaching Elm, speaking about Elm or co-hosting the San Francisco Elm meetup, he likes to take a break from his job of writing Elm code full-time as an engineer at NoRedInk by kicking back and working on some of his open-source Elm projects. Some have said he’s “into Elm,” but he’s not sure where they got that wild idea.
Thomas Angarius is the Principal Engineer at Humio and has been rocking Elm since 2016.
This episode of the GOTO Book Club was possible thanks to the support of Humio, the only multitenant solution that enables organizations log everything to answer anything in real-time — at scale, self-hosted, or SaaS. Humio’s modern architecture enables complete observability to answer any question, explore threats and vulnerabilities, and gain valuable insights from all your logs in real-time. Humio’s front end is developed in Elm, a functional language selected for its strong emphasis on simplicity, stability, and speed, which are all important capabilities in working with large data volumes in real-time and with high user interactions where data is being continuously explored. Humio offers low total cost of ownership and unlimited plans, with easy deployment at any scale, self-hosted, or SaaS.
Learn more about Humio from Kresten Krab Thorup, CTO of Humio
About the speakers
Functional programming language expert & author of “Elm in Action”