Welcome to the Ruby Roags. My name is John Epperson. And on our panel today we have Luke Stutters.
Hello.
And for our guests today, we have Richard Fellman.
Richard, Richard, we've had you on the panel before.
I was not here. I was listening to the podcast at this time. It was quite a while ago. I believe Oddy was still on who.
I don't remember who else would have been there.
Looks like, according to the pics Chuck and Evan, Jessica Kurt's time. I actually don't remember how to pronounce her last name. It was Okay here too. It was like kind I used to work together.
And as I recall, it's a long time ago, I think she introduced herself to me as care like care bear, So I think that's how it's pronounced, which I'll correct.
Remember that now that I think about it. I remember hearing that okay, fair enough. Wow, I can't believe it. I didn't even recognize that, sorry, Jessica. Yeah, so welcome, welcome again. And I remember listening to this particular podcast. Actually, I remember being very excited about ELM, and ELM is one of the many things over the years that I was like, I'm going to do that thing, and I didn't do it, so I'm excited to hear how it's
changed and different. It also sounds like you, or I mean, sounds like you did release a book, so we can talk about that too, I guess maybe to get us into this, why don't you talk about what the I don't know what the goal of your book was, and like, why did you release it?
Why'd you write it? Yeah?
Sure, So the main goal of the book is to help people who have never done anything with ELM or anything with functional programming of any sort, learn ELM from scratch and basically be able to build applications at ELM. One of my big goals for writing the book is that when I was first getting into like functional programming languages, especially typed functional programming languages, I found that a lot of the books, actually really all the books I could
find at the time, were just really really refocused. They would talk about a lot about like philosophy, and they use the phrase reason about a lot, and I just don't work that way. I like to build stuff, and so I wanted to write a book for people who like to build stuff like me. So that's what the book is it's a way to learn by building stuff. So over the course of the book, starting from chapter two, like chapter one is basically like syntax and stuff like that,
and you know, kind of stuff you need. Starting from chapter two, for the rest of the book, you're working on building a sort of a photo browsing application. And each chapter it's like you get a new a new feature to build from your fictitious manager and you build it, and then over the course of the chapter, while you're building it, you learn some new concept in language, like testing or you know something like that.
It sounds very it sounds very Real's esque, right, like get your do your iterative thing, get your small victory, move on to the next step.
Could Yeah, it's it's definitely like. It was a real challenge to write the book in that style. I at first I was like, man, why is it everybody wat a book like this? And by the end I was like, oh, now I know, because it turns out to be a big challenge to get everything to sort of pull together in that way, because it's not just that you're like, of course, I need to build the application myself so that I can, you know, go back and build it up.
Chapter by chapter.
But then whenever I would discover oh wait a minute, I need to teach this chapter this concept a little bit earlier, a little bit later, then I'd have to go revise the application and then also go sort of propagate that change through all the chapters that were affected. So revisions took a lot longer than I was hoping for upfront. Totally fair, That makes a lot of sense. Well, I'm really happy with how it turned out. I mean,
it ends up. Yeah, you do actually build an application from start to finish and learn about the language along the way.
So how how do you recommend using ELM? Do you see ELM as a thing that lives alongside rails in our stack?
Is it?
Is it really a separate thing that we should we should we should pick this tool off the shelf when we're approaching certain kinds of problems and leave rails, you know, for the instead, or yeah, how do you see these things living?
Yeah? Great question.
So, I mean the way that we use it at work, like very specifically, is we have rails on the back end for most of our back end at this point, and then on each individual page, what we do is instead of loading some compiled JavaScript, we load some compiled ELM instead. So basically, anytime you're doing what I would call a web application, whether that's a single page app or just something that has a lot of complicated front
end logic, I think that's where elms are really good fit. Conversely, if you have just kind of a tiny little bit of JavaScript that's just kind of like augmenting what's primarily HTML on the page, I don't think it's worth it to go like all the way to ELM. You're not really going to get the benefit of using a whole different language unless you have a lot of complexity.
There, all right, So we can throw away our React and things like that in exchange for out.
That's what we did at work.
Yeah, so literally we started from Reacting and migrated things to ELM. Eventually, I guess it's more accurate to say that ELM took over. Technically, we still have some ancient React in there. It's like react o dot twelve, I think, because we just haven't it's been that long since we wrote any new React code.
That's fair.
Yeah, I was it like duff, I don't know whatever somewhere in there React change and then I went from being very excited about it to not not being as big of a fan.
So how do you feel about this? All? Right?
So, so stimulus is kind of a thing in the reals community right now and with a good amount of popularity. I don't know, I don't know how popular it is. I like it, but how does it compare with things like that? How do you pick or are you just committed to ELM and so you really haven't you know, put it's on a comparative time in.
Yeah, I mean, to be honest, I mean we've been so happy with ELM that we definitely have not really like reconsidered that choice. The way that I see it is it's it's kind of like the big question is sort of ELM versus JavaScript as a whole, because they're very different languages. I mean, they've both sort of solved the same problem, but they come at it from pretty different angles. And so from our perspective, like, we have a lot of people who are just really happy being
ELM programmers. And something that I've noticed is that once people get a taste of using ELM at work, it's pretty common that like the first place they go after, you know, when they're looking to move jobs is like the jobs channel on ELM Slack because they want to use ELM again rather than going back to JavaScript or type script or that whole ecosystem.
I got some dumb questions fire away. I got some dumb questions answers.
Ruby infamously has has little to know typing and an amazing imagination. What is it about front end development that seems to require some kind of typing system?
You know, I don't know that it's necessarily so much of a domain specific thing. For me personally, I would say it's more about sort of the identity of the language itself. So you can classify both Ruby and JavaScript as you know, dynamic languages, but they feel very different to use. I mean, they go about it in very different ways. And similarly, I would say that like ELM and typescript, although they're both type check languages, they feel very different to use and they go about it in
very different ways. So I don't know that it's necessarily
a front end specific thing. So Evan who was on the podcast last time, he's the guy who created ELM, and he basically when he was trying to when he created the language, it was because he had this experience where he was doing an internship at Google, and he was working on like C plus plus and Gmail or something like that, and a friend of his was doing some JavaScript stuff and he'd finished his project early and was going over to help out his friend, and he
was really surprised by just how hard it seemed to be to work in that environment relative to kind of what he assumed it would be like at a place like Google, where they just have the most investment ever in JavaScript. And what he remembered was he was like, man, I worked with some of these older languages in college, like these mL family languages that have these nice module systems and things like this and that, and it seemed like a lot of this stuff was just much easier.
So his thinking was not, you know, oh, let's add a type checker to this, because I think if he'd done that he would have ended up with something more similar to typescript or flow or you know, one of these other projects. But rather he was thinking about at the language level, I've had these really positive, nice experiences with these this other family of languages that are you know, not as popular in mainstream use. It's like, I think there'd be an opportunity to try this out in this domain.
So whether that's innate to front end or not, I don't know, but I think it's It really has more to do with like the positive feelings that people expressed about ELM, I think are similar to the positive feelings people expressed about Ruby. It's just like a joy to use. It's a delight to use the language.
That's not a very postive and uplifting story. I'm going to suggest that reality is that the web is getting is getting worse instead of better. Brownses coming left right, the center obviously iees going away, but still in other things require eleven for commercial reason. And the front end is inherently a hostile It's like a wild West atmosphere. When I'm safe on my server with my Ruby micro frameworks, all rails, no one can touch me. I control the environment.
It seems to me that on the front end, you are on the front lines. Front End development is front line development. There we go. You heard it here first. What I think, reading through and listening to Evan talked about ELM is ELM is like a shield that can protect you against the e vagarities of what can be really quite a hostile programming environment on the front end.
And let me.
Delve into some of my own front end experiences. Recently, I had to start writing complicated front ends. This is not something I've done. I've been writing very simple front ends with a business logic in the back and maybe you just have to hit a button or you can do everything separate pages as fine. But you know, as as it turns out, I do have to write some fairly complicated almost desktop app like Interphasis now for sure.
And I looked at Stimulus, but I've been using Voo to do my front end development, and I get errors left, right and center. I get more errors from food and I have from any any other language, any other programming environment. It really really likes to blow up, and it's very much a sun death situation. One error in my Voo
code will take out the whole page. So I would be interested, very interested in a front end where I don't have that concern that the app's going to blow up for someone on some browser and then they just dead. The single page app stops working and I've lost that business.
Yeah, I mean that's we were using ELM with Internet Explorer nine for many years, so that's certainly not a concern. And also I mean, if an ELM app's going to blow up, it's going to be you get a compile error. We actually went almost two years before we got our first runtime era that was logged like our production server like logged a runtime exception. It's just I mean, it can't happen. Actually, the particularly one that we ran into them was then fixed in the next release of ELMS,
so that couldn't happen anymore. But that's really kind of ELM's goal is that if something bad's going to happen, it's going to happen on your local development machine at compile time, not at run time where it can affect your users.
And it really delivers on that.
We still have like JavaScript blogging, you know, enabled unproduction and yeah, the number of runtime exceptions we get from our JavaScript you know, we still have some legacy JS, even though now it's we have like four hundred thousand lines of ELM code. This is at no rid ink, by the way, where we mixed up for software for English teachers, so students and teachers. We have like millions of users, you know, very high traffic, lots of different devices.
By the way, we're hiring full stack engineers and also sr and tooling engineers. If you're interested in working with ELM at work, that's no redink dot com slash jobs. But I mean what we've seen over the years, and we've been using ELM since twenty fifteen. Actually, I think on that podcast we were relatively new to using it at the time, but now we've had, you know, a lot of experience under our bills. We're way past the
honeymoon phase and we still love it. And part of the reason is just yeah, I mean we get to see every day in our error reports, you know, on bugsnag, just how many exceptions our JavaScript code from you know, twenty fourteen is still throwing that we haven't you know, gone back and deleted or rewritten in ELM and our
ELM code just you know, just plowing along doing well. Yeah, it feels kind of surreal almost to be to be honest, I had never thought that, like, prior to using ELM, that would something you could get in the browser, because yeah, I mean, as you said, there's it's a bit of a it can feel like a hostile environment in some ways, especially to doing really complex things, because let's face it, that's not what jobst was designed for It was designed for really small scripts, and the way that we use
it is to basically build desktop applications that have to be streamed over the internet and used, you know, immediately, not what it was designed for. But but yeah, ELM does do a really good job of presenting something that's much nicer than it's a much nicer interface to the browser.
It is different.
I mean it would sort of have to be, right, I mean, it would be weird if you could have something that was both familiar and much better. At some point, in order to be significantly better, you've got to be different, so, you know, hence why there are many of us out there writing things like books and tutorials and things like.
That to help people learn it. How is it to get up and running for Rails developer? So how difficult or easy? Good?
Yeah?
I man, I think it was since Rails five you've been able to use it out the box with sprockets. Don't quote me on that because we actually have a different build syst and we used to use it with sprockets, but now we do our own thing. But yeah, I mean, I guess it's been a long time since I set it up from scratch, so I but I believe it should be straightforward.
Fair enough.
I mean, I guess wrong person to ask, since you're like, yeah, I've lived with it for forever, I don't remember.
What I did.
Yeah, I mean back back, admittedly back in twenty fifteen, when it was like the early days. Yeah it was you know, you had to do custom stuff to set it up. But I don't believe that's true anymore.
Yeah.
I looked up a couple of things, and it does look like it works with like webpacker now and some things. I mean, there's a gem out there to get it started. I don't fair enough. I mean, I actually the gem actually now that I'm looking at is no reading slash and umbnails. So I assume that you guys are involved in that somewhat. Yep, that's the same suction. Fair enough? So yeah, all right, cool? So, I mean there's some stuff out there. You haven't touched it in a while,
so you don't remember how hard it is. But fair enough.
But I do remember, specifically hearing that it got easier since we originally set it up.
So yeah, all right, close enough? Sweet? So why oh go ahead, Luke.
Can I ask you about service side?
Rendering.
Sure, so service side rendering is a thing that is not supported out the box. It is something that you can get with like a third party module. That's not something we do at work, but I know that's like a use case that some people care about and have done. I don't know how it integrates with RAILS though, because, like I said, we don't personally use it at work.
Thank you.
It's not people who kind of start in Ruby. They start service side first. That's what you get. Yeah, yeah, and they transition to a client side rendered model, which is one I went through and learning food was quite drastic. You know, you really you really do have to reorganize things and the way you think them did. Do you think of ELM as a client side framework?
Oh? Yeah, absolutely.
I mean, like I said, I think if it is, you know, if I'm building something complex, I want ELM to help me with that. If I'm building something where the client side interaction is really simple, I just wouldn't bother with any you know, compile the JAS technology. I probably wouldn't even you know, bother with a JS framework. I just write plain old JAS.
You know.
If I'm talking to just a handful of lines here, just to you know, wire a button up to do something you know, slightly unusual. That's kind of what jobscript was originally designed for. And I think it's you know, it's it's probably not worth the hassle of doing anything custom at the build level if you if you know it's going to be really small. But on the other hand, a lot of times you know it's going to be something really big and complex. And I think that's where ELM shines.
Yeah, I feel like we're kind of like past the stage right where we only write small stuff. Literally, I mean, shoot these small projects that I don't think I'm writing much JS on, Suddenly I have ten JSS files like and I was, I was just like, this is a simple app.
Like what happened in this way?
It works well, you know, I mean to A counterpoint to that is recently I was writing a documentation generator and that is something where you know, I mean, it is almost all static HTML. And I actually tried to have a goal of I was like, let's see if I can make this work even if someone has JavaScript disabled. And I was able to do it with absolutely everything except for I wanted to have a little search box that would filter things like as you typed into it.
So I basically made it so that search box only appears if you have JavaScript enabled and then everything else. But I mean the whole all the JavaScript code on that page, you know, fits on one screen. I don't even have to use a scroll bar, right, So yeah, I didn't bother with a build step for that.
Nice. Yeah.
And I think one thing that I would throw into the ring is I definitely have gotten a lot of for the low JS code sites, right, Like I've gotten a ton of workout of Stimulus, So that's been great too. So talk to me about why I should pick ELM, Like what maybe what the right use case would be for for somebody that's considering it, and maybe.
A wrong case if you're aware of that. I mean, I think the main use case is just you have an application that's, like Luke said, something that's basically a desktop app in the browser, something that's like gonna be pretty complex, and so some here are some I don't know, interesting facts about ELM. If you look at JS framework benchmarks and you put ELM into those benchmarks, ELM does extremely well in those benchmarks, Like it's really fast generally speaking,
outperforms react outperforms view. I think there's like one benchmark where like the latest Angular outperformed it in one of the like micro benchmarks, and all the others Elms faster than it. So it's it's it's it runs really fast. Also, compiled asset size, it's basically smaller than anything but swelt Felt. I mean, okay, it's hard to beat Spelt because it's like that's their whole point, that's what it was built for.
But generally speaking, in terms of compiled asset size, ELM is smaller than everything Butt svelt for like real world.
Applications, And.
Yeah, it's it's just the output that you get is very high quality. And then also the experience of building the application is that it just feels really nice and everything's like works really reliably. One of the biggest things that I think for me, that I love about ELM is that the ecosystem is totally separate. Like for our front end, except for our legacy JS stuff, we don't
use NPM. We just use ELM's package system. And the really critical difference there is that everything in the ELM package ecosystem is one hundred percent l It's just all built on this same set of shared primitives, this sort of different foundational api of how to interact with the browser, which means that we don't get these like you know errors sort of sneaking into our system and like oh, this library had an incompatibility with that library and they
were one of them was you know, doing something that it shouldn't have been doing. It's like, no, they all play by the same rules. A way of thinking of this is it's like, well, imagine if javas started with typescript in e S six in twenty twenty rather than in you know, the nineties. You know, how much better would people have? How much better of an ecosystem would people have made with the benefit of hindsight and with also without having to do all these backwards compatibility hacks
for old hacks that people used to do previously. And in a lot of ways, ELM is sort of the result of like that plus sort of going even further and saying, what if we didn't even need to take JavaScript as a language as the foundation, and somewhat miraculously there there actually is an ecosystem there. You know, it's obviously it's not as big as NPM because no ecosystem is as big as NPM. But I mean if you go to package dot, ELM, dash Lang, dot Org, I
mean you can just browse through these packages. There's a ton of packages and they're all they're nice things like semantic versioning is actually enforced. So what that means is if I go to publish a package and I'm going to actually delete this function I decided it was a bad idea, I'm going to take it out. If I don't bump the major version number, the package manager will actually reject that and it'll say, no, no, that's a breaking change. You have to bump the major version number
for breaking change. So and there are other you know, things that clearly will break.
Compatibility that it'll do that for.
So when I get a package from ELM package, I know that I'm going to have this really nice upgrading experience. And to be honest, I feel pretty spoiled by that because every time I like, I still use NPM for like some side projects like command line tools and stuff, and whenever I go to upgrade, like immediately like five things break. I pray my packages. I'm just used to
things breaking, but an ailment's opposite. Whenever I upgrade my packages I expect unless there are major version bumps, in which case, you know, I expect to have to make some changes. If it's all minor and patch versions, I'm just like, yeah, just upgrade, and then I expect everything to just still work perfectly. And that's normally what I get. I mean, of course bugs can happen, but but yeah, I mean certainly I expect everything to compile again, and that that has always been true.
It's pretty nice. It does sound very nice. I think my experience rail sits somewhere in between where most people most of the time do a great job and then occasionally you just get completely surprised and bit but yeah, so yeah, yeah, okay, so maybe okay, So ELM is is faster, it's you know, smaller.
You love your experience in ELM. The compiler runs faster than typescript. Too fair in the experience of people who use both what about the wood the F word? The F would I only know one F word you might be referring to, And I'm not sure how it pertains to our technical discussions.
ELM.
ELM is functional. Oh functional programming.
Yeah, now, this is this is something I've seen a bit about that was longer than what I was thinking of. Yeah, right, I didn't say it was a full a lot of word, but it is the threat, and it was on.
My list of things to ask and I didn't. I didn't recognize that.
Yeah, yeah, go ahead.
Back in the day, hack and years was full of stuff on a Haskel and it just used to make me angry and confused. And I genuine believe that Haskell has probably set functional programming back twenty years.
You know, you might be right about that.
To be honest, that's a don't don't at me.
Well, I mean, that's a that's a controversial statement to make in the functional programming community, but I think I could be more nuanced about it than that, which.
Is let me let me just say that I feel off put off by the fact that says it's functional. This fills me with fear to see that, just to see the F word in a language.
I know I'm wrong. I believe that the ELM does.
Provide a speriod development experience, and Mike, you said if it didn't, people wouldn't be applying for jobs doing it, so I totally believe you.
Well, check it out, go to ELM dash lang dot org and and you'll see that it doesn't self describe as a functional language. It uses a different word. What's the would a delightful language? Ah, because that's what it's about, right, It does sound at friendly and like, yes, technically if you go to Wikipedia, it's classified as a functional language, but that's really not a big as big a part of ELM's identity as being a language that's really user friendly.
It's really uh. I think just because you know, the languages that Evan used were functional languages. You know that that he said, hey, that I had a better experience in college using these sort of more obscure languages. I want to try and bring something like that, you know, to the modern world. I think it's it's more about the legacy than about trying to advance a particular like agenda or viewpoint and just finding that, you know, Evan tried to put together a language and I think he
really succeeded that. It just has a lot of really nice characteristics and a functional language is how he ended up there. But I completely understand where you're coming from. I have felt this too. When I was early on, I had a friend who was really into functional programming and who sort of would talk to me at lunch about it and really convinced me that it was worth
my while to look into. But man, when I go on Hacker News, when I when I started like watching some talks, yeah, some of them were really nice, but also some of them just felt like I just felt very inadequate, like this is.
Like some club that I didn't belong to.
And if I'm being honest, part of the way that I wrote element Action was in reaction to that. Like, I don't think that it should be that way. I think functional programming languages are languages just like you know, other paradigms, and they should you know, sort of stand and fall on their own merits, not because people are talking about them as like you know I mentioned earlier, like the phrase reason about that one really kind of bothers me because it almost seems bi implicate that, like
other languages or other paradigms are unreasonable. And I think there's plenty of ways to you know, criticize and to talk about trade offs of different languages without all the sort of like high minded like oh, this is just like innately better. I think we can get more specific and say, like, for example, like ELM programs, you know, tend not to crash. That's just like a very concrete, nice thing that we can agree is, you know, a
positive thing. I don't think we need to say like ELM programs are easier to reason about and you know, are more elegant or something like that. I just yeah, I think it's the way that functional programming languages, and in particular I think, like you said, Haskell, I think historically the way that Haskell has been talked about in Hacker News and elsewhere a lot of the time is is not really doing the people who like to use these languages any favors.
What's the ELM community like in twenty twenty you use touched briefly on how to get a job, and now where do things happen? And how does it feel to be part of the OLM community?
Great question.
So I would say the two main places that people hang out would be on ELM discourse and on ELM slack. So I can remind me I can put some links in the show notes to those. But yeah, so discourse is for sort of more long form discussions. Slack is from real time discussions. I generally recommend to people to start off with elm Slack because the Beginner's channel there is just full of really friendly, helpful people who will just answer questions in real time. It's a honestly, it's
the friendliest community I've ever been a part of. And I say that with affection for the Ruby community, but I just, I don't know, Maybe it's just the ELM community just has a special place in my heart, but I mean, everybody's just really nice and really friendly, and I don't know, I just have a lot of friends there and just think very fondly of it. When I think about what I recommend to people in terms of getting into the community, I always say ELM Slack. And
then the next place I mentioned is discourse. But that's not to say that there aren't other places, like I know there's an ELM subreddit and things like that, but I think those are kind of the two main places.
Pre pandemic a really big place.
We had an increasing number of ELM conferences, So I think back in twenty fifteen we had zero ELM conferences. In twenty nineteen we'd gotten all the way up to four different ELM conferences, and there was going to be in ELM Japan for the first time in twenty twenty, which unfortunately had to be called off along with all the other twenty twenty ELM conferences. So hopefully, knock on wood, those will be coming back after the world gets back
to normal. But I really miss it. I just have a lot of great memories of just getting to meet people in person and you know, exchange ideas and.
Yeah, awesome.
Yeah, I think not necessarily to rehash functional stuff per se. But I mean I think one of the you talked about like nice communities, right, or we were kind of talking about nice communities, and you're like, well, I love ELM even more than I like Ruby's community, right, And I think, I mean, to be frank, there's something, there's some sort of thing, right, nice communities and how you advocate for your language, you know, I think kind of go hand in hand.
Right.
I like Ruby, and I feel like not not taking my Ruby Bible so to speak, and be beating people over the head that right makes people amenable to wanting to join the Ruby community.
And I feel like I have never been browbeat by an own.
Bible, So I have a positive opinion of the ol community, right, whereas I have been smacked by the JavaScript in the Haskell two by four's you know quite a lot, right, No, so yeah, I think that makes a lot of sense. Yeah, anyway, I'm a big fan of like nice communities. Otherwise, I think we have programming, you know.
That's I think that's that's sort of the one of the changes we can be in the world, you know, Like you know, like min Swan, it's just a great you know, Matt's is nice to we are nice, Like I love that. It's it's just a great like mantra to live by, like, yeah, let's let's try to be nice to each other.
You know.
I agree so that that particular one always bothers me, not because it not because the idea bothers me, but because what happens when Matts dies or what happened if Matt's like you know, I don't know, like if something happens to Matt's and he suddenly not nice, Like we've had enough bad news in twenty twenty. All right, I'll knock up with guys. I'm not trying to suggest that this would happen. I'm just it always like worries me.
What if?
Sorry, but yeah, no, I like nice communities and I've always like it's part of the reason why, uh, for me, the Elixir community has always you know, had some sort of draw right, Like I feel like they've always tried to be like make me feel like they're going to be a nice community if I come join them.
So I think another another interesting thing, so you know, to maybe draw a bit of contrast. But I think they're sort of coming at the like, let's have a nice community from different angles. Evan has always said, like, hey, let's you know, it's great if you like el compared to you know, what you're using before, but let's not bash other languages. You know, like we can say like, hey, I prefer this, but we don't need to like talk smac about you know, whatever we were using before.
It's too late because I've done it already.
But at the same time, he also says, you know, hey, I don't want to Like people would ask like, hey, should we call ourselves Elmists or Elmer's or you know, arborists or like what what you know, what name should we use? And evyone was like, how about just ELM programmers, Because at the end of the day, it's a tool, you know, it's not It's not like we need to sign up for religion here. It's like, you know, it's okay if you like ELM for this problem, and it's
okay if you like other things for other problems. We don't need to you know, self self identify as like that strongly with this tool that we're using. And I think that sort of reminds me of it's like the opposite of the thing you were saying earlier about functional programming, Like there are definitely some people I've met who for whom it's not just a tool.
It's not just a paradigm.
It's sort of like a way of life or or like something that you know needs to be preached as opposed to just you know, I think there's an important difference between that and saying like hey, here's this nice thing, you know, or hey, this has nice properties. We can talk about it in sort of a calm way without without you know, forming factions. And I think that's, yeah, that's that's also like a step in the right direction
towards having nice communities. Removes the zelotry from it, and it kind of just yeah, yeah, but you know, I mean, obviously, like I'm a very passionate person, I really love ELM, but you know that's not to say that, like I you know, I'm not going to claim that ELM will be the best language of for all time for every problem, Like there are problems like I just talked about earlier where I choose not to use ELM, and also there you know, will it would be weird if this turned
out to be the last programming language anyone ever needed for you know, this domain. Right, Like we're technologists. Technology evolves, sooner or later, there's going to be something else.
Yeah, No, go ahead.
I was gonna say, speaking of evolution, how how has the grown in the last five years.
That's a great question. You know, It's funny because I think of it as a mixture of growth but also refinement, and so some things have grown and other things have sort of intentionally shrunk. So actually, back in twenty fifteen, that was pretty close to a big turning point for the language, which is to date, the biggest like breaking change the language has ever had, like by a very large margin, which was basically simplifying the foundational primitives of
the language. So originally there used to be this very low level of concept called signals, and everything was built out of signals, and at some point what we discovered was that in practice, everybody tended to organize their signals
into this model, view and update concept. So you'd have your model, which is like your application state, then you'd have your view, which was a way to render that state, and then you'd have update, which is a way of transitioning from one state to another based on user input. And those are sort of the three ingredients that everybody
would use. And at some point this became a library, and then eventually it was like, you know what, why don't we just make this the because signals are really hard to learn and everybody uses them in the same way anyway. So basically Evan said, yeah, we're gonna we're going to move the foundation and say, now the foundation is this this sort of model, view and update API that everyone uses anyway. And that's what it's been ever since.
And it was a really nice simplification to the language in my view, and it's sort of almost become synonymus with elements that knows the ELM architecture, and that architecture has since been ported to JavaScript, and you know, various libraries and people seem to like to use it outside the own community too, but making it like a first last thing in the language I think was the biggest
way that elms change since those days. Other things that have changed, so other things have like simplified and gone away. There've been various API changes. The compiler has gotten a lot faster since it was in those days. Like now it's it's very fast. I mean it's normal to have a scratch compiler usually should only take so we have
like four hundred thousand lines of code at work. Actually I haven't measured this in a while, but generally speaking, if you're doing an incremental recompile, expect it to be under a second or like maybe about a second, depending on what changed and like how big the how many other modules that affects. Obviously lots of you know, bug fixes and things like that, but really like the fundamental experience of using ELM, I don't think has has changed
that much other than just sort of getting better. I would say it's more refinements than anything else. We got a nicer debugger, it does like time travel and stuff like that out the box. And yeah, at this point I would say the language has has gotten quite stable.
I don't really anticipate any major breaking changes in the immediate future, which you know, for a language that's granted, you know, not not been around for even a decade yet, at this point, it's nice to see that it's sort of starting to be like, Okay, this is this has been vetted, this design is nice. We don't need to like keep making big changes. There were like one or two changes of various sizes that seem to be necessary based on what we learned, but at this point it's like, yeah,
it seems to be working pretty well for people. One possible which I don't want to promise because not clearly that this will end up making sense. But you mentioned earlier about desktop applications in the browser, and so one thing that a lot of people ask me about is web assembly. You know, what's what's the deal with like
ELM web assembly because ELM compiles the JavaScript. And the short answer there is that ELM is designed to be able to compile to web assembly in fact in a backwards compatible way where even you're so one of the things you can do with ELM's JavaScript inner opt. So we use this at work for like there's some like rich text like wuzywig editor that we use like little
things like that that's written in JavaScript. And one of the things that ELM is designed to be able to do is in the future to be able to compile to web assembly instead of JavaScript and yet still be able to be backwards compatible with not only your existing ELM code, but that even includes your JavaScript innerupt This is all like theoretically, you know, by design, but it's not necessarily going to work out in practice if maybe
something surprising happens. But yeah, there's really no reason that like from a design perspective, ELM could not compile to web assembly if that turns out to be something that
people want. Of course, there are questions of like browser support and things like that, but it's somewhat of an exciting prospect to me that the code that I've already written, or like all that you know, code we have at work could someday just get just a really big, nice performance upgrade by having a compiled the websmbly instead of
JavaScript without our having to really lift a finger. But you know, that's sort of what you can get when you have a language that's by design sort of compiling to JavaScript as sort of a compilation target exclusively rather than as you know, sort of like an enhancement on top of JavaScript like typescript.
Is no.
I think Web simply had a bit of a tough start in its in its life where the first time anyone saw it was when it was mining bitcoins on unwelcomely on your computer. So hopefully in future web senta would be a bit brighter. That was really interesting what you see that jobascript interrupts. So as a as a semi reluctant front end dabbler, you know I am. I am the front end builder of last results, and I like to take relatively complete JavaScript components to solve a
problem which I have a lot of difficulty buildings. Say, for example, I want to do to build, as you said, a rich text editor, some kind of busy with tool. I don't want to spend a lot of time doing that. If I can just drop one in and sure it might take me a couple of days to get it working, but that sure beats six months writing one from scratch. So how interoperable is ELM And do you cover that in your book?
Yes, there's actually a whole chapter on that called talking to JavaScript. And yeah, so ELM is definitely interoperable with JavaScript. But the way that it does it is pretty clever in my opinion, where it basically sort of segments the JavaScript off and so they're sort of like ELM Land and JavaScript Plan and you can get the two worlds to talk to each other. That's why the chapter is called Talking to JavaScript. But it's not a fluid so you can't, for example, in the middle of your ELM
function just call an arbitrary JavaScript function. It's more like the way I like to think of it as it's somewhat like broadcasting an event. So ELM will say like, hey, JavaScript, I want you to do this thing, and then on the JavaScript side you have a listener set up and says, oh, I hear that ELM wants me to do this thing, great, I will do that thing, and then broadcast an event back to ELM and ELM's listening for events from JavaScript.
And so in this way you have a very strong abstraction boundary there, and so you can tell all the things on ELM Land follow the rules that you're used to, and all the things on JavaScript Plan. You know, it's back to the wild West. But they can talk to each other, so you can, you know, and the end user has no idea this is happening. It's just, you know,
from their perspective, it's just a page. The other thing you can do, and I covered both of these techniques in the book, is actually you can use custom elements, which is part of the Web component specification. I think that ELM programmers might be in practice the biggest users of web components just for interrupt because it turns out to be a very convenient way to do interact with JavaScript stuff. So the way if you're not familiar with web components.
That bishim of web components.
Okay, so it's it's a relatively rarely used specification in the browser, but it's basically a way to define a custom element. At least this is the part of it that we really use.
Technically.
Web components also covers like shadow down and things like that, which not really important for the interropt purposes. But custom elements in particular is a pretty straightforward idea for a feature, which is basically, so you've got your built in htmail elements like you got button and div and you know, so on and so forth, and custom elements is a way for you to in JavaScript define new elements which
whenever they're instantiating the browser. The browser just runs your JavaScript code no matter how they got into the dom. So in this way, what you can do is you can start by saying, I want to define a new custom element called I don't know, whizzywig dash Editor, and whenever I see a tag, whenever the browser sees a tag called wizzywig dash Editor, it's going to run this custom JavaScript code that I have defined to set it up and have it, you know, send events, and then
tear it down when it's all done. And then on the ELM side, you just say, oh, I would like to put it in an element here called wizzywig dash Editor, and I'm going to give it these attributes, these properties and set up these event handlers on it, and then the browser will actually take care of of making the communication happen because the browsers like, oh, you've added one of these elements. I will go ahead and run my hook for the custom element, and so on and so forth.
And Yeah, in the book we give examples of doing interrop in both of those different styles. Yeah, the custom element, one, of course, is is quite nice when you want to have something like right in the middle of your dom, like you know, a custom element, and then the other style is more for like if you want to do some processing, like you want to send it off to like a JavaScript logging library or something like that.
It's my understanding that this is what we're doing when we put custom components on the page with like React, for example.
So React doesn't actually use the Web Component SPECK or the custom Element spec. They have their own sort of thing behind the scenes. I actually a few years ago I went to a conference where one of the days of the conference had a it was called a Creator's Summit, and it was basically representatives from several different communities like
technologies working in the browser. So it was like me from ELM and Tom Dale from Ember, and Andrew Clark from React and Steven Fluinn from Angler and I totally blanking on who was there from view, but it was two people. It was Diviya and anyway, so people from
different print and technologies. And one of the questions that someone asked at one point of the group was like, Hey, do any of us really think that we should change our component systems over to use custom elements and like web components or should we just continue doing our own things? And we all agree that we should all continue doing
our own things. And I mentioned like, hey, by the way, we actually we really liked it for interropt but yeah, we still use our own representation internally for actual rendering, and everybody has good reasons for doing that.
I think that's probably likely the it's going to stay. That's an interesting tidbit. Yeah, I've been educating.
I have been too, but I've forgotten a lot of it over the years.
That's totally fair. Okay, So what is the testing land like out there? Like, I mean, is the tooling ecosystem good? Does it have edges? I mean you already mentioned earlier the time traveling, the debugging, you know, the time traveling debugger that you already have.
So yeah, so great question. So for unit testing, there's ELM Test and basically there isn't really any ELM specific sort of integration test stuff because usually when you're dealing with integration tests, you sort of need to spin up a browser and like actually you know, like run the code to see what what actual dom elements up here there.
If you want to test the sort of ELM virtual don code, you can do that in ELM test itself, and you can actually run queries on your own like internal like staying within elm land virtual dom and say like, oh, I expect that to be a button here and a div there and so forth. But of course you know that it's always possible that the real browser might do something different if you have certain extensions installed or things like that, or you have other jobs on the page.
That's that's you know, messing with the dom. So if you want an integration test, ELM doesn't really have anything special to say there. You can use like Cyprus or something like that. But for unit testing, ELM Test is kind of, you know, similarly to ELM itself, designed to be really nice, easy to use out the box, and really fast, and I think it does a.
Good job with that.
There's a chapter on that of the book also, Okay, even better, even better.
I don't know.
Is there anything that you specifically feel like we maybe haven't touched on yet that you're like, well, well we should really talk about this thing.
That's a good question. No, I think it's been an interesting discussion. I can't think of anything. Okay, we'll also put hit.
You also put in your notes that you had an interesting story around how you came to be the author of the Oh yeah, so.
The way I came to be the author of ELM in Action was that. And this is actually in the in the forward of the book. So I got I got an email from Manning saying they were going to do a book about ELM and they wanted to know, like they, I guess I'd given a talk about ELM or something at that point, and I was a, I don't know, part of the early ELM community, I guess, and they asked if I wanted to get on a call to talk about, you know, people I might recommend
for writing the book. And at this point I co authored a very early book on React and I'd written some blog posts and that was kind of about it, given like a talk or two, and I'd never you know,
written a whole book myself or anything like that. But I got on the call and I started getting really animated about just explaining about like, well, it's really important that this is a book about building things, and you know, kind of like a reaction to some of the stuff Luke was saying earlier and trying to make it you know, like not about you know, this like high minded stuff, but just about let's just build a thing in a
nice programming language. And then I was like, oh, and also, you want to make sure to start by teach this first and then teach that later, and teach this in terms of that, because I'd also been like, you know, had some experience teaching ELM to people at this point, and of course, by the end of the call, I was like, all right, I'll write it, which which I suspect was kind of what they were. You know, why they reached out to me to ask me for names
in the first place. That may have been the goal, and if so, you know, well played. But I did not intend to write a book about ELM until they reached out to me and asked me for some names of people who might be good to write it, which I also recommended. There are other people who've written ELM books too, But yeah, I thought that was funny. I don't know, maybe other authors have had that similar experience, but it was the first for me.
Where can I go to look at sites made using ELM? So we've got a no reading site? What other sites are on it? You're like, look, ELM can do.
This, Oh, good question.
I think there is a built with ELM GitHub brief O somewhere built with ELM dot Co. Yeah, let's say they just got a bunch of a bunch of sites here. Yeah, screenshots and links to various things.
I think I will go and check that out. Oh that's what I assumed as well.
Cool.
Then I think we should probably roll into pics maybe unless we have something else. Sounds like we don't have anything else. Okay, sweet Luke, did you want to start us off?
I did.
I have been building front ends this week finally enough, and I've been using a few components from a guy called Rick who has a kind of small software business in the Netherlands called Pekina dot nl and it's p qi na dot nl And these are just kind of far upload components and a few really useful things, and I've been using them to upload to Linod's objects storage s free alike storage system, which is my second pick
and I have picked up before. But the object component object storage component on Linode does not talk to the standard AWSS three gem in Ruby, and if you start talking to it and following the S three guide, you will quickly find it is not S three compatible out of the box. You must add to your rails set up a magic option, and that magic option is the HTP continued timeout and then everything magically starts working. So
a qualified pick layer for Lino System. It's a lot cheaper than S free, it's a lot cheaper than Google Plant, but you do need to know the magic option to get it working with Ruby.
Fun fact about them, they're actually headquartered in Philadelphia, which is where I live, and they host meetups at their office which is actually in a bank, like they're actually they have.
They've got their own bank.
Well the building used to be a bank, so they actually have like servers down where the vaults used to be.
It's pretty cool. Nice, that's pretty sweet.
Yeah, all right, So I have a couple of picks today. One is just kind of something that I was encountering this past week. So I was working on a thing recently where so you know, I have my consulting firm or whatever, and we had a clients come in that wanted a very they they wanted some they wanted some customizations to Shopify and in the end, you know, they what they wanted was like Shopify Pro or plus or whatever it is that costs like a couple grand a
month or whatever. So they that wasn't really in their budget. And so anyway, long story shorts, after a really long process of talking about what they wanted and what they you know, discovering what they needed and things like that, kind of turns out that they just kind of wanted a small thing, and we ended up we ended up basically proposing to put together a site or whatever, basically a custom thing for them. It's using Spree, you know
or whatever. So you know, if you remember from way back or whatever they I mean, they're obviously still around Spree and whatever the thing they came out of them later, I can't remember off the top of myself.
The e commerce yep.
So you know, it works. It's pretty and you know, if you're just trying to up more or less e commerce thing for somebody and it looks like a monolith and it quacks like a monolith like rails was, Spree does the tricks. So that was pretty cool, yep. And so then for my second my second thing, I was looking at my list of stuff and something that I haven't recommended here that's on my list.
It so a book series that I read a really long time ago.
I don't know what it is, but I've always like kind of liked Merlin. You know, the Mage King Arthur kind of era stuff, right, So you know, if you're familiar with you're familiar with Legends stuff, some of them talk about him in a pretty cool manner, and he's always kind of has, you know, a pretty cool atmosphere to him. But then there's something, I mean, he's got some creepy elements to him, right, Like, but but there Merlin, both both actually, but but Merlin specifically as what I'm
talking about. But there's this book series where basically the author imagines Merlin how I became Merlin as a kid, basically, And so i'll paste this in here. But it's a really fantastic series or whatever. I remember I read this. It's been a long time now, but it's like, I don't know, I have a handful of like ten to twenty like books series that like, I'm just like, these are awesome, everyone should read them, and it's on that list.
So it's pretty sweet. And I'll paste it.
In here in just a second once I actually find a link to it on Amazon. So yeah, that was super cool. I just really liked that it gave him a lot of motivations and I mean, if you think about it, I think one of my favorite things here is, you know, Morgan la Fez always liked the evil bad guy, right so, and not a lot of people explain why she's like evil and bad. It's like, oh, she hates Merlin? Why because I don't know? So, And yeah, that was
one of my favorite parts about it. But Richard, did you have anything maybe?
Yes?
I got a couple. Okay, First one, I realized that I'm extremely late to the party here. But Battle Star Galactica good. I never watched it when everybody else watched it, when it was like actually a new thing, but it was always kind of on my back burn and be like, oh, yeah, I should try that at some point, And yeah, it really holds up. It feels like watching a brand new series that just came out, except that I know it's
all the episodes are available miraculously. So if anyone hasn't checked that out and you like, you know, sci fi type stuff, definitely recommend it. Second pick front End Masters. So I did an ELM course for them as well, so if you'll like more of a workshop style format. It covers a lot. There's a lot of overlap with the intro to ELM workshop that I did for them and the book. I also did an Advanced ELM workshop for them, which is sort of more for like once
you've been into ELM for several months. So if you're interested in either of those, check them out front endmasters dot com. I'm also doing a RUST workshop for them, which will hopefully be out in April twenty twenty one. We will see. It's still a work in progress, but that's the goal. Third pick is this is this is gonna be a weird one BARB Medicine dot com. So this is basically two doctors, like MD doctors medical doctors are both really into strength training like lifting heavyweights and
as you know, for health. And then also I mean, I guess some people do it competitively, and I've just gotten really into their stuff. It's like they're really nerdy about it, and they get into all these like details of like protein muscle synthesis and stuff like that, and they have like videos on YouTube and you know, like
guides on their website. And I don't know, I've never really been somebody who likes to exercise for its own right, but I definitely like nerding out about things and so it's it's been kind of cool to read their stuff, and it's it's like, maybe enjoy that aspect of.
It more awesome.
I totally I can totally sympathize with the being late to the game thing. My wife and I neither one of us had watched any Star Treker entire lives. A few years ago we embarked on a journey and watched all of it, so.
Like every every series.
Yeah, like we watched everything, so it happened. I totally understand that thing where you get to a thing like really late, it's got it nice?
Cool?
Well, thanks, Oh, one more thing before we get Oh, actually, if people want to reach out to you, you know, find out more information, how do they get a hold of you?
What's the best way.
Yeah, I'm on Twitter, ELM, Slack and GitHub as rtie Feldbin and yeah you can find all my ELM projects and stuff there.
And my on GitHub.
And I not super active on Twitter, but I used to be more active. I decided I should be less active on it, but definitely still, you know, I'm on there and if people at me, I generally respond to things so awesome.
We can get those links in the show notes as well. Awesome.
Thanks for listening everybody, and we'll see you next time. Thanks, thanks for coming.