Elm is a functional language that compiles to JavaScript and runs in the browser. Lindsay Wardell from NoRedInk joins the JavaScript Jabber panel this week to discuss her background with Vue and Elm. The discussion ranges into how Lindsay got into Elm and how it differs and solves some of the issues that crop up when people build apps with JavaScript.
On YouTube
What's New with Elm? ft. Lindsay Wardell - JSJ 527

Sponsors

Links

Picks

Special Guest: Lindsay Wardell.

Sponsored By:

CHARLES MAX_WOOD: Hey everybody and welcome back to another episode of JavaScript Jabber. This week on our panel, we have AJ O'Neill. 

AJ_ONEAL: Yo, yo, yo. Coming at you live from a decently good neighborhood. 

CHARLES MAX_WOOD: It's a beautiful day in the neighborhood. 

STEVE_EDWARDS: I can't think about where he was. 

AJ_ONEAL: I did have to think about it. And luckily my audio was already on. 

CHARLES MAX_WOOD: Yay. We also have Steve Edwards. 

STEVE_EDWARDS: Hello from cold and gloomy Portland. 

CHARLES MAX_WOOD: Dan Shapir. 

DAN_SHAPPIR: Hi from Tel Aviv, but where it's already springtime. 

CHARLES MAX_WOOD: I'm Charles Max Wood from Top End Devsa and this week we have a special guest. It's Lindsay Wardell. Lindsay, do you want to just introduce yourself real quick? Let people know who you are and why you're famous. 

LINDSAY_WARDELL: Sure. My name is Lindsay Wardell, pronouns she, her. I am from Brighton's Sunshiny Portland, Oregon. You can see the rain. And starting in... 

STEVE_EDWARDS: We just think of it as liquid sunshine. 

LINDSAY_WARDELL: Exactly. It's just liquid sunshine. I started participating in Views on View in 2019. Been doing that for a couple of years. And...in October 2021, I started as a software engineer at No Red Ink. 

CHARLES MAX_WOOD: Now, are they based down here? Because I've seen like billboard signs and stuff saying they're hiring. 

LINDSAY_WARDELL: Definitely hiring there. I think the company headquarters is in California, San Francisco area, but the company is completely distributed at this point. So I've got team members across the US and we've got employees across the globe. 

STEVE_EDWARDS: Is there much tech going on in California? 

LINDSAY_WARDELL: Just a little bit. Just a little bit. Small fruit company.

 

Hey folks, this is Charles Maxwood from Top End Devs. And lately I've been working on actually building out Top End Devs. If you're interested, you can go to topendevs.com slash podcast, and you can actually hear a little bit more about my story about why I'm doing what I'm doing with Top End Devs, why I changed it from DevChat.tv to Top End Devs. But what I really want to get into is that I have decided that I'm going to build the platform that I always wished I had with DevChat.tv and I renamed it to because I want to give you the resources that are gonna help you to build the career that you want. Right? So whether you wanna be an influencer in tech, whether you want to go and just max out your salary and then go live a lifestyle with your family, your friends, or just traveling the world or whatever, I wanna give you the resources that are gonna help you do that. We're gonna have career and leadership resources in there and we're gonna be giving you content on a regular basis to help you level up and max out your career. So go check it out at topendevs.com. If you sign up before my birthday, that's December 14th. If you sign up before my birthday, you can get 50% off the lifetime of your subscription. Once again, that's topendevs.com. 

 

CHARLES MAX_WOOD: All right, well, we brought you on to talk about Elm, actually, not Vue. So do you wanna give us a little bit of background as far as what you've done or been able to do with Elm? And yeah, some of the background there. 

LINDSAY_WARDELL: Sure, a little bit of background on me. I started working with Vue in 2018. Primarily before that, I'd been doing a lot of PHP and backend stuff, but realized it's really cool to have responsive UI that actually changes without a page refresh and started playing around with different options, explored jQuery a little bit, discovered React and Vue, and decided to go into Vue. So 2018 forward, I'd just been working with Vue. Been really lucky that all of my jobs use that, as opposed to needing to learn other front-end frameworks. 

DAN_SHAPPIR: Before we get past Vue, why did you in fact choose Vue? over the other options or specifically over React? 

LINDSAY_WARDELL: So at the time that I was looking, the three frameworks I saw were React, Angular, and Vue. I tried all three of them. Of the three, Vue felt the most comfortable. It reminded me the most of working in something like PHP. And to be clear, I was doing straight PHP before. I wasn't using a framework like Laravel. So just using HTML and then some PHP inside to tweak the logic so the display was different. And Vue felt the closest to that. I was able to build out components using the same basics of HTML and CSS, and then add on the JavaScript for the additional benefit that it could provide. So from a development experience, it felt very comfortable and familiar to what I was doing. I think something like React, looking at it at first, and bear in mind, when I was looking at React, there were no hooks. It was all either class-based or stateless components. So looking at these things, they made zero sense as to why this was what people were doing and it didn't click for me. So eventually I was able to learn React and I could see why people use it and what the benefit is. But as a newer dev to the JavaScript space, going into something like Vue, especially with the options API, where I was able to break down, this is my data, these are my methods, these are the things that I'm watching so I can perform side effects, it felt really comfortable and easy to understand in my head. 

DAN_SHAPPIR: And I'm kind of curious in that context. What was your level of expertise with JavaScript itself when you were going through that transition from the backend to the frontend? Or how much do you think that might have impacted your choice, let's put it this way? 

LINDSAY_WARDELL: I was very new to JavaScript. So I'd been doing web development to some degree or another since like middle or high school because it was just something interesting. I originally started wanting to make fan games with like Sonic the Hedgehog or something and eventually I needed a place to put them and talk about it. So I got into web design. And the web design became more interesting than the games. So I just stuck with it. But at the time when I was doing that JavaScript was just not a fun language. It was, it was very uncomfortable to work with for me. So I stuck with HTML, CSS, learned PHP so I could get some dynamic stuff. Spent a lot of time in both WordPress and PHP BB, just doing what I can using those existing systems, as well as building my own applications in PHP. But eventually over however many years, that was 10, 15 years decided that having some additional reactivity in the front end was probably useful. And I'd copy snippets occasionally for like entering a password and being able to say it's good or bad, or just some basic interactivity that you would have on a web page. But everything had been done in PHP up until then. And I wanted to try something different where you could have a modal appear, or you could have client-side validation to some extent. Just, you know, those little things, nothing big. So when I was approaching React and Vue in 2018, I was fairly experienced in web development, but very new to JavaScript specifically. 

DAN_SHAPPIR: And do you think that your, at the time, lack of familiarity with JavaScript impacted your choice between Vue and React? 

LINDSAY_WARDELL: I don't think it was my familiarity with JavaScript that impacted it. I think it was my familiarity with PHP specifically that impacted it. Looking at React, like at the time I was following the tutorials. I was writing my own code with JSX and the...and everything that React was pitching at the time. I think 16.0 had just come out. So looking at it and following along, I was able to understand what I was doing, but it didn't feel comfortable. It didn't come naturally to me. Whereas with Vue, I'm basically just writing PHP files, but with a Vue extension and then adding on JavaScript on top of it. So I feel like the onboard to get into Vue as opposed to React was a lot smoother. 

DAN_SHAPPIR: So it was the familiar templated approach that got you...hooked on on view as it were. 

LINDSAY_WARDELL: Yeah, that sounds right. 

CHARLES MAX_WOOD: Cool. It's, it's interesting. I'm going to kind of segue us over to Elm because a lot of people, they pick up Viewer, React or Angular because they get a job where they're doing Viewer, React or Angular and it sounds like you picked View and then got a job doing View. So with this latest job transition, it sounds like you transitioned into doing more Rails, Elm, Pascal kind of stuff. Was that by design or was that more just hey, they're doing interesting stuff over here, and they happen to use those technologies. 

LINDSAY_WARDELL: So in 2018, I was learning JavaScript and working at a job there. I transitioned my position from an IT manager into web development because they had an app that was originally developed in 95, and it was not supporting the business anymore. It needed to be switched out. So I built a new app for them using Vue, went with Node and Express for the back end, just so I could be in all one language. If I'm going to do JavaScript, I wanted to do while JavaScript was kind of my thinking. And then later in 2019, I got a new job as a contractor at Daimler Trucks North America. And while I was there, I did learn React and TypeScript, but thankfully I was able to keep using Vue as well. But I was in this mode of just like constant learning about JavaScript and digging in. And it was at this time that I heard an episode of JS Party where they were interviewing people about Elm. And when you're listening to a podcast, and I know this is going to happen with this one as well. Talking about another programming language and comparing it to JavaScript, you're never really going to get a grasp on what the syntax looks like or what the feel of the language is. So as they were talking about this language, I had the takeaway of, oh, it's TypeScript, but harder. So I walked away from that episode thinking, oh, that sounds cool. I kind of like TypeScript. I've been enjoying this thing. I'll learn Elm. Why not? It'll be fine. So I go online to the Elm site. The Elm site. The official Elm site has a nice little guide to get you started. And I'm looking at this, this is not TypeScript. This is not JavaScript. What is going on here? And it took a little bit, but I was able to build a basic app. I had attended a boot camp to get into the front end stuff in 2017, 2018. And so I just rebuilt one of the JavaScript apps from that in Elm as a test. And things were starting to click, starting to make sense, but I couldn't really see why I would use it. But over time, just kind of playing with it as a side project. Eventually, Elm became my favorite programming language. Obviously, I was still using Vue at work, but having that functional programming language that I could reach for as a fun side project was kind of neat. Again, I didn't know anywhere that would use it, but it was kind of cool. So in 2021, I had an opportunity while working at this.labs to interview Richard Feldman from NoRedInk. And we just got to talk about Elm for a while. And later that year, he reached out and asked if I was interested in a position at NoRedInk. So I applied and started in October that year. 

DAN_SHAPPIR: Cool. And No Red Ink is focused on Elm for the frontend? 

LINDSAY_WARDELL: Yeah. So, No Red Ink, for those who don't know, is a platform for teachers to help with their students learning English and writing techniques. It was started, I think, in 2012, 2013. They started using Elm in 2015, and they've been using it ever since. So, the entire frontend is written mostly in Elm. There's a little bit of other experiments some legacy code that's still there. But the majority of the front end is written in Elm. And part of the allure of working at No Red Ink is this is a place where you can learn to use Elm and actually do it in production. So there's a lot of developers that come to No Red Ink specifically because they're interested in functional programming. They may never have used it before, but it's a place where they can get that experience and have that exposure to functional programming in a production environment.

DAN_SHAPPIR: It's really interesting for me that for many years, functional programming has kind of been associated with the academia. That people in the field mostly lean towards, let's say, object-oriented or stuff like that, and it was only those propeller heads in their ivory towers that were really into the functional stuff. And it's really interesting to see this kind of switch that's happening where a lot of people...are embracing functional programming and very often people who are not from an academic background that have gotten into, let's say, development in general or front-end development through boot camps or stuff like that and are still drawn towards functional programming. 

LINDSAY_WARDELL: Yeah. I think a lot of it has to do with, I can't point at the source that I had for this, but somebody broke down a number of languages and a number of language families and one of them was functional programming being a lot like you were saying academia. It's more of like research languages like Haskell. And those languages have influenced other languages. And I think at this point, we're now seeing the fruit of that work where functional programming is being adopted in more mainstream languages. We're seeing it in JavaScript. We're seeing it in Java even and C sharp. These very traditional object oriented languages are adopting more functional styles and functional techniques because we've had the time to kind of take those functional concepts, boil them down into what's really useful outside of pure functional programming and start applying them in a widespread way. On the same side, you have these functional languages that are then evolving out of the academia. So Elm, for example, was heavily inspired by Haskell, but wanted to be something that was more friendly and more delightful to use because anyone who's used Haskell knows it's not the best experience in the world. 

DAN_SHAPPIR: All I can say is that whenever I played with Haskell, I never actually became really professional with Haskell, but I think like many I played with it. And my key takeaway from it was that it was kind of magic. That things that looked like, I don't know, like numeric expressions or algebraic expressions all of a sudden actually executed. So it was kind of strange in that context. But like I said, unfortunately, I never actually got to use it. But I did want to ask you about, it's not just functional, it's also statically typed. So it's not just going from an object oriented approach, it's going to a typed approach. Now granted, a lot of people are going down that road thanks to TypeScript, but with Elm, it's kind of baked in, I guess. It was a type system that was designed from the get-go, not retrofitted on top of an existing programming language. So is that also something that drew you towards Elm?

LINDSAY_WARDELL: I don't think the type system was the initial draw for me. It was, it was more specifically the functional approach, but at this point, I feel like one of the big benefits of Elm is the type system. One of the strong benefits it provides, it is, it is a strongly typed static language. So all of your data in your application is a type. And for example, if you have a function, it will always return the type that you define it's going to return. You can't return two different types. 

AJ_ONEAL: So does that require having a runtime then? 

LINDSAY_WARDELL: There is some level of runtime in Elm.I can't speak to its actual size at the moment, but I remember from some of the analysis that other people have done, the Elm runtime ends up being fairly small and lightweight compared to viewer reacts equal if not better. So you're looking at the same basic trade-offs. 

DAN_SHAPPIR: Yeah, but AJ, to your comment, having a static, enforced static typing is more about the compilation step than about the runtime. It's more about enabling the compiler to verify the correctness of your code. 

AJ_ONEAL: Until you're working with external inputs and outputs such as JSON. 

LINDSAY_WARDELL: So that's actually an interesting point. And that's one of the things I wanted to talk about with TypeScript. Because if you're coming from JavaScript and you're looking at Elm, the obvious choice to look at is TypeScript as your easy comparison. TypeScript has types and it's JavaScript. But with TypeScript, all you're doing is telling the compiler, this is the type that I expect. It can't actually check your data. And you could tell TypeScript to lie if you really want to. You could say something's an any, something is unknown, and just do whatever you want anyway. And this is especially true when you're saying, AJ, what, the TypeScript lies? 

CHARLES MAX_WOOD: Yeah, I want to lie to my compiler too. 

LINDSAY_WARDELL: But if you're going to make a request to an API, let's just use the Poke API as an example. And you're wanting to get information about a Pokemon. 

AJ_ONEAL: Oh, Pokemon, yes. I do want to get information about Pokemon, please. 

LINDSAY_WARDELL: I'm so glad to hear that, AJ. So we go in our get, we make our API request and we get our data back. We run, let's say we're just using fetch. So we fetch the data and then we convert that using result.json. And now we have a JavaScript object. Even if we type that all the way out in TypeScript, there is no actual guarantee that the type you have is what you think you have, because the API could have changed. The data structure could be different than what you typed. There's a whole number of things that could go wrong, but TypeScript won't know and cannot protect you from that. All it can protect you from is what you tell it to protect you from you have to write a JSON decoder. So when you get that JSON value, it's just a JSON value. It could be a string if you really wanted to treat it as a string. But then if you want to use it as an object, as a record, you have to take that and parse it into an Elm type. And if that fails, Elm will say, oops, this isn't the type you expected. And because of its strongly typed nature, it will force you to handle that case. You can decide I'm going to do nothing, but then it's on you. It's not on the language at that point.

DAN_SHAPPIR: incoming data being effectively typeless and then you needing to kind of coerce it into a certain type is one of the reasons I think that a lot of people with TypeScript are kind of drawn toward that GraphQL enforces the typing on the response for you and it kind of works well with TypeScript in that context. But I agree that if you're working with raw JSON data then...with TypeScript, the best you can kind of get is, I don't know, it's strings mapped to strings numbers and stuff. And that's not a whole lot. In fact, there are two reasons that I sometimes struggle with TypeScript, or actually maybe even more. But one is the fact that indeed a lot of things end up being not as typed as you would want them to be. And the other problem is that, again, because it's kind of retrofitted on top of JavaScript, which is kind of the poster child for dynamically typed languages, then it can be really challenging to come up with sane type expressions for some of the JavaScript paradigms. And I guess that's not an issue with Elm. 

LINDSAY_WARDELL: Right. So Elm provides you with a number. Elm, first off, is not a complete and total wrapper around the JavaScript API. The JavaScript API is constantly changing and evolving, especially as new browser APIs are being added. So if you do need to interoperate with JavaScript, sometimes you will need to reach outside of Elm sandbox. But for a majority of the web development that is done, you can handle it within Elm itself, rather than having to reach out and handle those edge cases and those esoteric APIs that may or may not return types that you expect. 

DAN_SHAPPIR: So how do you work with a DOM from Elm? I mean, at the end of the day, you're building a front end application, so some sort of DOM interaction is required by definition.

LINDSAY_WARDELL: So Elm has its own virtual DOM implementation. I don't remember the timeline on it, but Elm and React came out at about the same time and they had some of the same ideas. So Elm adopted a virtual DOM. And when you're writing a front end in Elm, basically what you're doing is declaring function calls, similar to what you're doing under the hood with JSX. So in Elm, if you want to create a div, you call HTML.div. And then it takes two arguments. One is the attributes and one is the inner children. And so you construct the series of function calls in the same way that you would in React or Vue or any of these other languages to build out your UI. The main difference that Elm has compared to React or Vue or any of those is because it is a pure functional programming language. As you are generating this DOM tree, you don't have to worry about any side effects. You don't have to worry about any accidental mutation because there is no mutation in Elm. And you don't have to worry about some of the...some of the oddities that JavaScript has. For example, you're never going to run into undefined is not a function or cannot read null of undefined because those types just don't exist in L. You don't have undefined, you don't have null. If you're going to have a data value that could be empty, then there's a specific type for that, but you don't have to worry about running into missing data when you expect it or accidentally changing the state of your application in a way that you don't expect either. 

STEVE_EDWARDS: So in other words, in L, undefined is undefined? 

LINDSAY_WARDELL: Undefined is indeed undefined.

AJ_ONEAL: So kind of taking a step back or sideways, what is the syntax of Elm? Does it look like, does it look like a functional programming language with a bunch of arrows and brackets and no words, or is it reasonable like Python and JavaScript and go, 

LINDSAY_WARDELL: I feel like it's a mix of the two personally. I've been in the middle of it. So somebody looking at it, who's purely done JavaScript is going to say, wait, where do I put the parentheses to make a function call? You don't. Where do I put the parentheses around my if statement? You don't. So in that way, Elm is a lot closer to Python or I feel. 

AJ_ONEAL: I was gonna say Ruby. 

LINDSAY_WARDELL: Ruby too, yeah. But it doesn't have any end statements at the end of its blocks either. So I feel like Elm syntax is very clean. It does have more arrows because it is inspired by Haskell and the Haskell syntax, but it takes that in its own direction. I think some of the oddities that you'll run into is instead of a bang and an equal sign to say not equals, you're gonna do a forward slash and an equal sign because that looks more like the equals with a line through it. So that's the syntax they went with. Or with a lambda function, you're going to do a backslash and then the argument to that function, because that looks more like an actual lambda symbol, little things like that. But I think if you're looking at it, once you get over some of the small thing, you're not going to be putting parentheses around all of your function arguments. Or to declare a function, you just name it and you put an equal sign and you do something. You don't have to use the keyword function because everything is a function. It's small things like that, but once you get used to them, I feel like it's a complex to work with. 

STEVE_EDWARDS: I was looking at the Elm docs while you were talking. One thing I didn't see is how is a project setup in terms of a project structure? For instance, we know a little bit about Vue, obviously, in Vue you have your single file components, with your template and your style and your script. How-You know there's different ways to set up your directories, but how is an Elm project set up? Is there, and is there, since it's front end, we're compiling a JavaScript, what sort of templating are you using for rendering your HTML to the browser? 

LINDSAY_WARDELL: So primarily when you're structuring an Elm application, just like with Node applications or modern JavaScript applications, you typically have a package.json. Elm has an elm.json file. So all of your dependencies are there and whatever your...root files that you need to access are going to be defined in that file as well. But typically, after your elm.json, you're going to have a source folder and within that is your main.elm file. Main.elm is going to have an application of some sort. Just like if you were using Python, let's say, you had a main function that you call to start the application, you're going to have a similar thing in elm where you have a main function. The kind of application that you spin up is up to you. There are a handful of options. So you can do a sandbox application, which just handles the basic. It's got a view. There's an update function. For those who haven't seen it, an update function looks kind of like Redux, how it used to be, where you've kind of got a switch and it handles all of your messages for you. That's built into the Elm language. It's part of the Elm architecture is that you have an update function, a view function, and your state or model. So the...Most basic Elm application you can make is just those three things. You can then expand that if you want to have subscriptions and allow for interoperability between Elm and JavaScript. The most advanced application you can build is a full, I think it's called browser.application, and that allows you to handle a full SPA style setup where you're watching for navigation events and you're handling the URL changing and things like that. But typically, you're going to have that base setup of an Elm.json file, a main.elm file, and then...If you want to compile that to JavaScript, the Elm language comes with its own compiler. So you just call Elm make. That outputs a JavaScript file. You can then take it wherever you want, import it into HTML or into your view application or react application, wherever you want to go with it from there. There are a number of more advanced setups, including one that I created for integrating Elm with Vite. It's the Vite Elm template. You can find it in the awesome Vite repository as well as on my own GitHub, but that lets you, rather than having to go through the step of compile and then import it somewhere. It just kind of streamlines everything using V to connect your Elm directly into a V JavaScript application. 

DAN_SHAPPIR: So based on your description, it seems to me that unlike JavaScript, where your choice of the front end framework is wholly distinct from your choice of the language, I mean, JavaScript obviously predates all the frameworks that we currently use. And similarly with TypeScript, you can, you know, these days choose effectively any front end framework that you like and use it with TypeScript. It seems to me that what you're saying that with Elm, the framework is kind of baked in. The choice is simultaneously the language and the framework. 

LINDSAY_WARDELL: Yeah, that's correct. One of the huge benefits of Elm, if you look at JavaScript, for example, and you look at all the modern tooling that we need, let's say we're going to do Vue applications. We've got Vue. We're going to use Vite for our setup for testing, let's use Vtest because that's new and cool. We're gonna use Prettier, we're gonna use ESLint, gonna need some additional libraries, so we're gonna be relying on NPM. There's this whole ecosystem of stuff that you need to build a JavaScript application in the modern way that people do today. And with Elm, all of that's kind of baked in. So I like working with V, and I like the streamlined approach that that provides, but you can work with just the Elm language and the tools that it provides. And the framework...that you build in is just the language. Elm is designed around this Elm architecture where you have your model, you send out a view to the browser, you get an update message from the browser, and then you update your model and go back and forth. It's just the circle. And it really streamlines the application development process because you're not having to think about juggling all of these different things with these different concepts and ideas. You can focus on building your application. And granted, there's a lot of patterns and advanced techniques that you can use in Elm. It doesn't, out of the box, you still have to learn what you're doing to use the language properly. But all of the core pieces to get going and get started with the language are built in. And you don't really have to stress about the different decision making that you would have to deal with in JavaScript. 

DAN_SHAPPIR: It's interesting. I think that we are seeing this sort of tendency of effectively a language slash framework choice being kind of merged together in things that some people in the JavaScript community or ecosystem think about as frameworks, but are effectively also their own programming languages. Svelte, for example. People tend to think about Svelte as yet another JavaScript framework, but Svelte is actually a programming language that is similar to JavaScript, but different. And so in that way, Svelte, I think, is actually closer to Elm than to JavaScript in many respects, because it has its own built-in framework, as it were, but it's actually primarily a different programming language. And I think the same thing can kind of be said about Solid.js as well. It's just that Elm takes it one step further by kind of giving up on the JavaScript syntax and JavaScript and some JavaScript semantics. 

LINDSAY_WARDELL: I think that sounds accurate, yeah. created a programming language built around building components and building UIs and building an application. Elm went into the pure functional route and made a way to make functions that had a certain set of guarantees, and then on top of that provided a way to build full applications and UIs. 

DAN_SHAPPIR: Now, if we mention Svelte, so Svelte has SvelteKit, kind of similar to React that has Next.js and now Remix and Gatsby and whatever, and to Vue that has Nox. does Elm have anything like that? Does it have any sort of support for server-side rendering? And does it have any sort of application framework that kind of ties it all together so that you as a developer don't have to do it, setting up a server and stuff? 

LINDSAY_WARDELL: So unfortunately, Elm does not have server-side rendering. That's one of the features that's still coming. One thing to note about Elm development compared to the rest of the front-end ecosystem is it's very slow and methodical. So the creator, Evan Schaplicki, as a language for his thesis. And it's been slowly evolving since then. The last major release was 0.19. That came out in 2019. So it's been a little while. And in this time, Evan's working on new features, but very much doing it as a research project. And when something is finished and ready, it will be released. So server-side rendering is something that's on the list. It's on its planned, but it's not something that's come out yet. On the note of frameworks though, there really aren't a ton. Like in React, for example, React builds itself as being super flexible. It's this UI library. And so because of that, you have Next.js, you have Remix, you have Gatsby, you have all of these things. Because of how focused Elm is on building web applications already, there aren't a ton of frameworks built on top of it. That said, there are a couple that are worth noting. One is called Elm Spa, which is an SPA way to build Elm applications. One of its nice things is that you can do file-based routing. So rather than having to configure the whole thing yourself, you just put in your pages in folders and it puts the glue code in for you basically, just like you would get out of Next.js. Another really cool project that's worth looking at is Elm Pages. Elm Pages was originally designed as a static site generator for Elm, but with version three, it looks like it's going in a bit of a different direction to provide some of the benefits of server-side rendering, as well as things like integration with Netlify functions being able to write Elm on the front-end, back-end, and kind of stitch them together. A third framework that's worth taking a look at, it's called Lambdaera, L-A-M-D-E-R-A, and that is currently released. It is a full-stack solution for building Elm applications, so front-end, back-end, and it provides you with a data store that you can save on the back-end, and they've got free and paid tiers, but it really gives you the full experience of writing Elm, because one of the things as an Elm developer is you get really used to writing that way in the front-end, and then you look at the back-end,How can I do this over here too? Because in JavaScript, you can do that. JavaScript on the front and JavaScript on the back end. But Elm is really designed as the language for building front-end applications. So the back-end solutions are a little lacking, but Lambda really comes into that and solves the problem very nicely. So you can write Elm on the back end and have it access a database of sorts where you're saving your Elm model, but on the back end. So I think those are the three most comparable to what we see in the JavaScript space today.

DAN_SHAPPIR: If you don't mind me asking, what are you guys actually using for your backend? 

LINDSAY_WARDELL: So at NoRedInk, it was originally designed as a Rails application and there is still legacy Rails code being written and maintained. There's actually a great talk by Richard Feldman called From Rails to Elm and Haskell where he kind of goes over this. It's a talk from, I think 2017, 2018, but he talks about the evolution of NoRedInk moving from a straight Rails app using CoffeeScript and React into Elm. And now we're also moving into Haskell. So within NoWriteInk, we are working on writing a lot of Haskell code and doing our logic in that as well, whenever we need to handle things on the backend. There's also a great podcast. I need to remember its name, but I will find it. NoWriteInk is putting out now where we talk a little bit about some of what we're doing internally. It is called Software Unscripted and the host is Richard Feldman. The latest episode that came out was talking about avoiding the database apocalypse and it had to do with some of the issues that rails specifically had with communicating with my SQL and how we migrated some of that code over the hassle. 

STEVE_EDWARDS: So in other words, they're going partially off the rails. 

LINDSAY_WARDELL: Yes. 

DAN_SHAPPIR: Get used to it, Chuck. 

CHARLES MAX_WOOD: I will groan every time. It's fine. 

 

Hey folks, I'm here with JD from Raygon. You know, JD.We were talking just a second ago about empathy, and it seems like a common concept within the programming community. And yet, when we're building features for customers, a lot of times we call it done when it passes CI, deploys and doesn't give us errors. And that really doesn't seem very empathetic when it comes to our customers, because we're not looking at what they're doing. Do you have thoughts on this? Yeah, absolutely. I mean, at the end of the day, until your code actually hits the customer, you don't really know if it's any good. You know, everybody uses things in so many different, weird, wonderful ways. You can only really debug in production. Um, yeah, I've been there. It's done. It's not done. Oh crap. It's not done. I gotta go fix it. Now it's done. Yeah, absolutely. And when we see things like error reports flowing into Raygun, right. A lot of the time it's things where you just kind of go, Oh, that was a configuration that as a developer, I didn't think could exist, but actually here's an example. And so it's connecting that code to customer and your development team through to real users and their experiences, which to your point builds real empathy and the best software teams care a lot about how their customers are experiencing their software. Right. It's kind of the feedback from the app, but it's also kind of this meta feedback is we do better. We tend to get less of this negative input back from our customer, which really does reflect empathy.Yeah, absolutely. And I also think to your point earlier about CI-CD pipelines, like we've done an amazing amount of work as an industry to automate getting to prod really fast. But if you really want to go super fast, you need to close that loop with real-time feedback from prod back to the dev team. And that allows them to do things like fail forward and just really leverage that investment in CI-CD. And it can turn into a real superpower. Yep, absolutely. So I'm gonna encourage you folks, yeah, set up your CI-CD, but then go sign up for Raygun. They'll actually give you a free trial, and you can get it at raygun.com. 

 

DAN_SHAPPIR: So I assume that at least some of the developers work both on the front end and on the back end. How easy is it switching between Haskell and Elm? I guess they're similar, but is this similarity actually beneficial, or does it cause confusion? 

LINDSAY_WARDELL: So at NuraDink, we've, let me back up. One of the nice things about Haskell being a research language is you can define your own, some of your own syntax even for use inside of Haskell. You can change the core library that's used in your implementation. So at NoRedInk, we have a library that kind of Elmifies Haskell and brings a lot of the Elm syntax and data types into the Haskell ecosystem. So as our company is very comfortable with Elm and a little less comfortable with Haskell, we're able to take Elm developers put them in, like myself, this is what I've been doing actually, getting into Haskell and I'm able to say, okay, I need to learn about monads, I need to learn about functors because this is academic functional programming at this point. But I can approach those things from an Elm perspective. A lot of times I can just write code like I would in Elm, and it's able to compile in Haskell without any problem. 

DAN_SHAPPIR: Wait, so Elm does not have monads? 

LINDSAY_WARDELL: That's an interesting topic. Elm does not have an actual data type of monad. I unfortunately cannot describe 100% what a monad is. The way I have it in my head is it is a venable. So if you have something, and then you can do something else to it, that is what a monad is. That's the general gist that I have. Elm has that concept of, let's say you have a list, and then you wanna do something else, or you have a maybe type. Maybe is either nothing or just a value. And then you can do something with a maybe, and then you can do something else. So it has these concepts from monads, but it doesn't have a specific monad type that things inherit.

DAN_SHAPPIR: You mentioned the maybe type, which kind of forces me to do a really brief segue, because you also touched about the fact that Elm does not have null and undefined. And that might be really confusing for people that are not coming from a functional programming background, because, you know, having some sort of a null or a type or value built into the programming language seems like something that how can you do without. And there's an interesting story there, because the whole concept of of a null pointer or null reference was introduced way back in 1965 into the Algold programming language, which is kind of like the granddaddy for C in a lot of ways and then other and many other programming languages, Java effectively and so forth. And it introduced and one of its creators, Tony Hoare, actually created this whole concept of the null reference in the context of that programming language. And he since then has called it his billion dollar mistake. Although I think it's probably cost way more than that by now, which basically the fact that you can get your applications to crash because you're trying to dereference null. And you have to put safeguards around anything that might be a null access in order to prevent your applications from crashing. And then you have...programming languages like Elm and or like the programming language that I'm currently learning which is Kotlin which kind of use a totally different approach of Having nullable types versus non nullable types or the concept of a maybe so you need to be really explicit about whether something can be null or Cannot be null and if the types and the type system actually can guarantee to you that something cannot be null. And then consequently, you just can't crash due to a null reference because it just can't be null. 

LINDSAY_WARDELL: That's right. Yeah. And actually on the point of crashing, one of the things Elm builds for itself is that it will guarantee almost no runtime exceptions. There's been a couple, so we can't say zero runtime exceptions, but it's practically zero in practice. But yeah, so Elm has this concept of maybe, and that fills in the case where something could not be there. So...If I had, let's say a first name and a last name field, last name was required, first name was optional, then in ELM I could just find the last name as a string because it will always be a string. I can guarantee there will always be a value there. And the first name is a maybe string. And in that case, this first name is either nothing, which is the actual type, it's nothing, or it is just a string. And that's how you destructure that value, is you have to do a case statement, which is kind of like a switch and you check to see if it is nothing or just a string. And that's how you are able to access and handle data that could be missing without having to break the type system or without having any runtime exceptions. 

DAN_SHAPPIR: Exactly like you said, that you need to be very explicit about how you access values that might be nothing or might be null in other programming languages. And you need to, and if you forget to perform the explicit test, then the compiler will actually yell at you and...you won't be able to compile, it will break. So you cannot accidentally deploy something like that. But once you have checked and you've converted it from a type that can be null into a type that cannot be null, because you performed that explicit check, well, now you're safe and you don't need to worry about the null anymore or the nothing or whatever it's called. 

LINDSAY_WARDELL: Right. Exactly. Elm has a number of these types, and you can also write your own custom version of this because it's just using the type system and you're defining variance on a type at that point. So you can, I mean, if you wanted an Elm, you could create your own Boolean, call it My True and My False or something, but please don't. But it has a number of these types. So let's go back to the HTTP request as an example. If you make an HTTP request, you're going to get a result. That result is either an error or an okay. And I think you run into this in other languages too, especially like I've experienced it in Elixir where if you make a request of some sort, you've either got an error or you've got okay. And the error is an HTTP error, so you can then break that down and see, was this a bad body? Was it a bad status? Did the server fail? What's going on? And you have to handle each of those cases explicitly. Or you have the data you wanted, and congratulations, now you have the data. 

DAN_SHAPPIR: So I wanted to ask about that, because one of the, like I kind of mentioned, one of the benefits here is that the compiler kind of guarantees the correctness of the application and I've heard it said about Elm that if your code can compile then it's probably correct. But I mean, I'm guessing that you can still make logical mistakes. You can still not consider certain behaviors or whatnot. So I just can't see a situation where you totally don't need to debug. So what is the debugging experience like using Elm? I mean, at the end of the day, source maps are no fun. So is it...How do you deal with that? 

LINDSAY_WARDELL: So let's talk about the compiler first because you're right on all of that. Elm's compiler, first off, is super friendly. So rather than use JavaScript as an example, undefined or cannot read undefined of null or cannot read null of undefined, whatever that error is, that's not really helpful. And it points you at a line number and that's it. Let's say you're a JavaScript developer and you've come into Elm and you're just trying to do some string concatenation where in JavaScript you just use one plus sign and Elm it is two because the single plus is just for numbers. So a double plus is required to do string concatenation. But you're a JavaScript developer, you don't know that. So you do the thing that you normally do. The Elm compiler will then tell you, hey, it looks like you use one plus instead of two plus. One plus is for number addition. You wanna do two plus for string concatenation, which is what it looks like you're doing. How about you try that? Here's a link to the docs. And so the Elm compiler is super friendly and helpful as you're trying to learn and grow as a developer, but also when you run into those cases that you don't really know what's going on. And yeah, it...The line that the Elm community uses, if it compiles, it works. And that definitely does not cover logic. Obviously, you still need to code your application to meet the business need. But if your application does compile, whatever you just told it to do, it will do it. But yeah, you are going to run into debugging at some point. And typically, what we're doing, or let me back that up. What I'm doing on my side projects, I'm not using any special tool. I'm just looking at my code and saying, oh, this thing isn't working. I'm then going to be reaching for, can't remember its official name, but there's an Elm debugger. So if you're using Vite, for example, or if you're using one of the other providers for getting access to Elm development, there's this little debugger, very similar to what you can get with Redux or Vuex, where you can then time travel through all of the changes in your state. But because Elm is a pure functional language, all changes can be rewound. So you can just use that time traveling debugger to access everything that's going on in an Elm application. And you can just walk through this, cause this, cause this, cause this, cause this, because you don't have the annoyance side effects. You don't have accidental mutation of your global state. Everything is very methodical and organized. So if you run into a bug and you see something happening, sometimes what I'll just do is start up the application, do the thing that causes the bug, and then just walk through the debugger and say, okay, this happened and this happened. Oh, I passed the wrong data or, oh, it had the wrong value for some reason. Then, then I'm able to go into the logic and really dive into what am I writing, why is this happening, and fix it. And at that point, assuming I fix the bug, it works because it compiled. 

DAN_SHAPPIR: But is this debugger integrated with the browser in some way? 

LINDSAY_WARDELL: Yes. So in the case of the Elm debugger, let's say you're looking at an Elm application that you're working on. In the bottom right corner of your screen, that's typically the placement, you'll see a little blue button with the Elm icon, and it'll have a count of all of the times your update function has been called. And if you click on that, you'll see every single change that happened in your application since starting.

DAN_SHAPPIR: So your debugger is not actually the DevTools that are built into the browser. They're kind of like an integrated debugger, I guess, implemented in Elm that is shipped together with the Elm application, as it were? 

LINDSAY_WARDELL: Only during development. Typically, you'd want to extract that out for production. But during development, yeah, it's just a little button in your browser. You click it, it'll pop up a separate window with all of the update functions that have been called. 

DAN_SHAPPIR: In any way to kind of handle mobile stuff?

LINDSAY_WARDELL: I'm not sure what you mean, sorry. 

DAN_SHAPPIR: I mean, you know, in DevTools, for example, if I'm probably debugging on a desktop, but I have an option to cause the browser to behave as if it was a mobile device. 

LINDSAY_WARDELL: Oh, gotcha. So in that case, you're still using, in this case, Chrome is what I use. So you can still use Chrome, you can still pretend to be a mobile device, and that button will still appear. So because you're using the desktop version of Chrome, you still have access to everything. And even if you're using the mobile version, you can press the button think on my iPhone when I press the button, it will open up as a separate window in Safari, but I can still see all of the things that have happened. You still have that full development experience that you would expect. 

DAN_SHAPPIR: Cool. Effectively, the debugging is not source maps over DevTools, it's its own custom integrated debugger that you ship with the application while you're in the developer mode. 

LINDSAY_WARDELL: That's correct. So one other example, because we're JavaScript developers and we're really fond of console log, this is the thing we do, right? In Elm, there is an equivalent called debug.log. So if you put in a debug.log, that is a function that takes two arguments. One is a label, one is any value that you get back. So let's say you wanted to see what a specific variable was at a specific point. You could just call debug.log, I wanna see my variable, and then the variable name. That will print it out in the console. Unlike...JavaScript where if you print an object out, it'll just be an object that you can then play around with. If you print out an Elm record, it will stay in the Elm syntax. So it'll look more like a string in your console. But that's probably what you want because you're debugging Elm at that point. And one of the nice benefits about Elm is if you try to compile for production and you leave a debug.log in your code, the Elm compiler will not compile and it'll say, hey, wait, you left a debug. You need to take this out before you compile for production it's helpful in that way too, so you don't accidentally leak things into your console. 

STEVE_EDWARDS: Okay. Speaking of debugging, which is one of my favorite topics, what if you, for some reason, and I've actually seen apps that do this, you wanted to leave some console logging in your application. Is there a way to work around that or is that just a hard, sorry you can't have that line in your code? 

LINDSAY_WARDELL: You can't use debug.log in production. Let me back that up. You can, but your code isn't optimized. Like we were talking about with AJ and the runtime that you would have. If you didn't optimize your code for production, you could keep your debug.logs, but your code is going to be a lot bigger and it's going to take a lot more to download. You can add a port. So ports are the way that Elm communicates with JavaScript directly. So you could write a port that says, log this to the console, please. And then you pass it a string value or something. And then in JavaScript, you subscribe to that port. And whenever something gets called there, you just console log it using a standard console log. So that would be a way that you can do that in production. 

DAN_SHAPPIR: From what I've seen, the only real proper intentional use of console log in production is to output a we are hiring message. Everything else is just log statements that people forgot to remove. 

STEVE_EDWARDS: So getting back to debugging, what are your debugging options? Are there any, can you still use your browser debug developer tools in terms of debugging. If you want to do some step debugging and stop execution, execution and looking at what's going on at a particular point in code. 

LINDSAY_WARDELL: Step debugging is going to be harder in Elm because it is a compiled to JavaScript language. So hypothetically, you could add a stop to the compiled JavaScript, but that wouldn't necessarily point you at what's going on within your Elm code itself. 

DAN_SHAPPIR: So basically you're not single stepping. You're looking, you're debugging through the state and you're debugging that using the integrated Elm debugger. 

LINDSAY_WARDELL: That's correct. 

DAN_SHAPPIR: So you're looking at state rather than at code lines as it were. 

LINDSAY_WARDELL: Yeah. So you're looking at what the state of your application is, what the change was and what the result of that change is. And that's partly to do with the fact that Elm is a pure functional language. Richard Feldman made a comment about how with a pure functional programming language, you could replace all of the function calls with a key value lookup table. And that's how you know that it's a pure functional language. It's not causing any side effects. It's not causing any changes outside of itself. If it's a pure function, you could replace all of the calls with just a lookup table. And so with Elm, when you're doing debugging, it's the same concept. 

DAN_SHAPPIR: Kind of reminds me of the ease even in DM module. Have you seen that? But the question- I don't know the apps without it. I'm sure. 

LINDSAY_WARDELL: Well, otherwise it would be odd, right?

DAN_SHAPPIR: Yeah, for those of you who don't know, it's this amazing npm package that provides an implementation of iseven by effectively comparing to each and every number explicitly. It's amazing code. 

AJ_ONEAL: Sorry, I missed the rimshot opportunity there. I wasn't prepared. 

DAN_SHAPPIR: By the way, I much prefer a recursive implementation of iseven. That was intended to be a joke, but I guess it's not funny. 

LINDSAY_WARDELL: That's okay. I prefer the recursive version as opposed to iseven.

DAN_SHAPPIR: But the question about that also does Elm use lazy evaluation? 

LINDSAY_WARDELL: It does, yeah. So if you declare a function call where you want to, let's say you're trying to declare a variable within a function, it won't evaluate that until it's actually needed. 

DAN_SHAPPIR: And that kind of, I think, explains why single stepping is effectively meaningless in this context. Because things will get evaluated when they get evaluated. And, you know, when they're, like you said, when they're actually needed. So like single stepping becomes kind of funny because you'll be jumping all over the place. 

LINDSAY_WARDELL: Right, exactly. 

DAN_SHAPPIR: So how many people have you got working at Red Ink on that Elm application? 

LINDSAY_WARDELL: That is a good question. I think we've got at least 30 or 40 people in our engineering department. And like I said, we are hiring, we're looking to expand our team. So that number is going to be growing over the next year or two. 

DAN_SHAPPIR: But basically I'm asking it from the...From understanding that it's appropriate for large scale front end up, just something that you would have one person working on at a time, this is something that can be used by a team of people working in tandem. 

LINDSAY_WARDELL: Absolutely. We've got multiple teams working across our Alma application, all working in parallel, working together to make sure that everything is... Everyone understands the patterns that are being used, and everyone understands what changes are being made to the code base.

DAN_SHAPPIR: And when working together, I mean in JavaScript, which is over obviously very free form and you can more or less do whatever you want. We've got tools like Prettier or ESLint in order to enforce kind of coding best practices or even formatting best practices across a team. Is something like that even needed in Elm? 

LINDSAY_WARDELL: Needed is a strong word. I would say it's very useful. As far as formatting, Elm has a very strict formatting guide. So for example, with Prettier, you could have an argument between spaces and tabs. You could have an argument over how many spaces even. In Elm, it's, it's predefined. There are four spaces and that's, that's what you use. So if you're going to indent it's four, it's a four space thing. And there is a tool called Elm format that all it does is enforce the styling guide that Elm already provides. There's another tool created by Yeroon, which is called Elm. I forgot the name of the tool, but it is an equivalent to ESLint, where you can provide it with a set of rules, and it will inform you when you're making certain changes to your code that need to be addressed or not done, depending on the circumstance. One of the nice things about Elm being the way it is is that you can do a lot of dead code elimination just by doing that kind of check when you're doing compile or during your CI step. So if you aren't using a function anywhere, it'll just know, hey, you're not using this function anywhere. And we can see that pretty easily. Or this function isn't exposed and it's not used internally, you can delete it. And there's a lot more complex rules as well as a lot simpler rules that you can just import and use as your team decides. 

DAN_SHAPPIR: So since Elm has its own VDOM implementation and Elm has its own, I assume, data structures because it needs its data structures to be immutable and the built-in...JavaScript data structures that it's compiled to are not immutable and and also because it doesn't have server-side rendering How is that in terms of performance and memory usage? 

LINDSAY_WARDELL: I don't have the official numbers on that But what I have seen in my experience is that it is it is performance and usage To any of the Lmap or not any of the view applications that I've built Performance wise the the best metric that I have just for myself is I have this side project that I've been building since 2018. It's a turn-based strategy game, and I built it originally to learn React. Then I rebuilt it as a CLI app to learn TypeScript, rebuilt it in Svelte, and the latest version was rebuilt in Elm. And all of them perform very well. I actually find the Elm version is the easiest to maintain as well as very, very performant at high speeds. So part of how I do my testing is I have eight computer AI playing against themselves, and each one has a turn of one millisecond. And I just watch it go and see how it's doing. So I've noticed in the JavaScript version, and granted I've grown as a developer since then, but in the React and the TypeScript version, they ran into some hiccups in between turns where the JavaScript would just kind of spin and try to do its analysis. In Elm, I did run into that same problem, but fixing it was a lot easier. And so the performance ended up not being as much of a problem and the AI was able to be more advanced at the end of the day. I don't attribute that necessarily to Elm being more performant than React. I wouldn't go that far, but the way that Elm is structured and the way I'm able to build the application allows me to improve it in ways that JavaScript wouldn't necessarily feel as comfortable doing. I think 

DAN_SHAPPIR: you have to provide a link for that. So super cool 

LINDSAY_WARDELL: is so that the name of the game is called your Rollin J U R A L E N. And I will make sure there's a link for that. Be aware. It does have some music play once you start interacting with it, because I was going for something very Age of Empires civilization feeling. So I've got some nice little background music playing, different sound effects happen. 

CHARLES MAX_WOOD: We're kind of getting toward the end of our time. It's funny because people kept asking the questions that I had, so I just let it all kind of run. 

STEVE_EDWARDS: One quick question, Relic. So what is the status of IDE integrations for Elm? Are there a decent amount of plugins for things like VS Code or WebStorm for syntax highlighting and things that are...particular to Elm? 

LINDSAY_WARDELL: Yeah, so our team uses a lot of different editors. I can't speak to WebStorm, but I personally use VS Code, and a number of people on our team use some combination of Vim or Emacs or Terminal editors. Everyone's able to get the integration for code highlighting, for errors, things like that. It works very well. In VS Code, the tool that you would go for is called Elm tooling, and it provides access to Elm format, so that when you save formats for you, which is nice as well as Elm review. That was the tool I couldn't remember the name of Elm review. So it will provide some basic checks for you like, oh, this type is never used or this function is never called, things like that. And in VS Code, you can also, on a function, you can see every location in your code base that it's called, which is really nice. And there's a handful of other small plugins. One guy from my team, his name is John Suter, created a plugin so that you could see all of the different function calls that are made by type within your app your particular module. So if you create a type, let's say person and a handful of functions that either rely on person or return a person, it will then sort that for you. And so you can kind of see all the different function calls that you have available to you for that person type, which is really cool. 

CHARLES MAX_WOOD: All right. I'm going to push this into picks. We're kind of at that time. I want to make sure we end on time, but this has been awesome. Lindsay, are there resources that you're putting out there or places where people can connect with you to get more information about

LINDSAY_WARDELL: Absolutely. I'm on Twitter at Lindsay K Wardell. Happy to talk Elm there. I also have been doing some blogging about Elm, both on Dev2 as well as on my personal site. So I've got an article on how to get up and going with Elm in 2022 if you want to spin up a new application or how to use web workers, which was my latest blog post, writing the web worker itself written in Elm. So you can find those on my website, lindsaykwardell.com. I'll also do a shout out to the package that I put out on NPM called Elm View Bridge. Since I was a view developer and a view developer, but I wanted to play with Elm, it's sometimes hard to get started in just writing Elm and just go from zero to 100 with Elm. But if you have an existing view application, you can use Elm View Bridge to write an Elm module, import it as a view component, and then just interact with it as you would any other view component, but you're writing Elm code inside of it. So that's Elm View Bridge, elm-view-bridge.lindseykwardell.com. 

CHARLES MAX_WOOD: Awesome.

 

Hi, this is Charles Max Wood from Top End Devs. And lately I've been coaching some people on starting some podcasts and in some cases, just taking their career to the next level. You know, whether you're beginner going to intermediate and immediate going to advanced, whether you're trying to get noticed in the community or go freelance. I've been helping these folks figure out how to get in front of people, how to build relationships and how to build their careers and max out and just go to the next level. So if you're interested in talking to me and having me help you go to the next level, go to topendevs.com slash coaching. I will give you a one hour free session where we can figure out what you're trying to do, where you're trying to go, and figure out what the next steps are. And then from there, we can figure out how to get you to the place you wanna go. So once again, that's topendevs.com slash coaching. 

 

CHARLES MAX_WOOD: All right, well, let's go ahead and do some picks. AJ, do you wanna start with the picks? 

AJ_ONEAL: Oh, let's see what I can get us started with today, don't you know? So I'm not, you know, you, you said earlier, I'm interested to hear what your thoughts are. But the thing is, I really don't have a lot of thoughts on languages that aren't languages that I would use. And the thoughts that I have are just not constructive because at the end of the day, it's, I don't like this. I don't want it. Right. So for me, that the whole functional style of lots and lots of syntax and very little communication. All communication is implicit. I'm not an implicit communicator. I'm an explicit communicator. I don't like high context scenarios. I like low context scenarios. So, but in the vein of speaking about languages, I am developing my own language and you know that I hate transpilers. So where does that leave us? Well, It's a strict subset of JavaScript. So I'm working on it's not JavaScript because you can't run JavaScript code in it, but it is a, a language that you can use in browsers without any transpilation. And really basically what that amounts to is I want the level of quality of tooling that you would get from go, but in a subset of JS that would be a manageable subset. Cause if you try to support every syntax and every possible way of doing things, you just spend your life there. Whereas I think if you take a very small language and say, let's make really, really, really great tooling for a very, very, very small language, you can get to really, really, really great tooling. So anyway, that's the thing that I think I will pick today is just aj script, tentative name, working title. And basically, if you wanna check out the issues on it, it is...Additions, soft, let's have to say this, because it is a subset of JavaScript, but that's the language. There are things in JavaScript that have not been adopted for stupid. For example, we need a math.random int, not because it's complex or it's difficult, but because it's so darn useful that it's one of those things where rewriting those same three lines every single time that you want a random integer of math.floor, math.round, da da da da da. But essentially, there's two parts of it. I'm putting together, well, three parts. I'm putting together some additions to the standard library. So basically, that just means you require something, or you include a script tag, and you get some additional methods that are namespaced with an underscore, not, like for example, promise.underscore sleep. Because I don't think that sleep is ever going to get added to the language, but just in case it does, and just in case the only parameter isn't milliseconds, I wouldn't want to collide with that. And so it's just a little... It's little things that are added to the language that I see as not, you know, a bundle of here's a million utilities, but here are the things that I personally am using in just about every application that I'm creating that just ought to be part of the language because they're so core and fundamental and important at a level of being able to write simple code quickly. 

DAN_SHAPPIR: I'm curious, AJ, does your language have this? 

AJ_ONEAL: Of course not. 

DAN_SHAPPIR: I guess that's what I was going to guess. 

AJ_ONEAL: Now I don't know if it actually evolves out into a language. I don't know. I mean, if it really gets going, because right now it's more conventions because there's nothing to there is no tooling yet to help you. But I'm looking at starting with ESLint with maybe some checkers and some formatters. So for example, one thing that is going to be unique about ajScript is that numbers that are five digits or more in length must have a delimiter in them. So if you were to just write a number that's, say, nine digits long, the default would be that it would reformat it, putting a delimiter between every three digits. So you can have the delimiter wherever you want, but there must be a delimiter in...and numbers that are more than five digits because this increases readability. And I can't think of any reason you shouldn't have that. So that's kind of a, that's one of the more extreme things about the language, but it's, it's optimized for readability and optimized for developing out the correct applications quickly. But again, very much the opposite paradigm of the functional paradigm. It's all about, yes, let's use less syntax and more English words to describe things. So it's much more verbose. But a lot of that verbosity, if the tooling comes through, will be you can still use a shorthand arrow function. And when you hit Save, it would just turn into a normal function. And there would be no difference between the two because there's no this. 

LINDSAY_WARDELL: So I'm actually, I don't want to interrupt our picks mode. I'm glad you mentioned that because I actually feel that Elm is one of the most explicit languages that I've used. Because rather than relying on objects and inheritance from array.prototype.something, every data structure that you have is just a data structure. Every function that you have is just a function. And so if you want to do something, you actually have to write these things and compose them together in a way that, at the end of the day, I feel is more readable and more maintainable than something that I used to write in JavaScript with like, I take an array, dot map, dot filter, dot this, dot whatever. 

AJ_ONEAL: Yeah, I agree, those things get hairy. 

LINDSAY_WARDELL: It leads itself to something that reads more like English despite being a functional language, I feel like it really does give you those benefits that you were just describing about A.J. script. So I'm excited to see what you get. 

AJ_ONEAL: Yeah, well, we'll see. I mean, right now, like I said, it's actual real snippets of code that are things that are the extended standard library, so to speak. There it's guidelines and then it's ideas for this is what the tooling should do. And I am really stumped on how to handle what you just suggested with the...Chaining in some cases if you chain one or two things it can be good But if you're chaining ten things, it's generally bad But I don't know how a tool can look at what you're doing and interpret and say hey This is a bad use of chaining versus this is a good use of chaining and the goal with AJ script would be to make a language that is difficult to abuse so that abusing it is truly an art form and Obviously outside of the realm of software engineering

CHARLES MAX_WOOD: All right. I'm going to derail us back to actual picks. I think this is interesting, but yeah. And I'm waiting for AJ's tooling to tell me, Nope, don't do that. 

AJ_ONEAL: I will. Ideally it would just correct it for you. For example, things anti-babble anyway, a reverse babble. 

CHARLES MAX_WOOD: Gotcha. Are those all your picks or? 

AJ_ONEAL: You know, I, yeah, I wasn't really thinking about stuff. So that that's, I just pulled that off, off the top of my hat, hand, head, whatever it was, I checked all places Steve recommends. 

CHARLES MAX_WOOD: It's the battle you're fighting today. That makes sense. All right. Steve, what are your picks? 

STEVE_EDWARDS: So before I get to the high point of any podcast episode with dad jokes, one little thing I noticed as we're recording this right now, this is what are we in day 10 of Russians invasion of Ukraine and found a little interesting thing on GitHub the other day and I tweeted about it. And my note was when you're wondering why your favorite open source maintainer isn't keeping up with the roadmap, at my day job, we use Bootstrap view and they have been working on for a while upgrade to work with view three with the whole composition API change and so on. And in a recent chain, somebody said, Hey, how's things going at the roadmap? Getting there. And he's like, they're maintainer responded. Sorry, no deadlines at the moment. We have a Russian invasion, our country, and I'm writing this post from a shelter in car key, which is under rocket attack for a few days. So slight, I guess that's a pretty good excuse, but anyway, so. when you're wondering what's going on with open source roadmaps. And remember there's a lot of people in places that don't have quite the stability at the moment. So getting to the, the dad jokes of the week, this is always Chuck's favorite part, I know it. I found out that puns, you know, which are dad jokes, they make me numb, but mathematical puns make me number. 

DAN_SHAPPIR: I get it now. Yes, yes, yes.

STEVE_EDWARDS: A friend of mine stinks a lot because he lives down the street from this milk process, the processing place and everything smells like dairy air. Yeah. Okay. 

CHARLES MAX_WOOD: So we need the trombone sound effect. 

STEVE_EDWARDS: So it took my, you know, I've, I have three kids and it took my wife six hours to push out our first child. She's old enough to live on her own now. 

DAN_SHAPPIR: Okay. Oh, I get it.

STEVE_EDWARDS: There we go. Riverside is a little slow there. 

CHARLES MAX_WOOD: Save us, Dan. Save us. What are your picks? 

DAN_SHAPPIR: Uh, yeah. So I've got two things. Because of, since I'm continuing off of Steve's jokes, I'll start with the happier pick first. And that happier pick is the book Uprooted by Naomi Novik. I just finished reading it. It's a standalone fantasy book. And I enjoyed it a lot. It was like...It was just a lot of fun reading that book. I read it fairly quickly, had fun throughout, and I would recommend it to anybody looking for upbeat, nice, fantasy reading. So that would be the happy pick. The sad pick kind of ties to what Steve was talking about, this ongoing situation in Ukraine. Again, I'm really hopeful that by the time this episode airs, we'll be seeing the end of it. But I'm not overly optimistic, unfortunately. It's even gotten to this point where I'm kind of starting to get scared because on the one hand, I definitely don't want Putin to win, but on the other hand, I'm really scared about what he might do if he loses. So it's kind of this no-win situation that we're kind of getting into, and it's really bumming me out. And as I said before, I know people there, visited there a couple of times. It's so sad to see what's going on there, the human suffering. It really bums me out. And also the stuff that's happening in Russia. I mean, I think like the people that are demonstrating in Russia against this invasion are probably the bravest people that I can think of because, you know, what's happening to them, the way that they are then arrested and beaten and stuff like that, it's really, really sad. So I don't know, my shout out to their bribery.That's all I can say. 

CHARLES MAX_WOOD: Yep. Absolutely. I'm going to jump in with a few picks here. My first pick is taco cat goat cheese pizza. That's a card game. Sorry. 

STEVE_EDWARDS: I was hoping you weren't eating a taco cat. 

CHARLES MAX_WOOD: So, uh, it's, it's a card game and you know, I do the board game picks or whatever. So my, I've been playing with my kids and the way you play it is kind of comes with its own deck and you flip a card over and put it on the pile and you just. In turn, say taco, the next person flips one over cat, goat, cheese. And so if the card matches what they're saying, right? So if you play a taco and you say taco, then everybody has to slap the pile and the last person to slap it picks it up, right? And the object is to get rid of all of your cards. There are three special cards. There's the gorilla, the groundhog and the narwhal. And you have to do a different motion and then slap the pile before, when those show up, no matter what is being called because obviously you're never calling those. Anyway, it's been a lot of fun. My six year olds getting into it. She's not quite as fast as everybody else, but she really enjoys it. And then all of my older kids have really enjoyed it in 10 year old, 13 year old, 15 year old and 16 year old. So anyway, we've been really enjoying it. So I'm going to pick that as the board game pick this week. And then. Yeah, I'm working on getting JS remote conf up. So keep an eye out for that. You just go to JS remote comp. Uh, by the time this goes live, I should have a website up and everything ready to go. You can submit a call for proposals. I'll also be reaching out to people who I think would be good to speak. So anyway, I'm just going to shout out about that. And there was something else I was going to shout out about night. Not thinking of what it is. So I guess I'll save it for later, but, uh, yeah, Lindsey, do you have some picks for us? 

LINDSAY_WARDELL: I have two picks today. First. If you like podcasts and you want to learn more about Elm, I will recommend the Elm Radio podcast at elm-radio.com. It's hosted by Dylan Kearns and Yirun Engels. Hope it pronounced that right. Dylan is the creator of Elm Pages and Elm GraphQL and Yirun is the creator. And they do a bi-weekly episode, bi-weekly show talking about some of the interesting things going on in Elm, such as if it compiles, it works, or this one of the deeper concepts of opaque types, which is really fun. So definitely recommend that. Second pick is a talk by Richard Feldman, Why Isn't Functional Programming the Norm? Where he explores the history of programming languages, especially the object-oriented ones, and talks about how they came to be and why functional programming is not the paradigm that we're all using today, which is a very interesting talk. So definitely recommend that one as well. 

DAN_SHAPPIR: Although again, like I mentioned, undoubtedly functional is becoming much more popular in recent years. 

LINDSAY_WARDELL: Oh, absolutely.

AJ_ONEAL: Anyway, I'm really interested to watch that talk. What was the name of that again? 

LINDSAY_WARDELL: I'm going to look that up right now. I just put it in the chat here is why isn't functional programming the norm?

CHARLES MAX_WOOD: Okay. Yeah. We've had Richard on the show a few times too. So we'll put links to those in the show notes as well. 

LINDSAY_WARDELL: I have one last pick. I forgot to mention at the beginning. So I have three Richard Feldman, since I've already name dropped him a bunch is creating a programming language called rock. The concept of rock is Elm is really great to work with on the front end, but it's not really designed for the backend or other uses. Rock is a functional programming language for those other use cases that Richard Feldman is working on. And starting in April, he'll be doing that full time, sponsored by Norettic. So definitely, 

DAN_SHAPPIR: that's really interesting. That's really interesting because there are already a couple of back-end functional programming languages, like, well, of course, Haskell, which we mentioned before, but also Reason and also Scala and others. So it'll be interesting to see how Rock is different from those programming languages. 

LINDSAY_WARDELL: Yeah, and there's a few videos. I just very bare bones right now because the language is still in development and kind of the goal is to not make people think it's ready. But I believe at Strange Loop last year Richard gave a talk demoing Rock and specifically its performance compared to things like C and go and JavaScript and Haskell. And it was extremely performance. Some of the things that he's doing under the hood, make it a really powerful language in general for backend views. 

CHARLES MAX_WOOD: So I'm looking forward to rock on rails, 

LINDSAY_WARDELL: rock on rails. 

CHARLES MAX_WOOD: All right. 

AJ_ONEAL: There was one thing that I, that I forgot that I should pick. Can I throw that in? 

CHARLES MAX_WOOD: Go, go, go, go. 

AJ_ONEAL: Okay. Okay. So there is an NPM module. Oh, that's such a terrible thing to say. It's not an NPM module. It's somebody wrote it in JavaScript and published it to NPM. Important to get, you know, who really is it that did NPM did nothing for it. Anyway, point being, it's called Slonic, Slonic or Slonic or Slonic. I don't really know, but it's the, it's the, I don't know the French name of the Postgres elephant or something like that, but it does what I always wanted because ORMs get really messy for a couple of reasons. There's no need to write some wrapper for a million different databases, because you're only going to use one database. And that database is going to be Postgres, unless you don't know what you're doing, or you need some specialized database, which you probably don't. So it's going to be Postgres, right? And Slonic has, it's a template tag system, which normally, you know, building a DSL, you know, I don't like these types of things. I don't like the transpiling, I don't like the DSL. But in this particular case, it solves a problem that I don't know of any better way to solve. And it seems to solve it well. And you just write your Postgres SQL in these SQL tag strings. So template strings with a SQL tag, and then you will get additional checking on the strings. So you can, and there's a VS code plugin. Unfortunately, there's not a Vim plugin for it yet, but there's a VS code plugin, plugin that will actually do syntax highlighting on the SQL inside the JavaScript. So while you're in your JavaScript file, you can know whether or not the SQL is valid and will run. And I think that that is just amazing. This is a tool that I've been wanting for a long, long time. It is enough reason for me to open up VS code and try to figure out how to get the plugin installed. I haven't done it yet, but I have faith that it'll work. And, uh, if you know anybody that is willing to work for money, that is a VIM script person and could adapt the VS code plugin to VIM, which I'm sure, because the language server is common between VS code and VIM and all the editors. So there's just some sort of wrapper glue or something that goes on top of them to get it to work from one to the other, I would presume. But if you know anybody, I am very, very interested in getting somebody, commissioning somebody to get this thing working in VIM because I absolutely love the idea of having checking on your SQL while you're writing your code so that you don't have to deal with an ORM to get type safety, you can, you could just get it right there and it's just, I'm so just, bah, I think it's great. 

CHARLES MAX_WOOD: All right. Sounds good. I'll have to check that one out. All right, well, let's just go ahead and wrap it up here. And until next time, folks max out. 

STEVE_EDWARDS: Adios. 

DAN_SHAPPIR: Bye. 

LINDSAY_WARDELL: See ya. 

 

Bandwidth for this segment is provided by Cashfly, the world's fastest CDN. Deliver your content fast with Cashfly. Visit c-a-c-h-e-f-l-y.com to learn more.