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