[00:00:00] Simon: For a long time, development of elm-watch was basically only updating that vision document and like thinking that, okay, now, now I know exactly what we need. And then a couple of days later, I was like, oh, wait, this is not such a good idea. That's not going to work. And then reworking it.

[00:00:18] Jared: Hey folks, welcome back to Elm Town. I'm your host, Jared M. Smith. We'll be visiting with Simon Lydell today,

[00:00:25] Sponsored by Logistically

[00:00:25] Jared: but first, let's talk about our sponsor, Logistically. At Logistically, we make intuitive software to help logistics teams make better decisions and improve efficiency. Logistically pays me to record Elm Town episodes, as well as pays for our production and hosting costs.

[00:00:43] We build the front end for all new features in Elm. If you're interested in our mission, And enjoy writing Elm, please drop us a line, elmtown at logisticallyinc. com. I'll put a link in the show notes.

[00:00:56] Introducing Simon

[00:00:56] Jared: Now, Simon. Simon, according to his GitHub profile, is a magic coding creature. He's contributed to the Elm Node Test Runner, published the lydell/elm-app-url package as a simpler alternative to the official elm/url, as discussed on Elm Radio 77. He made the elm-tooling tool to manage Elm tools as discussed on Elm Radio 22. He built elm-watch for Elm hot-reloading as discussed on Elm Radio 65. Simon, welcome do Elm Town.

[00:01:36] Simon: Hello, and thank you so much for letting me be here.

[00:01:39] Jared: Yeah, of course. It's nice to have you on.

[00:01:43] Origins in computing

[00:01:43] Jared: To get started, I wanted to ask you about your origins in computing and programming. I know on the episode of Software Unscripted with Richard Feldman, my contribution to the LeftPad incident, you mentioned that you started coding, I think, as a hobby during a mechanical type of job where you learn things like Regex and you also have a history of using tools like CoffeeScript and Babel and Prettier. But maybe if you wanted to go a little bit deeper and tell us a little bit about why you were interested in computing in the first place and kind of what brought you there.

[00:02:25] Simon: Yeah, so, uh, I was born in the 90s, and when I was just, like, a couple of years old, my family got our first computer, which was a, uh, Windows 95. And, uh, I remember, like, uh, playing games on it. And then, our second computer we got was a Windows XP. And, uh, at that time, it was just still playing games. But something else I really liked to do was to just, like, mess around in Microsoft Word. You know, you could do these cool 3D texts with different textures and stuff, and I found that really fun for some reason to do. But even then, like, I didn't really understand computers. I just, like, used the parts that I knew. Until, we invited our, my uncle over. And, uh, he was supposed to help us fix the computer after we had gotten viruses and stuff in it. So I sat next to him and, uh, really, like, learned everything. How, how you, like, install programs, how you configure things, how to Google for, uh, problems that you encounter.

[00:03:42] And then my, like, real computer interest started, I would say.

[00:03:47] Jared: Okay, nice. And so, yeah, you started out with Windows 95, then you went to Windows XP, which from my memory, it was kind of buggy. It seemed like it took longer to do things with that one than, uh, than previously. But maybe that was just the power of the computer that I had or some viruses that were probably running in the background.

[00:04:11] But, but yeah, so you also got into Microsoft Word and, you know, making things with 3D text and just exploring. And then your uncle... And you learned a little bit more. So you mentioned you could Google. So what year was this? Was this actual Google or was this pre Google Googling?

[00:04:33] Simon: it was Google. This was maybe, like, 2007, I think.

[00:04:37] Jared: Right. Okay.

[00:04:39] Simon: But speaking of Google and the web, so, like, the most important thing that my uncle showed me was the Firefox browser. Previously, I didn't even know what a browser was. I thought that the internet was like the blue E with a circle around it. And like, what is this?

[00:04:56] Is this another internet? But then I understood that, ah, okay, there are multiple programs that can access the internet. And, uh, I also learned that you could, like, customize Firefox. And that was my new, my new thing. So I, I liked, uh, looking for, uh, new add ons to install. And I learned that you can even customize Firefox using CSS. So using CSS you, I could, like, change the interface of Firefox. And I found that to be super fun. Just, uh, trying to figure out how CSS works and, uh, see what I could do. And that's, uh, how I learned to, uh, program for the first time. CSS in Firefox.

[00:05:42] Jared: All right. Yeah. So that's really neat. And I remember Firefox kind of being a tool that could make you more of a power user versus Internet Explorer, particularly, because there was before there were dev tools as a standard feature. And I don't know if this aligns with the time you were using it, but you had to add, I don't remember how you added it.

[00:06:11] Maybe it was a plugin, but there was something called Firebug, which only worked in Firefox. And then that gave you access to the console and to inspect things. And it was like this. Really powerful tool. Did you happen to use that?

[00:06:26] Simon: No, not at a time, uh, I only, needed to, like, inspect Firefox interface itself. So I installed, like, another add on called the DOM Inspector, which allowed you to do firebug things, but for the Firefox interface. And, uh, I didn't even learn HTML and JavaScript until a couple of years later. And, uh, at that time, the DevTools were already started to become built in into browsers. So, uh, I basically was pretty lucky starting in an era of browser development where things were already starting to get pretty good and easy for developers.

[00:07:08] Jared: Nice. Okay. Yeah, that is really neat. And so then you're getting into HTML and JavaScript after having played around with some CSS and doing some customizations of Firefox. And then I know, like I mentioned earlier, you had done some, some things as a hobby on the side during I don't know what type of job this was exactly, but some type of a job that was, you know, gave you time to think about different things in your head.

[00:07:45] Do you want to talk a little bit more about that?

[00:07:46] Simon: There is actually one more piece of the puzzle until we get there. And that is, uh, when I started high school. Then, uh, we got these, uh, graphing calculators. Not the famous Texas Instruments ones, but we had Casio, which had a bit simpler programming language. And that's when I did, like, real programming, if you will. I consider CSS to be programming as well, but you don't have, like, your ifs and your loops and stuff in there. So I remember my first program, which was like, print hello, and then go to line one. So it just printed hello over and over and over. Uh, I was really proud of that.

[00:08:32] Jared: Nice. Yeah, I remember Casio as well. I think I talked to Chris Martin recently about the TI series and those being instrumental, if you will, in our learning programming and getting into computing, but you went the Casio route. What programming language was it?

[00:08:57] Simon: They had like their own programming language, but as far as I understood it's pretty similar to Visual Basic.

[00:09:05] Jared: Okay, neat.

[00:09:08] From messing around with open-source to headhunted

[00:09:08] Simon: also during high school I met my best friend, and he already knew some JavaScript. And thanks to him I started learning HTML and JavaScript and I took a web design course. During high school, and also a Python course. And then, after high school, I just had like a random job, as you mentioned from the Software Unscripted episode. But during that time, I messed around a lot with programming in my free time, and put it on GitHub. And thanks to that, a company here in Sweden contacted me. And said like, oh yeah, we saw all of the things that you have put on GitHub. Do you want to come here and have an interview with us? And I did, and that's how I got my first job as a programmer.

[00:09:58] Jared: Wow, okay, so you didn't apply for this job, they found you.

[00:10:02] Simon: Yeah,

[00:10:03] That's so weird.

[00:10:05] We learned in school that like, yeah, you might hear people who get headhunted, but like, that doesn't happen for real. You have to like actively search for jobs, and they taught us how to do it and stuff, and then I... I just got the complete opposite experience,

[00:10:21] Jared: Wow. So that's really neat, and... You got this company that reached out. What kind of work were you doing there?

[00:10:32] Simon: It was a develop web development, uh, agency. So I was, uh, mostly doing front end. Uh, we had, um, Python and Django on the backend, so my Python skills did help a bit. But, uh, on, on the front end, I worked mostly with, uh, Django templates and, uh, jQuery.

[00:10:54] Jared: Okay. So you're mostly writing front end using jQuery and then interfacing with the backend through Python and Django. And did you like the front end more? Was that why you chose that route, or went more that route, or was that more of what was required of you with the work?

[00:11:16] Simon: Frontend was, uh, what I was the best at, given that, like, CSS was the first thing that I learned, and that I had learned, uh, JavaScript, and I had used JavaScript in my spare time much more than, uh, Python. And they were looking for a frontend developer, so that's where I ended up. And, uh, was a different time back then, doing frontend.

[00:11:42] Like, yeah, these Django templates that I was talking about. It felt like the Django people had, like, been burned bad by PHP. Because, you know, like, in PHP, when you start writing something in a PHP file, you're actually writing HTML. Like, whatever you type, it's gonna be treated as HTML until you open a PHP tag.

[00:12:07] And then you can start writing some PHP code. So like, the default in PHP is template. You do everything in the template. So the Django people must have been like, Okay, this is really bad because you're making terrible messes of your code with like, database calls sprinkled with the rendering of a table and whatever else you can think of. So Django templates were like, crazy limited. Which was really annoying as a front end developer who was expected to do complicated UIs. Because there are, like, nothing to help you do it in a good way. You just make a super big template, nest everything deeper and deeper, loops into loops into loops, and you can't have, like, functions that you can reuse so you can have the same little piece of UI in different places. So that is something I don't really miss, I would say.

[00:13:03] Jared: Yeah, I see. Okay, and during that time, using jQuery, the size of the framework, the way that it is constructed, did not really give a clear way to do a front end heavy amount of logic. Correct.

[00:13:24] Simon: Yeah, definitely. And I remember also that, like, it was always easier in one way to do the Django templates. Because there you could just, like, loop over the data you have, make all the elements, and you're done. But in jQuery, you have to, like, replicate a lot of those HTML structures, because you need to be able to update them, and, like, maybe insert a new list item that looks the same.

[00:13:52] How do you do that? Because there's, like, no templating in jQuery. And, um, this is something that I remembered. Uh, when we finally talked about bringing, uh, React at work. So, like, a couple of years later, we decided that, okay, React seems to be a pretty big thing. We're gonna try it out. So we did. And, uh, I really liked in React that you have this render function, which feels a bit like doing a regular backend template.

[00:14:26] You only need to think about how to render once. And you don't need to think about how to update the UI to, like, always be consistent with that render function.

[00:14:37] Discovering Elm

[00:14:37] Simon: And, uh, also from React, we unavoidably bumped into a product called Redux. And reading about Redux, I learned that Redux was inspired by Elm. So then I went reading about Elm, I started watching conference talks, and then I was like, wow, this is the thing.

[00:14:58] This is so much better than React. It is so much better than Django templates and jQuery. And I was kind of hooked.

[00:15:06] Jared: Okay. Nice. Yeah, I think it was Jeroen, and I'll put something in the show notes if I'm wrong here, but I believe he said that he had a similar experience where he had heard about Elm through Redux. I may be misremembering, but anyway, yeah, that's a familiar story. Okay. So, you... Found Elm through React and Redux, and at first, what would, you said that you really thought this is it, but what exactly about Elm was it that you thought was it?

[00:15:45] Simon: I think it was that it was a tool that could do everything in a simple way. Because, like, reading about React, it felt like it was a necessity to bring in something like Redux to be able to do the state management in a good way. And reading about Redux, you learned about, like, you're gonna have plugins for Redux to be able to do side effects. it started to feel really complicated and, like, annoying to have to pick and choose all the different pieces. But with Elm, it felt more like... It has all of these things, and it was thought through, and I didn't need to choose, I could just, uh, do what Elm gives me, and not worry about doing it the wrong way.

[00:16:33] Jared: Right, yeah, that Lego experience, right? You can connect things together and they just fit. Yeah, that makes sense. I remember having to... Be a lead on different projects, and as we would start a new one, every time, it seemed like we had to go through all the different libraries related to whatever framework we were using and try to fit things together in a way that made sense, but it was a lot of work, and then feeling kind of anxious about the decision anyway, because, well, what if this isn't the right choice, or the best choice, and so, yeah.

[00:17:12] When you use Elm, you have the Elm architecture, you have the Elm tools and packages that if they don't fit together, it won't compile, right?

[00:17:24] Elm syntax as a CoffeeScript programmer

[00:17:24] Jared: How was the syntax for you at first?

[00:17:27] Simon: That was actually one of the things that I liked, because, uh, we, at my previous job, we actually used CoffeeScript quite a bit in the beginning. And, uh, I was a contributor to CoffeeScript at the time, so I really liked it. Uh, it actually even said in my first contract that I would be a JavaScript slash CoffeeScript programmer.

[00:17:51] Which is something that I've never had in a contract since. But, uh, I was very fond of CoffeeScript, so I liked the kind of similar style in Elm, where we have, uh, Kind of significant whitespace and no curly braces and it looks like kind of clean syntax wise. So that's something I liked.

[00:18:14] Jared: Yeah, and you had a history of using Python already at this point, so I feel like... The folks that I've taught Elm to that have had Python experience also have that similar, you know, not C like syntax. I wouldn't exactly say Python's ML, but similar enough. And it isn't as scary. But for me, who came from C Sharp and JavaScript and even Java in college, it was very odd to go to Elm. And that was something that took me a little bit to get over. But once I got into it, I focused on, you know, the, the things, those list items that were really important to me that were the reliability and, uh, enforced semantic versioning. And then I got over that, but you said this was something that was really interesting and you had already used CoffeeScript.

[00:19:17] Contributing to big open-source projects early in career

[00:19:17] Jared: And were a contributor to CoffeeScript as well, so that seems like a pretty big job. How long had you been coding when you became a CoffeeScript?

[00:19:31] Simon: Yeah, not that long actually, um, maybe just like two or three years I think. So I went pretty quickly from beginner to CoffeeScript user to like making... A docs fix or something to CoffeeScript to making bigger and bigger pull requests. And for some reason I just really liked working on, on a, on a compiler.

[00:19:58] Jared: Sure. Sure, yeah. And you had worked on, as a contributor to other projects as well, Babel, and Prettier. Did those come later or was this around the same time?

[00:20:14] Simon: They came a little bit later. I think it was CoffeeScript, and then a little bit of Babel and then Prettier like two years later or something.

[00:20:24] Jared: At the point you were contributing to those projects, had you discovered Elm yet?

[00:20:29] Simon: Yeah, um, for Prettier, at least. The reason I was interested in Prettier was because of Elm. I had started writing some Elm code in my spare time, and I used elm-format, and then I went back writing JavaScript, and I, even though I'm like a Vim, person who really likes Vim and likes typing on my keyboard and stuff.

[00:20:54] I was so tired of formatting code. It felt like such a waste of time when I had used elm-format. So I went looking for something similar in JavaScript and couldn't find anything. But then one day on Hacker News, I saw someone releasing Prettier, and I felt like, wow, this is going to be awesome. I have to help out this so it actually takes off, which it did.

[00:21:16] So that was a success. Maybe not because of me, but I think it helped a little bit at least.

[00:21:23] Jared: Yeah, sure. So what were some of your contributions to Prettier?

[00:21:28] Simon: I started out, like, helping out in the issue tracker and, uh, updating the CLI tool and making, like, some small changes to the actual pretty printer. But I did those things because I wanted, uh, the smart people like the initial creator, uh, to be able to spend all the time on the hard parts and making them really good.

[00:21:50] Jared: Oh wow. Yeah, that's awesome. I like that perspective there.

[00:21:55] And so you had discovered Elm, you were using it in your spare time.

[00:22:02] From Elm meetup to full-time developer

[00:22:02] Jared: I asked Kristian Lundstrom to give me some things to ask you, and he said, quote, Do you remember the first Elm meetup you ever went to? What was it about, and do you think the meetup had an impact on your Elm journey?

[00:22:20] End quote.

[00:22:21] Simon: Yeah, so at this time I started going to Elm meetups in Stockholm. And I think the first one I went to was one where Noah Hall from NoRedInk were visiting. And, uh... NoRedInk was like the biggest Elm place at the time, still really big, and it was so cool meeting someone who actually worked with Elm and who knew so much about it, so we were like a bunch of people who just picked his brain and asked him about all the things.

[00:22:57] And I think that definitely got me more sold on it and made me want to use Elm at work as well.

[00:23:06] Jared: So, at this point, the Elm Meetup had solidified Elm in that you didn't just want to use it in your free time, now you wanted to use it professionally. And today, you use Elm professionally at, Insurello, so, which I should have probably mentioned at the beginning, but I know you are a software engineer at Insurello, but...

[00:23:34] At what point did you decide or how did it come about that you were able to become a professional Elm developer?

[00:23:42] Simon: That's all thanks to the Elm Meetup and Kristian who you mentioned. So I kept going to the Elm Meetup and eventually I met Kristian there. And he was already working at Insurello. And he was there with some other folks from Insurello as well. And afterwards they asked me if I wanted to come work for them.

[00:24:07] So, uh, I said, yeah, that sounds interesting. So I went on an interview and went to Insurello and really liked the people and what they were doing and that they use Elm. So then I just felt like, yeah, I, I need to do this. I'm, I'm joining.

[00:24:24] Jared: Nice. Okay, and then at the time you joined, what was the team size like there?

[00:24:34] Simon: I was the fifth, uh, developer. So we were like five developers, product manager. And, uh, yeah, that was basically it, I think, on the tech side. So it was, uh, it was a startup that had been around for like three years or something. So I came in somewhat early. That was fun days.

[00:24:58] Jared: Sure. And so how long ago was this?

[00:25:02] Simon: This was, uh, 2019.

[00:25:06] Jared:

[00:25:06] Okay.

[00:25:08] Natural growth at Insurello

[00:25:08] Jared: So now it's 2023. What does it look like these days at Insurello?

[00:25:13] Simon: Yeah, we're a little bit bigger. I think we are like, uh, Twelve developers or something like that. A couple of designers, more product managers. And, uh, we, uh, we keep going.

[00:25:30] Jared: Nice. Excellent. Excellent. That seems like a good level of growth. I have seen the path where, you know, startups gets funding and then suddenly they have this huge explosion of things to do and that can make it difficult to make the transition from a startup to a large organization, but it seems like this is a healthy level of growth.

[00:25:55] Simon: Yeah,

[00:25:55] I mean, we did have that as well. Uh, in, in between, then and now. But, uh, you know. Lots of things is happening in the world, like we had Corona, we had the Ukraine war, which actually affected us because of investors and stuff, so we had those, uh, explosion plans, but now we are on the more, uh, steady growth instead.

[00:26:20] Jared: yeah, yeah, I like that. It's at the pace of nature. I like to think about it. I think that makes sense.

[00:26:28] Pranking the designer

[00:26:28] Jared: Um, and so then there's another question from Kristian. This is paraphrased

[00:26:40] what's the small prank you implemented in Elm and demoed for the team's designer that had been away on vacation and had just gotten back?

[00:26:47] Simon: Yeah, so, um, our designer had been on vacation, and, uh, When she came back on our stand up, I said like, Oh, by the way, let me just show a little thing before we go live. It's nothing big, I promise. And I said to the designer, don't worry, there's like no new design or anything. And then I started demoing it, and I'm demoing our sign up form at Insurello. I think It helps to know what Insurello does, uh, to understand this. So, basically, if, uh, you, um, hurt yourself, you can come to us and, uh, tell us all about your accident and we are going to help you find which insurances to file to and help you through the whole process. So we have like a kind of a big sign up form that you need to go through. And in my prank there I had extended the questions about traffic incidents that we have. So it started out reasonable like asking was there a vehicle involved and you can say yes. Then coming to the prank question that I added was like, uh, how fast were you going in the vehicle? And instead of like having a number field where you can type in how fast you went, I had made this slider that you had to drag. So the slider went from 0 to 120. Which is like a really weird interface for entering a speed.

[00:28:24] And then, uh, what if you need to go, like, faster than the maximum? Well, then you can also drag the end of the slider to make the slider longer. And then you can, like, choose an even higher speed. And on top of that, you can even drag the end of the slider all the way to the left, past the beginning point, which means that now the slider is negative.

[00:28:45] So you can enter negative speeds, which means that you were reversing. And we just saw the designer, uh, like getting big eyes and like, what is this? You said there were like no new design and this is not good UX. But she, uh, she realized pretty quickly that, okay, this is, this is a joke. This can't be real.

[00:29:10] Jared: Are you messing with me? Yeah. Okay. Nice. That's a good one. Oh, you didn't release that as a package? An Elm package? Just joking, just joking. Okay, so, for the past four years you've been using Elm professionally at Insurello. And...

[00:29:35] Vision document for elm-watch

[00:29:35] Jared: I know you've been building some of these tools, and I was wondering, because as you talked about elm-watch on the Elm Radio episode, you mentioned a vision document for that, and I was wondering if you use that for other things as well.

[00:29:54] Do you want to kind of talk about what that is, and how you used it with elm-watch, and whether you use it for anything else?

[00:30:03] Simon: I think that's the only time I've used it. elm-watch is also the most ambitious project that I've made that really like needed a vision document. And the background behind it is we were using Parcel version 1 at Insurello. But we had so many problems with it. It was very unreliable. And one day, me and some colleagues were talking about it, and all of us said, like, Ugh, I'm so fed up with this. Is there nothing better we can use? So I started, like, Googling what other build systems are there. And it wasn't clear at all what to use. Parcel, they had been working on their version 2 for many years, and it was unclear if they were ever going to release it. Uh, I don't think Vite was a thing at the time. I stumbled on something called Snowpack, which had a Elm plugin. Which, like, felt pretty nice, but it... I'm lucky we didn't use it, because now Snowpack is not a thing anymore. But, like, thinking about all of this, I realized that... It seems like there's a tool missing here. There should be, like, a really nice Elm style...

[00:31:24] Watcher tool that does all these things that I want. at that time, I don't think I knew exactly what I wanted. So, anytime I bumped into a problem at work, I would like type in some more text into this vision document of things that I thought of, things that I wanted to solve, ideas on how to solve it.

[00:31:43] For a long time, development of elm-watch was basically only updating that vision document and like thinking that, okay, now, now I know exactly what we need. And then a couple of days later, I was like, oh, wait, this is not such a good idea. That's not going to work. And then reworking it.

[00:32:02] Jared: Okay, wow, so you spent a bit of time in the planning phase before writing any code, I gather.

[00:32:09] Simon: Yeah, I actually did. And, uh, at least in that project, it worked out fine.

[00:32:16] Jared: Nice. Was this a technique that you just thought, I'm going to try it this way? Had you heard of this as a technique somewhere else? How did you decide to go about this, using the Vision document?

[00:32:31] Simon: I think that I wasn't even sure that I wanted to build something. But I felt like I had a lot of good ideas, so I wanted to write them down, so that I don't forget them. And, uh... That kept happening for a while, and since I still didn't know if I actually wanted to build something, that was what I did, until I finally realized, okay, I should be doing this.

[00:32:58] So it kind of just happened, I hadn't read about it. I'm not sure if I have heard about it ever since either, but that's how it played out.

[00:33:08] Jared: Yeah, I like it. I think it's, it reminds me of a commonplace book where you put your ideas all in one. The example that I've heard is having three by five index cards and writing ideas down on those and then putting them all together and kind of categorizing them by different ideas. But of course, you know, a digital version works just fine.

[00:33:34] But... I really like this as a strategy for thinking about whether to do something, right? You, you stopped and you asked whether you should. Um, that's a reference to the Elm Radio episode on elm-app-url, I believe. As well as a reference to Jurassic Park. Meta reference, if you will. Uh, so, yeah. You were designing this in a way, you were writing down ideas, gathering your thoughts, and then at some point you thought, okay, I'm going to do this.

[00:34:16] Different catalysts

[00:34:16] Jared: What was the, actually, lemme, this is phrased better by Kristian because Kristian is now apparently a producer on the episode because of so many great questions, quote. What are some examples of final events that made you decide to actually start trying to solve a tool tooling challenge like you have done with projects such as elm tooling?

[00:34:42] Are you usually being annoyed with current solutions or lack thereof for a very long time? Or do you quickly go to action and start experimenting? Are there any common patterns between how things you made came to be end quote.

[00:34:55] Simon:

[00:34:55] I don't think there are common patterns. There has probably been... Different, uh, catalysts, uh, for each product. So for elm-watch, it was really long and slow. And, uh, one of the final things that happened was, uh, I started seeing more and more people in Elm Slack wondering, like, uh, yeah, which, uh, build tools should I use these days? I want Elm with hot reloading.

[00:35:21] And people were saying, yeah, different things. And I was like, okay, it feels like there's a need for a, for a tool here that I can make. But for elm tooling, I think it was more like, I got annoyed once, and I, it felt like, oh, this should be pretty quick and easy to do. So I started hacking on something, and got pretty far pretty quickly. So it can be a bit of both. I mean, if, if your idea isn't too big, and you get like a rush of inspiration. Then it's pretty easy to just start on something. But then, you know, the hard part is finishing, as always.

[00:36:05] Jared: Sure. Yeah, so you were annoyed once with Elm Tooling, but with elm-watch, you had taken a longer vision approach. I wonder because at the beginning, I don't know if I would know the scope of these different projects. Did you have a sense of what it would be with each one that, oh, this is, I mean, obviously you said with Elm Tooling, you thought it would be an easy one, and with elm-watch...

[00:36:36] You thought it would be a bigger project. Was this based on some preliminary thoughts and planning, or was this an intuition that you had?

[00:36:49] Simon: Just intuition, I think. But also, Elm tooling, like, replaces something that already exists. So, I had already read the source code for the official npm package to see what it does. And I saw that, oh, this is not so much code. So then you actually have a very concrete feeling of how much work needs to be done to replicate something.

[00:37:13] While elm-watch was like something more completely new. So there I realized, uh, there's, there are more unknowns here that I need to account for.

[00:37:24] Jared: Ah, I see. Okay, yeah, that makes a lot of sense. And then with elm-watch, there were some tools that existed already, right? You mentioned there were... Things like the plug in for Snowpack, of course, there's a plug in for Webpack and there was Elm Live and then the fork Elm Go. What about those, you know, as kind of existing tools, what made elm-watch different in your mind or in

[00:37:59] Simon: I looked at Elm Live a lot, actually. I had used it before for small, uh, hobby projects. And I was hoping to be able to use it. But there were two crucial things with it that was a blocker for using it at work. And that was, one, I noticed that it was a bit too buggy for me. And like the whole point of replacing the setup we already had was to get rid of bugs and annoying things.

[00:38:27] And the other thing is that you can only really have one Elm app set up with Elm Live at a time, but at work we had like, uh, a couple of them, like eight or something that we need to run at the same time and Elm Live just couldn't do that. So then I realized that, okay, I don't think any tool checks all the boxes that I want.

[00:38:56] Jared: Sure, so you can target multiple... Main modules, if you will, or elements, and compile them into a single JavaScript file. But you're talking about compiling separate target Elm to JavaScript compilations. What was the benefit for you to have those as separate apps versus compiling them all into a single JavaScript file?

[00:39:26] Was it simply the assets, or was there something more?

[00:39:29] Simon: Yeah, so for Insurello, we have a customer facing app, and then we have an internal app that only employees use, and they share some code, but there's also a lot of code that they don't share, that we don't want to ship to customers for several reasons, but the most obvious reason is that it's going to be a huge bundle to download, where you don't actually need half of it.

[00:39:59] Jared: Yeah. Yeah, that's a lot, that makes a lot of sense. I have a similar experience with Logistically where we have a customer portal and we want it to load very quickly because it'll often be the case where someone will click on a link and need to go to this or scan a QR code and it pop open from there and they may be not at home, it may be more of somebody out on the road driving.

[00:40:26] So we definitely wanted that to be very minimal experience and much faster versus the standard user app where it's much larger, but folks will likely have more of a single page application experience. They log in, they keep that tab open for a long time and they click around and do different things. So yeah, that, that approach was an important tactic for us as well.

[00:40:53] elm-watch hot reloading

[00:40:53] Jared: And I think I mentioned before, but. We moved to using elm-watch, and that was something that was really nice, was that it was a first class consideration for this type of, this way of using Elm. And even more, there was an example of a package that I wanted to use, but the dependencies, there was... A module that had the same name as a different module.

[00:41:27] So I couldn't install it directly in our code base, so I had to make a separate compilation target, elm.json, you know, basically Elm app completely, and then vendor that in as a sort of directive or custom element within an existing, another Elm app. So, yeah, we may have multiple of those little elm-watch widgets in the corner for a page because of that. So, yeah, that was another thing that was really nice to see, uh, thought about. Because, you know, the way that, if you're growing Elm organically from a company that already has an existing code base, for ours it's AngularJS, but it could be anything, React, Vue, whatever. Then, you may have these different little bits of Elm used in various ways throughout your code and it's nice to have this thought of where it's not going to, it's going to, as I understand it, it will do a check to see if any of the targets that are, it looks at the graph of dependencies and determines whether any of the modules on the page use that particular module. And then will determine which order to compile things, is that correct?

[00:42:55] Simon: Yeah, kind of. So, like, you mean if you make a change to some Elm file, how does elm-watch know, like, which Elm apps to hot reload after that?

[00:43:11] Jared: Yes, yes, I'm talking about, yeah, the hot reloading. So the step that comes when you are looking at the browser, and then you make some change in the editor, click save, use your shortcut, and then... You look in the browser and you expect it to change as quickly as possible, right?

[00:43:33] Simon: Yeah, so, uh, you are correct, I wrote a small parser that goes through all the Elm files and only parses the top of each file, which is like the module line and then the imports. And, uh, following all the imports you get a graph of everything and that way I know which apps need to be reloaded and I send a message to each. Each app that has a WebSocket connected. And sometimes you can have two apps in the same, um, webpage, like you said. And each of them are going to get their own little elm-watch UI in the bottom left corner. And, um, if you change the module, which is used by both those... Elm apps that you have on your page, then both of them are going to receive an update and, uh, both of them are going to hot reload.

[00:44:33] Jared: Yeah. Yeah, it's really neat. It works so seamlessly. It's a really, really well thought out feature and I think, in my mind, it's due to having put these things into a vision document and taking your time and looked at all of the existing tools and focused on what are some real world cases that you solved with it and Thankfully, those real world cases were things that, uh, were happening with other folks as well, like, at Logistically.

[00:45:05] Simon: I'm so happy to hear, actually, that, uh, you are using multiple Elm apps on the same page. So you get to use this, uh, feature where you get two or three elm-watch UIs. Because I have never used it myself, but I decided to support it anyway. Because, uh, I had always been, like, a little bit annoyed that, like, Elm supports multiple apps on the same page.

[00:45:33] There is, like, code written only for supporting that. But at the same time, if you enable the debugger in both of them, they actually stack on top of each other. So, when you look at the debugger, you don't know if it is for app A or app B, and if you click it, you don't know which one you opened. So I just felt like, ah, I'm gonna try to make that better in elm-watch.

[00:46:01] So I don't, like, put two elm-watch UIs on top of each others. Um, and that turned out to be really difficult sometimes. And really annoying. I've been tempted a couple of times to just say, like, Oh, no, that's not gonna be a thing. You're gonna... Have to only have one app on the page, but then I have persisted and made it work.

[00:46:24] So, that was nice to hear a real user of it now.

[00:46:29] Jared: Yeah, yeah, it was a case where, like I said, a lot of our targets are pointed to the same JavaScript, right? It compiles down to the same JavaScript file, so we have... A lot of elements, because it's integrated into an existing AngularJS app, and so a lot of cases we'll say we need a new thing in this little section of the page, and so we'll use Browser.element, and it'll be a new main with Browser.element for that particular feature, it will be embedded inside of an AngularJS directive, sort of like a web component, or custom element, For folks who are not familiar with the AngularJS terms. But, the, this particular case, like I mentioned, didn't even allow us to do that.

[00:47:23] I could not compile it to the same because of these different, uh, conflicting module names from a third party dependency in this tool that I wanted to use. This package that I wanted to use. So, yeah, that was, after that case, it was necessary. And then, Similarly related here, talking about compiling multiple mains or multiple elements, you know, multiple modules with a main into the same JavaScript file.

[00:47:53] I really love that elm-watch provides the ability to configure that in JSON. And the reason is, at work, one of the things that we do is use glob patterns in order to determine Which files will be included in this main target, if you will, so which elements will be used in it in the main user app. And because of that, what I had before was this CLI tool that would expand out all of the glob patterns for you, so it would work with the existing Elm make.

[00:48:39] But now I can have an intermediate step where I can have the glob be expanded and then put into an elm-watch JSON that gets generated. And then if there's any question or any curiosity about exactly what is being built, you can look at that generated elm-watch JSON and be certain whether or not your target is in there.

[00:49:03] Simon: That's cool. I've actually had other people asking about globbing support as well. Where they actually wanted to put a glob in the elm-watch. json file. And, uh, in the end, uh, It kinda turned out not being needed, and I also suggested generating the file like you do. So that was interesting to hear how you actually saw that as a benefit, to be able to more clearly understand which files are actually compiled.

[00:49:34] Jared: Yeah. Yeah, for sure. And I think I had read that as I was looking to make this switch, that this suggestion that you had, I believe, was that in a, an issue on GitHub,

[00:49:48] Simon: Yeah, I think so.

[00:49:49] Jared: Yeah. Yeah, I believe I had read that and I was like, okay, yeah, that, that makes sense as a, as a way to do that. And then once I, I did it, I was really happy.

[00:49:57] And it eventually, it remained inside of that script for a long time. So you would add a new. If you wanted to glob and, and maybe it didn't, that pattern didn't already exist, it would always be inside of the package. json script glob thing. But this was getting kind of unwieldy. So then I, because it was these multiple steps, I was able to pull that out into a separate script and, and have this configuration that would say, what are the thing, what are the glob patterns?

[00:50:27] And then that expand out. And so, yeah, it, it was actually really beneficial in the end.

[00:50:33] Simon: Cool.

[00:50:34] Jared: All right, so enough about that unless there's anything else you wanted to talk about with those things.

[00:50:43] run-pty

[00:50:43] Jared: Okay. So one of the things that I wanted to mention was we also use run-pty, which is not exactly an Elm tool, but I thought it was interesting enough to, to bring up, because it works really well with elm-watch and having other watchers.

[00:51:07] So what we do is we have a separate watcher for LESS files that compile to CSS. And there's even a pre Elm compilation step that looks at our back end Python code and generates endpoints and some... Uh, custom types, but they're basically enums from Python so that those can be used on the front end. And so we watch for that and then that will regenerate using elm-codegen.

[00:51:38] And then that elm-watch will pick up, you know, the new files have been added and then, or changed, and then will recompile the Elm. So being able to see that in that run-pty where it has these different little icons for each one is nice to see those steps going through and separate that so that you don't have this, this big mess of logs all together.

[00:52:00] And if, if something goes wrong, it can be difficult to know where exactly that came from or what was going wrong. So I recommend that tool.

[00:52:10] Simon: So you were asking before how long it takes from idea to making a project or something along those lines. So for run-pty, that is probably the longest from idea to actually making it. That was something I thought about years ago at my previous job, where... It was an agency, so I was like switching projects quite a bit.

[00:52:36] And um, every time I need to switch a project, I need to, needed to start like, um, the Django backend in one terminal tab. And then I opened another terminal tab and started Postgres. And then another terminal tab with RabbitMQ, and then one with, uh, a watcher for CoffeeScript. And then another one with a watcher for sass. So that was like five tabs. And then I needed to switch projects, so I needed to close all of those and start the other ones. And I was really annoyed. So I asked a colleague, like, how do you do this? And he said, oh, I use this tmux config. And I was like, what is tmux?

[00:53:16] And then I read about what that was. And I was like, I don't want to learn this. It felt complicated. So I didn't do it. And then, then we started using Docker, which like, kind of helped with all of this. But then, at my new job, I switched from Linux to macOS. And then, suddenly Docker wasn't as nice anymore.

[00:53:39] I think Docker on macOS has so much more overhead, and like... File watchers don't really work well with it, so then I kind of wanted this tool again. Especially as we were transitioning from, like, just being able to run Parcel, to having to run, uh, both some kind of JavaScript, uh, compiler thing and elm-watch. So then, uh, I felt like I should be able to do... A nice tool that lets you run multiple things easily, and close them easily, and interact with them, and so on. And, uh, yeah, it turned out great. That is probably one of the things that I'm the most happy having built.

[00:54:23] Jared: Oh, nice. Yeah, well, yeah, it works really well. For, definitely for this use case for us as well, and so yeah, thank you for taking that long term approach and continuing to, to work on it, you know, for so long in order to bring it to fruition.

[00:54:41] Simon: Just to be clear here, there were like multiple years of just wanting something like this, and then, like, a couple of months of actually building it for the first version.

[00:54:54] Jared: Oh, nice.

[00:54:54] Huhuh

[00:54:55] Yeah, did you have a vision document or was this things that were kind of going on in your head that you kept coming back to?

[00:55:04] Simon: That was just something in my head, which was just like a vague idea, like, I want an easy way to run multiple things. And then I actually found another module on npm that was very close to this, but it has had like a few problems that I just didn't like. So I thought like, okay, this isn't that much code, I can probably do something similar, but better.

[00:55:32] And it wasn't that much code in the beginning, but I think as I've implemented more features, it's maybe twice as big today or something.

[00:55:43] Jared: Nice. Okay. Well, let's see. I wanted to talk a little bit about what you're up to now.

[00:55:51] Core contribution

[00:55:51] Jared: One of the things that I referenced before was this Software Unscripted episode "My contribution to the LeftPad incident". And one of the things that I took away from that, that I understood that you had a kind of change of principle or change of how you thought about building things.

[00:56:18] I know that, and I definitely folks, if you want to know the details of this, please go to that and listen to that episode. It is fantastic. Um, but you had this experience in the past of taking things that were within source code, or maybe used some little dependency and then changing that dependency or introducing a new dependency, I think is the real.

[00:56:44] Um, case here. And, and then, uh, and then some, some things can happen when you introduce dependencies, particularly for small, small things. And I, I say that kind of as a cliffhanger for folks to go listen to that. But I feel like you had a change at some point because of some of those things that happened.

[00:57:08] And you seem to have this pattern of... Removing dependencies these days and making things dependency free. And I say all that because I looked and just a few days ago, after I had already invited you on the podcast, you said, okay, I looked and there was this pull request out in the Elm compiler, I believe is the code base.

[00:57:41] And it was "Free the NPM package from third party dependencies". And lo and behold, it was merged. So does this mean you're a core contributor now?

[00:57:54] Simon: I think it does, yeah. That's pretty cool.

[00:57:57] Jared: Yeah, that is pretty cool. Do you want to tell us a little bit more about that? How that came about? Why you went through all this trouble? Because it looked like it was a lot of work. Um, because it was, uh, you know, not a, it wasn't just like a documentation change, this, this was well thought out.

[00:58:14] Simon: Yeah, so like we talked about, I had created this Elm tooling, uh, tool a couple of years earlier. Uh, which is an alternative way of installing, uh, the NPM binaries and elm-format binaries and so on, uh, via NPM. And since then, I was always on the lookout on doing it in some other way, potentially. So I was following some NPM issues where they discussed how to install native binaries. I also started using ESBuild, which is a build tool for JavaScript. And I noticed... They made a pull request there completely overhauling how they installed their native binaries. And they used a technique that I have never seen before, which was really cool because it was basically only relying on standard npm features.

[00:59:17] No hacks or no custom code that does any downloading and so on. So, I was pretty excited about that, like, started thinking about, like, hmm, what if Elm could use this? And then, I think the whole thing was sparked by some discussion in the Elm Slack, where somehow, like, Mario got involved, and we were talking about compiling new binaries for the M1 Macs, uh, which Use ARM instead of x86, which was the previous standard.

[00:59:57] And then I felt like, let's just do this, try that ESBuild approach as a way to install Elm in a better way and with new binaries. So, I wrote that, like, yeah, I would be up for making, uh, A secondary package, an unofficial package for installing the Elm binaries. But then, Mario contacted Evan, I think, and started talking about it, and he was actually interested in it.

[01:00:30] Fixing the issues people had with installation. So we worked together, and, um... I made this pull request with a new approach that doesn't need any dependencies. We tested it. I posted on the Elm discourse and lots of people were trying it out. But in the end there were like some final details and hurdles that we bumped into and then Evan didn't feel like he had more time to spend on this.

[01:01:04] He wanted to go back on Working on his compiler exploration, as he called it. And he also has a family these days, so he'd like, obviously want to spend time with his wife and kids as well. So, the pull request got, um, a bit, uh, left behind for a long while. Uh, but, uh, as you said, like, a couple of weeks ago, it was, it was merged.

[01:01:32] Jared: Yeah. Well, I appreciate you putting in all the effort to go through that and making sure that it was detailed and, and, and well thought out. Was there a particular strategy that you used to think about this, about how your approach to making a pull request in the official package, in the official Elm compiler code base?

[01:01:59] Or did you just kind of throw it together?

[01:02:04] Simon: Uh, I, I try to think about, uh, how Evan is as a person or like how I perceive him, uh, from conference talks and, um, also previous interactions on GitHub in issues and in, in pull requests. And I, I felt like he is very careful and wants, uh, things to be done, uh, uh, like his way or in a way that he can completely un understand.

[01:02:33] So I realized that it cannot be too big of a change, then I don't think he's gonna accept it. And I was also very careful to not make any, um, unnecessary changes whatsoever. It's often tempting to like, oh, I can fix this while I'm at it. But then I was like, is this gonna help in any way? Or is it just, like, nice for a programmer reading the code?

[01:03:00] And then I was like, no, I'm not gonna do that. Uh, so, like, keeping it to a minimum. Uh, keeping it simple. And then I tried to document everything that I had learned in the pull request, like showing how everything works, how to actually publish the npm package if it's merged. And I also even like included a tip on how to get a better git diff to more easily be able to understand what has changed.

[01:03:35] So there was a lot of strategy going in there, and Evan actually sent me a message afterwards thanking me for being so thorough in the pull request, uh, documentation, so that, that was nice.

[01:03:47] Jared: Very nice. Yeah. I can tell that it was well thought out. To me, that seems like you're thinking about other people's time. I think it's just generally a good practice to try to make things as small and simple and only do the things that need to be done. Make it clear what you did and why. And to, yeah, make it easy for someone to understand that.

[01:04:15] Especially as a person who has to review a lot of pull requests. I'm always thankful when there's information about why things were done. I end up asking those questions usually anyway. So if someone can do that up front, it's really helpful. And then... If I see something that looks like it isn't related, I'll ask about that too, and so it just, I think overall it saves a lot of that back and forth and is really thoughtful again of, of the time of the person who is trying to merge that in.

[01:04:53] So, yeah, very nice, very nice. I'll add a link to that in the show notes if folks want to look at that. And,

[01:05:02] Simon: uh, I think it helped a lot, uh, that elm-format had already, um, adopted the same approach for the elm-format npm package. I made a pull request there as well. So then, uh, I never knew that, like, okay, elm-format is using this. A lot of people use elm-format. It seems to be working great. Then, like, that's another data point that this is, uh, this is probably going to work out.

[01:05:28] Jared: nice. Yeah. Okay.

[01:05:32] What's up with Simon these days?

[01:05:32] Jared: What's up with Simon these days?

[01:05:35] Simon: I moved to a new apartment at the beginning of this year. So, uh, this year has been, uh, less programming for me and more... Fixing things in my apartment, or looking for a new sofa to buy. And, uh, I picked up, uh, gardening, so to speak. I've never had any plants really before, but now I have, uh, I've, um, grown tomatoes, and I have some flowers outside.

[01:06:07] So I've, uh, put some time into that, and, uh... In that way it's been a really good year, uh, doing some new things. Uh, before I had mostly programmed in my spare time. But, uh, I also feel like there are a couple of things that I wanna do, uh, programming wise and Elm wise. Um, I wanna release a new version of elm-watch with some new features.

[01:06:33] And, uh, I would like to... Also, start working on the Elm HTML package again. I would like to try to make it work with browser extensions. Because currently, like, browser extensions are the Achilles heel of Elm. They can change the DOM in ways that Elm does not expect, and suddenly it starts throwing errors. And that's, uh, not so nice. So that's, uh... Something that I wish to get the time and inspiration to work on.

[01:07:10] Jared: Nice. Yeah, maybe you can pull some inspiration from your history of hacking on Firefox and, and so pull some of that experience in. Really neat. Yeah, I appreciate these thoughtful contributions. And is there anything that you wanted to talk about before we moved on to picks?

[01:07:36] Simon: I think you've covered it really well.

[01:07:39] Jared: All right.

[01:07:41] Picks

[01:07:41] Jared: Well, Simon, do you have any picks for us today?

[01:07:43] Simon: Yeah, I have one pick. It's a TV show called Strange Planet, which is based on a comic called Strange Planet by Nathan Pyle, which is a comic which features these cute, Blob like aliens that live on a planet just like ours. And, uh, they struggle understanding all the weird things that we humans do. And, uh, they have, uh, the strangest and funniest names for everything.

[01:08:19] So they, like, instead of saying coffee, they say jitter liquid. Instead of saying alcohol, they say, uh, ingesting mild poison.

[01:08:29] Jared: Okay.

[01:08:30] Simon: Instead of teeth, they say Tooth Rocks and stuff like that, so it's really funny and cute and I like it.

[01:08:37] Jared: Oh, that sounds good. What does that stream on?

[01:08:40] Simon: It's on Apple TV Hej

[01:08:43] Jared: Okay. Cool. Yeah, we'll add a link to that in the show notes. All right, well, my one pick, I already mentioned it, I talked about it in the course of our conversation about elm-watch. It's run-pty. I've mentioned elm-watch as a pick in the past, but I think that run-pty works really well with it, particularly, again, if you have multiple things that you're watching and you want to...

[01:09:12] separate those, but be able to start it in a single terminal window. It works really well for me, and if that's something you might need, check it out. Thanks to all the folks listening out there. Please rate and share if you're enjoying the show, and thanks, Simon, for coming to Elm Town. Hej då!

[01:09:33] Simon: Hej då!