02:27 - Evan Czaplicki Introduction

02:32 - Richard Feldman Introduction

02:38 - Elm 

04:06 - Academic Ideas

05:10 - Functional Programming, Functional Reactive Programming & Immutability

16:11 - Constraints

24:24 - Compilation

27:05 - Signals 

36:34 - Shared Concepts & Guarantees at the Language Level

43:00 - Elm vs React

47:24 - Integration

52:23 - Upcoming Features

54:15 - Testing

56:38 - Websites/Apps Build in Elm

58:37 - Getting Started with Elm

59:41 - Canonical Uses?

01:01:26 - The Elm Community & Contributions

Extras & Resources

Picks

The Pragmatic Studio: What is Elm? Q&A (Aimee)
Elm (Joe)
Student Bodies (Joe)
Mike Clark: Getting Started With Elm (Joe)
Angular Remote Conf (Chuck)
Stripe (Chuck)
Alcatraz versus the Evil Librarians (Alcatraz, No. 1) by Brandon Sanderson (Chuck)
Understanding Comics: The Invisible Art by Scott McCloud (Evan)
The Glass Bead Game: (Magister Ludi) A Novel by Hermann Hesse (Evan)
The Design of Everyday Things: Revised and Expanded Edition by Don Norman (Richard)
Rich Hickey: Simple Made Easy (Richard)
NoRedInk Tech Blog (Richard)

Special Guests: Evan Czaplicki and Richard Feldman.

 

I think Flanders was based on Dave Smith.

Hey everybody and welcome to episode 175 of the JavaScript Jabber Show. This week on our panel we have Jamison Dance.

Hello, friends.

Joe Eames.

Hey everybody.

Aimee Knight.

Hello.

Dave Smith.

Hey, everyone.

I'm Charles Max Wood from DevChat.TV. This week, we have two special guests. We have Evan Czaplicki.

Hello.

And Richard Feldman.

How's it going?

Do you want to introduce yourselves?

Sure. So, I designed and developed this programming language called Elm.

And I use it at work. [Chuckles] And on side projects and examples and pretty much every chance I get.

Very cool. Do you want to gives us a quick introduction to what Elm is, for those who haven't gone and played with it yet?

So, it came from this feeling of I wanted to do frontend stuff but I wanted it to feel nice. And so, it brings in a lot of lessons from the last 30 years of functional programming stuff to try to make frontend programming really, really pleasant. And the key thing here is not that I'm really about crazy academic stuff but that there are a lot of cool insights there that I want to bring to the practical frontend work that I want to be able to do. So, that's the high-level version

So, you said it's not about crazy academic stuff. But it did come out of some of your PhD work. Is that correct?

Actually, it was my undergraduate thesis.

Oh, your undergraduate thesis.

Yeah. So, it actually was, I was going to work on this project no matter what. And if I worked on it as part of my thesis, I get to work on it a whole lot more and with much better guidance. So, it dovetailed together in a nice way. And so, that actually meant that the foundations of Elm are a lot firmer than they would have been if it had just been a project that I was passionate about.

My undergrad thesis was like, “How do I pass this class that I need to graduate?” [Laughter]

So, I'm impressed by people that do real work.

Yeah, it was super fun. My fourth year was, I worked on this project a hell of a lot. [Chuckles]

So, I want to dig into this a little bit. What are some of these academic ideas and how are they actually then applicable? Because when we hear academic ideas usually it sounds like, “Oh, okay. So, something that people noodle over but never really use.”

Yeah. So, I think there's a communication problem between these different communities where really awesome ideas have come out of there. And then no one's able to talk about them in a clear way. So, for me it's all about, how can I not have runtime errors anymore? Or, when I debug how can I go back in time? Or essentially, how can I make my experience as a developer nicer? And if you look through some of this research, there are some really cool stuff. And there's just this issue where there's a whole community that is unable to communicate when they've done something cool. [Chuckles] So, we're…

[Laughs] That's a really good way to describe it.

Yeah [Chuckles]. So, we're trying to find the cool stuff and actually make it so it's fun and easy to use so that we can make cool frontend stuff.

I just wanted to try to get the baseline before we went too far. So, coming from the perspective of someone who has not been writing code all that long, my question is really why you think functional programming is good for the frontend. But in answering that question, if you could go over how you define functional programming and then how you would define functional reactive programming. Because I feel like, especially the reactive part, that word's thrown around a lot. But what does it really mean?

So, first of all, I don't know your background. Are you someone who's just getting into programming?

Yes. I've been doing this for maybe two-ish years?

Awesome. Well, congratulations. Welcome.

[Laughs] I actually, so I worked with a mentor on… he actually worked me through his own project last week. We were able to talk about this stuff. But I know a lot of people listen and they may be fuzzy on those lines, because a lot of people who listen are new.

Yeah.

So, just to take a few minutes and go over that before we go into deep stuff.

Sure. So, my experience with why functional programming is a good fit for the frontend, I think it applies to the backend too. I wouldn't say it's particularly to the frontend. But really, the nice thing about it is just that it gets rid of certain types of problems that I run into a lot over the years, in particular around what happens when you start making codebases bigger and bigger. So, I've noticed that in a lot of cases when you're writing something functionally it maybe takes a little bit of getting used to. There's a familiarity gap because a lot of historically what's been done, like what's out there and what's on Stack Overflow, is done in an imperative style. But once you actually get used to writing something in a functional style, you realize that it's not actually significantly different. It's just that you didn't know how to write it in the way in the first place, if that makes sense.

What makes Elm in particular really go about, as a functional programming language, is just that it builds around the assumption that you're writing in this functional style. You asked, how would I define functional programming? To me it's all about using functions that don't have side-effects. So, stateless functions. In other words, functions where when you call them all they do is they look at what they're given and then they return a value and that's it. And they don't have any side-effects and they don't go query the world for anything. They just take what they're given and then return a value. So, if you give them the same values, they return the same results every time no matter what and do nothing else.

And to zoom out on that point, the reason why that's useful is it means you can think about your codebase in a local way. So, if I make a change in one piece of my code, I can know that it's not going to mess something up three files away or 10 directories down or something my coworker was working on a month ago. So, you get this modularity of adding code that's really kind of crazy.

Well, that's interesting is that it's nice but I wouldn't go as far as to call it crazy.

When you're just doing it in that style. So, I got introduced to these concepts a couple of years ago and I started using that style when I was writing JavaScript and CoffeeScript, just trying to write as many stateless functions as possible and then confine my mutations and updates to the minimal part of my program as I could. And I found that that was very helpful. It made my codebases easier to scale. It made things easier to debug. It was just nice. But it wasn't crazy awesome.

What's crazy awesome is when you have a language like Elm where that's the only game in town.

All of your functions are guaranteed to be stateless, because at that point when you look at a function and you're like, “What is this thing doing? I have this bug. Which part of the codebase could be responsible for this bug?” You can narrow that down just crazy fast because you're like, “Oh, well the only things that these functions could possibly do is call one another and use what each function returns.” So, I don't have to worry that this chunk of the codebase is affecting this other chunk of the codebase because it's literally not capable of affecting it. That's really awesome.

And immutability as well, correct?

Yeah. So, immutability is baked into Elm, which gives you this separation of concerns where it's not possible for one piece of your code to reach into another piece and mess with it.

Yeah. And those two go hand in hand, right? It's a lot harder to write stateless functions all the time if you have mutation because it's pretty easy to accidentally mutate something and then turn a stateless function into something that's no longer stateless. So, immutability actually gives you an easier time of doing that. So, I actually wrote a library that we use at work called seamlessimmutable that essentially makes it easier to use immutable objects and arrays in normal JavaScript code. These are just, you can just pass them around to any normal JavaScript function and they'll just work as long as that JavaScript function doesn't try to mutate them, of course, because it won't work.

Yeah. And to go to the point of, what is functional programming? What is functional reactive programming? I think every person you ask is going to answer those questions differently. So, I'm not going to say that I have a canonical answer. But for functional programming I'd say it's sort of there's a constellation of language features that are helpful. And so, that's stuff like immutability, doing things primarily through functions. So, if you need to configure how a certain part of your application works, instead of passing in some data maybe you'll pass in a function. So, that kind of stuff. And then depending on who you talk to, they might be more or less into types as a fundamental feature of functional programming.

I don't buy it.

Yeah [chuckles].

I don't buy it. [Inaudible]

Yeah. And then functional reactive programming, again you have a… [Laughs] people have many opinions on what is the true functional reactive. The way I think of it in Elm is essentially we have a way of running events through a program that lets us still use stateless functions and immutability and get all these nice benefits that Richard was talking about. So, it's essentially, how do you handle events in this environment where you're coding in a very particular way.

And interesting meta-comment on that is that I've heard a lot of discussions recently about 'What is reactive? What is FRP? What is functional programming?' And something that I've noticed is that there seems to be, in my opinion and this might be controversial, but I think there's a lot of smoke but not as much fire there. I don't know that those are necessarily the most important questions to be asking. Same thing with type-checked versus not type-checked. If I look back at the history of languages I've used and I rank them from my favorite to use to my least favorite, there's a mix of all those different things. There's a mix of functional and imperative. There's a mixed of typed and untyped. And they're not sorted like all the 'one type is above the other'.

I think it just has to do with, what is the collection of things that makes up the experience of using a language? Are you using a library? Are you using a framework? And I think that you have to evaluate on a case by case basis. And it's really about, is this thing more than the sum of this parts or contributes to experiences that are more than the sum of their parts? And for me, that stuff in the case of Elm, and it's been the case with other technologies I've used in the past, but I don't know if I could generalize and say that just because I like Elm and Elm uses functional very hard core strict type system and stateless functions and immutability everywhere, that I would like another language that did the same thing. I think what makes me like Elm is the way that those ideas as put together in a really clean way. [If] there were another language that had those same characteristics, the same buzzwords, but they weren't put together as well as they are in Elm, I could see not liking that language.

So, you're saying that you hate Haskell? [Laughter]

That's what I got from that.

I was very careful not to say that. [Laughter]

But I think that's a really good point. And the thing I think about when I'm making design decisions is, my goal is for people to be using the language for them to achieve their goals quickly and to have a good time doing it and to not regret [chuckles] that they did it a year down the line. I know, I have some JavaScript codebases where we're like, “Yeah, it works!” and then a couple of months later we're like, “Aaah!”

Oh, boy.

[Chuckles] So, it's really about having a clear sense of what the language is for and then achieving those goals really well. So, if we're not in competition with JavaScript or TypeScript or et cetera in terms of making frontend stuff, then we're doing it wrong. And whether it's functional or typed, I think those are incidental. It's about what's the best experience of achieving your goals and having a good time while doing that.

I just think too from more of a beginner person's perspective, it actually seems like a very approachable entry into functional programming. Whereas some of these other languages don't seem horribly approachable, this definitely seemed extremely approachable.

That's awesome to hear. That's like…

That's a huge goal of ours, to make it so folks can get started easily and feel like, “Oh, this makes sense. I can use this.”

Yes.

Yeah. And I've actually been on the other side of your experience Aimee, which is to say that… so, we have a couple of coworkers at work, or I have a couple of coworkers at work who went through a coding bootcamp. And actually, they have less experience than you do. In one case, it's just literally straight out of… this is their first programming job after a bootcamp. And it's been really interesting teaching them Elm as we use it at work.

So, I can't be the only person maintaining that code. So, I've been pairing with people and teaching them how to use Elm. And it's been just very illuminating, the experience of teaching people how to use Elm versus teaching functional programming using other languages which I have tried to do in the past. With Elm, it's just like, “This looks a lot like our other code except that there are a few tips and tricks that you need to learn.” It's like, “Oh, you don't do this in quite this way. You do it in a slightly different way.” And then beyond that, it's just a lot of the conversations we have tend to go like this where they'll say, “Okay, we need to worry about… oh no, we don't need to worry about that because that can't happen here. Right.” [Chuckles]

[Chuckles] Yeah, that's exactly it. I almost think… so, some people would think that maybe functional programming sounds a little bit scary. But I almost think some of the concepts around it will keep you from making mistakes. And as a beginner, that's really valuable.

So, I want to…

Yeah and it's also valuable as an expert, honestly. [Chuckles] We're humans. We make a lot of mistakes. And having a language that just helps you with that is just fantastic. I don't have enough hubris to say that I'm such a great programmer that I can just jam out code and it's always going to work, and especially that it's still going to work six months from now after we've been banging on it and making changes. But yeah, just knowing that the language has my back is just a very good feeling. It doesn't seem to go away with experience.

So, we've talked a little bit about this on the edges, but I want to talk a little more explicitly about it. It's this idea of constraints and how they can be helpful. I think if you're a person who's done a lot of JavaScript UIs and hasn't done a lot of functional programming, coming into Elm it can feel very constricting. There are a lot of things you can't do that you just want to do. And it can be counterintuitive to when you hear people tell you that that's better. Like, “No, it's good that you can't…”

“…pass in an object or a string to this function. You're better off that way.” Can you talk maybe about that idea and how it's helpful in the long run or if it is?

So, my friend Faruk Ate_ created Modernizr. He did this great presentation called 'The Beauty of Constraints'. And he's talking about it in the design context and how to make good user experiences and how constraints can allow you, sort of empower you to make something better than if you'd given yourself the full range of options. And I've found the same thing in working with the constraints of Elm and with the constraints of trying to use stateless functions in general, which is that basically the experience I've had is that there's this curve.

The first part of the curve is like it's the unfamiliarity part where you're like, “Wait. I want to do this thing. And I reached for the familiar tool and that familiar tool's not there anymore. How can I possibly do what I wanted to do?” And then in some cases you think about it. In some cases, you google it. Whatever. The point is you eventually get to a different place. You realize, “Okay. I can still accomplish what I want to accomplish. I just do it in a different way than I was doing it before” And so, by the end of it you end up achieving the same result that you wanted to achieve before.

And I definitely have yet to encounter a problem that I could not solve with functional programming or with Elm that I couldn't have solved with just plain vanilla JavaScript. But the difference is that by the end of it, these constraints, the fact that you were applying them consistently throughout mean that you can go back and look at your code and it's easier to modify. Because you say, “Okay, if I

make this change, will it break these other things?” or, “Does this thing have a dependency on this other thing?” Your dependencies are much clearer and your invariants give you the ability to make changes with confidence.

One way to look at it is constraints. But another way to look at it is as guarantees. When you write this function, you have a 100% guarantee that some other function in your codebase can't break it. And I think those are two sides of the same thing here. So, I want to flesh out what Richard was saying from the way I think about languages. So, when I think of constraining a language, so when you want to write a program, there's an infinite number of ways you could write that program. And the constraints are essentially giving you a smaller infinity. And hopefully, that smaller infinity is also a good subset. So, if you can get it just right, the common path through the language will also be great code.

So, another thing that's interesting about constraints is when you have rules about how the code works, the more structure there is to those rules, the better you can do large analysis of the code. So, when you access a field that doesn't exist in Elm, we're actually able to find that immediately and say, “Hey, the value you're passing to doesn't have that field,” and just let you know immediately. And that's because of the structured nature of the language. And part of the reason why JavaScript tooling isn't at the same level of Java or some other language is because having these rules, having the structure really helps you do meta-analysis. So, essentially the computer can help you code more if the rules for the [inaudible] are simpler.

Do you have that same feeling about JavaScript and TypeScript?

What do you mean?

Well, types are a form of constraints, right?

Mmhmm.

JavaScript's extremely popular and many of those who program in JavaScript, when they hear about types and strictly typed languages, whether they're experienced with them or not, often sort of poo-poo the idea. And we have TypeScript for JavaScript. And those who mostly adopt it I think are those who came from a strictly-typed background and missed it.

So, I'm going to make three statements all of which are true.

One: Elm is way, way stricter than TypeScript as a type checker. Two: I have never used TypeScript. Three: I have no interest in TypeScript even though I prefer Elm to JavaScript. And so, that gets back to my earlier point about, I don't know that there's necessarily a [chuckles] big correlation at least in my experience between whether a language is type-checked or not versus how nice it is to use. But the point is that what TypeScript essentially does, at least from reading up about it, is that it lets you add type annotations and the compiler will check those for you. But that's not really the type of guarantee that Elm provides.

What Elm's compilation does is it will tell you if you made a mistake anywhere. TypeScript will only tell you if you made a mistake where you told it about the types. And if you forget to annotate a type somewhere, you're still on your own. So, I don't have this guarantee of all of my functions are calling each other properly. It was I think over a year before I got my first accidental Elm runtime exception. And literally, I'm not making this up, it was from something that's going to be caught by the compiler in the next release. [Chuckles]

Yeah. [Inaudible]

So, it wouldn't have even happened. I would still have an undefeated, unbroken, never got a runtime… not even just never got 'undefined is not a function' but never even got a runtime exception, except for that.

So, that sounds like you're saying, “Any time there's a problem with my program, it's always the author of Elm's fault.”

Yeah, yeah, yeah.

That is exactly what I'm saying.

I like this language.

Yeah. And you're joking, but that's actually how I think about this design process, is if people are running into issues, one way to handle it is just be like, “Oh, programming is hard. Do better.” And I think a lot of different libraries and languages have that. And I prefer to take that as a critique of my work so far and ideas of how to do better.

So, as an example of this, we have an error message catalog of sort of, whenever you get an error message that's like, “Hey, you tried to use this field but it doesn't exist,” people can submit, “Hey, I got this report but I don't exactly know what it's talking about.” And so, we are trying to collect all those and improve as much as possible. So that whenever you get an error message, it doesn't feel like an error message anymore. It feels like a hint. It feels like you have an assistant who's saying like, “Hey, I found an issue here. Here are the relevant docs. Here's a suggestion of how to fix it.” So, we really want the experience to be really pleasant. And I do take it really seriously when people are confused. I think that that's something that I can make better.

And to finish up on the TypeScript question, one thing that is interesting to me, especially because my career has been back and forth between dynamic languages and type-checked languages, I

remember that one of the things when I first switched from type-checked to dynamic was thinking that, “Man, this is so much more concise.” I don't have to write out all these crazy type annotations all over the place.

And when I heard about TypeScript I was like, “Oh great. I'm going to go back to that. I'm just going to add a type annotation to everything if I want it to be more type-checked. Now at that point, it's like I'm just writing quick unit tests. I'm saying, “Okay, this needs to be this type and this needs to be that type.” And yeah, the compiler can check it a little bit faster. It's a little bit better than unit tests in some ways. And obviously it can't do as much as a unit test can.

But the point is in Elm, you just don't have to do that. You actually can write out an Elm program that you don't have a single type annotation in it anywhere. And because Elm has type inference, the compiler will just still check it and will still verify that you didn't make any mistakes. You didn't try to pass the wrong type of thing to the wrong type of other thing. So, you can have code that is strictly more concise than TypeScript. And in fact, more concise than JavaScript because Elm's syntax is just generally more concise than JavaScript's. And yeah, it gives you a stronger set of guarantees. Because if there are any mismatches anywhere in there, the compiler will tell you about them right away.

Another thing I don't know about TypeScript that I do know about Elm is that another thing that has been a big influence over the UX of using different languages for me is compilation times. So, I remember definitely using some languages where it just took so long to compile the files that I just wish that it weren't doing that.

Even if it did give me a nice message when I made a mistake, it just wasn't worth it because it slowed down development so much. Elm's compiler is just lightning fast, though. When I was pairing with one of my coworkers, we went through. We made some big change across several files, changed a bunch of stuff. And we just worked through the compiler errors and then switched over to the browser and refreshed the page to check that it actually still worked once we got through all the compiler errors. And not only did it work but we were both immediately struck by how much slower it was to switch over and refresh the browser and wait for the page to load, even though it loads in under a second, than it had been to just compile each time, recompile and just look at the errors. It's actually faster. That's just a new experience for me.

It's that usually I'm used to it being an upfront cost, having a compiler that type-checks. But in Elm, compared to the browser, it's actually upfront time savings. The alternative would have been that we would have brought it up in the browser and gotten a runtime exception and then gone back and fixed our code. But instead, we were able to just get these lightning fast responses from the compiler and just fix them right away before we even opened the browser.

Another question you might want to ask from a more language-y design side is what is your type system for? Right, so I think in TypeScript it's more, we want to lower the burden of unit testing to some amount. Maybe we can [offer] that. Or maybe it'll be easier to refactor a bit. And in Elm those are goals of course. But we also, the way that the system is designed in Elm, you can think of it as when you need to test every code path in your program, that things go well, that's actually quite hard to do, to get 100% code coverage.

So, what Elm's type system is able to say is, given how data can possibly flow through this program, through these functions or these other functions, we'll never get to a case where something is used in an unexpected way. So, that means we'll never get to a point where I call a method on a number. And it's able to essentially give you 100% code coverage, guaranteeing that I'm never going to use this data in an unexpected way that causes a runtime error. And I think that not every type system has that as an explicit goal. Does that make sense?

I think it does, yeah.

Mmhmm.

Yeah.

Can you talk a little bit more about the ideas around how Elm uses signals to flow values through your program? I guess we haven't talked explicitly about signals. But it's a big part of the experience of using Elm and how you can write pure functions that still deal with interactions. Because everything's easy if all your data's in-memory and you're writing it back to memory. But that doesn't happen in the real world. You need to interact.

It's interesting because… so, from my perspective, signals don't feel like a big part of the Elm experience.

Oh, really?

I realize, yeah, that there are a lot of examples online. So, the way I got into Elm honestly was I had a side project and I was like, “I want to rewrite this in a better language,” because it had gotten unmaintainable. And I decided to use Elm. And the way I got started was I literally just ripped off the TodoMVC and then just rewrote the logic bits and just kept expanding it until I had my app working. So, I never actually learned how signals worked in Elm until months after I'd had this side project running in production. [Chuckles]

And I think that's, not only is that possible but I would personally recommend it. If you can just start building stuff in Elm before learning about the underlying concepts that make everything work, as long as you're okay with hand-waving that away and saying, “Okay, this is a thing. It's different from what I'm used to,” but if this allows the language to have these cool characteristics and here's some stuff I can just copy paste in, I think that's a perfectly legitimate way to get in. I don't necessarily feel the need to understand what my compiled bytecode looks like on the server. [Chuckles]

I don't feel like you need to know everything about the language on day one to get a lot out of it.

Yeah.

Having said that, Evan can definitely explain how signals work. [Laughter]

Well, so part of the guiding philosophy with Elm is that we want to gradually introduce concepts as they become necessary or interesting to users. So, we actually have this package called start-app that's able to just start a normal web app that does HTML stuff without thinking about signals at all. You say, “Here's my model. Here's how I update my model and here's how I view my model,” and the machinery of hooking that up to events in the right way is taken care of by the package itself.

So essentially, it lets you put off learning about signals for a little bit longer.

You know the nice thing about start-app real quick is that it's not doing anything terribly fancy.

Mm.

It's just getting rid of some boilerplate that you tend to want to do a lot. But if you decide at some point you're like, “Okay, start-app got me this far but now I want to do something crazier and more complicated,” switching from start-app to that would be very minimal.

Yeah.

Because you're already… start-app is just like, “If you're going to use best practices, here I'll take of some work for you.” But you were already using the best practices so you just throw out startapp and replace it with your typical boilerplate that we used to write for start-app and then modify it from there as you desire.

Yeah. So, the learning curve these days is really more like, what is the Elm architecture? So like, how do I set up a web app such that I can have independent components that are modular and I can share them around? I can test them. And getting used to syntax and getting into using map instead of for in some cases. So, that's really the first step. And I think you can, I've seen people get extraordinarily far without having to get into signals stuff too much. And I think Richard and I might actually be on the, more the end of the spectrum where we say signals aren't that important, which is also weird considering that's what my whole thesis was about. [Laughter]

But in the pursuit of that nice learning curve where you're just getting productive really quickly and feeling great, I don't think it's really crucial with modern Elm code. But…

Maybe that just reflects my learning style. I feel like I get antsy if there is some abstraction that I know is happening and I don't understand it very well. That's why monads [inaudible] in Haskell. I

try and do a thing and they're like, “You don't have to understand monads. Just type this code in.” And I just google monads for five days and then I stop using Haskell

I'm the same way. I can't stand that. [Chuckles]

I would hope that that is an unfair comparison.

Yeah, yeah. I know monad like a trigger word to you. Sorry.

Well, so yeah, so I struggled with that concept for, I don't know, I'd say six months or something.

I still don't understand monads.

And I was coming, when I was struggling with it, I was coming from a background of I had done functional programming in various realms for three-ish years by then. It's just hard. Where signals is more the key thing that was exciting about Elm in the early days. It's like, “Holy crap, we can get this interactivity with a relatively simple concept.” And so, the idea was I was making just a UI library. Essentially I was like, I really dislike that I can't vertically and horizontally center this picture. That bothers me. So, I was just making a UI library to make that easy. And I got to a point where I was like, I had Yogi and he was centered. And I was like, “Oh, this is cool.” And I wanted to interact with him. And I realized, “No. Oh crap. How do I make this change but keep immutability?”

And so, I had this realization of what if we had values that changed over time? So, what if the dimensions of the page just changed and that flowed through your program in the right way? So, you can think of a signal as a value that is changing itself as the world moves. And so, all of that propagates through your program and you don't have to worry about that. So, where you would have been writing callbacks or doing some sort of wiring, instead that flows through your program in a nice way. To get a little more detail-oriented, the way you can think of signals specifically is, I

have a value and whenever and event occurs, it might change. So, there are discrete points in time where it will update to a new value. And whenever that happens, it propagates through the system.

Is that an okay high-level description of how things are working?

Sure, yeah.

There's a lot of stuff you can read up about it, to get to the more, what are the practical implications of that? But honestly, it's definitely something that is, a topic you can spend a lot of time talking about but also a topic that you don't need to spend a lot of time talking about.

And it's also, there the history of this idea is quite contested in that there are a lot of modern reactive things that actually work very differently than Elm. So, if you are looking at Reactive Extensions or Bacon.js, the actual role of…

[Inaudible] JS.

Reactivity in those systems is very, very different than what it is in Elm. So, in Elm it's more on the very borders of our program. We'd say, “Hey, I'm getting these messages in,” and on the other side we're saying, “Okay, and I'm sending these messages out.” Whereas in a lot of the JavaScript libraries that are for reactivity, the wiring and streams of things goes through all of your codebase. And what I think is nice in Elm is that our core is just this foundation of functions and immutable values that are really, really easy to think about. Whereas if you start getting crazy with signals and streams, your code gets a bit out of control. And so, I've seen this happen with teams that are doing stuff that's like TypeScript plus Bacon.js plus React. And if you squint, that's kind of Elm. But if you look at what actually happens in practice, it's so easy to go off the rails and end up with some really crazy code.

There's a really great photograph that somebody came out with a while back. And it shows this guy who's got a big camcorder and a boombox and a typewriter and he's just surrounded by this pile of stuff. The idea is that this is all a bunch of stuff that we used to need, all of these separate big clunky things for. And now, we just have an iPhone. And from my perspective, that's what it feels like switching to Elm, is like JavaScript is asymptotically approaching Elm as far as reactive concepts and functional programming.

And it's like, “Well, if you do this in this way and you use this library for this and this library for that and make sure not to use these other things,” even with all that you still don't have an iPhone. You have a bunch of parts but they're not more than the sum of their parts. Whereas Elm because it's designed around these things, is more than the sum of their parts. It's more than the sum of just all of those ideas put together because the language has these internal synergies where it's designed for these things to work really, really well together in ways that they just can't and never can in vanilla JavaScript. And that's what's exciting to me, is it's not just about following these new ideas but it's about, do you have a language that takes these ideas and elevates them into something that's better than what's possible outside?

That's a really good point. I've been using a JavaScript library that strongly encourages you to write pure functions. But at the end of the day, there's nothing they can do, right?

[Chuckles] Yeah.

You can do whatever you want. You can go download Wikipedia in your callback and they can't…

Sure.

They can't stop you. But that gets back to the point we were talking about earlier about building these constraints into the language and how much more powerful that is.

So, that's kind of a segue into something I wanted to ask about which is I feel like we're seeing this same thing happening in JavaScript. People are in some ways trying to put Elm into JavaScript. And then I guess that's probably the wrong way to say it, but looking at the things that Elm does well, and these are obviously not, it's not like this is an invention of Elm.

Mm.

Functional Reactive Programming into JavaScript. And the places where we're seeing this most noticeably is in React and Angular 2. So, you had this concept or this statement about how JavaScript by itself, even if you do things differently doesn't quite get all the way there.

Yeah. And I say this as someone who co-authored a book on React. [Laughter]

So, I'm potentially causing myself royalty money by making that statement. But I believe it. So…

Well, another piece of this is that I was… if you think of the idea of, “Hey, this unidirectional data flow thing seems pretty cool,” or this big chunk of state, what do they call it? The Flux thing.

Oh, stores?

Yeah, the big store, all your information should be in one place. So, these are actually concepts that show up in my thesis before React existed in the world. I didn't use those terms. I used terms that fit the literature and community that I was working within. But so, when React first came out I was like, “Oh you guys.”

They might have read your thesis. [Chuckles]

I don't think so. I think it was a co-invention kind of thing. And they made some really cool advancements as well. And so, what was cool when that happened was I had confirmation that the world is moving in this direction as well. And I think when Richard says the world is converging on Elm stuff, it's with that historical context in mind where that pattern of unidirectional flow and a single store for your state, that all emerged naturally from Elm. And it wasn't like I invented those concepts. It was just like it happened because we started with these rules and guarantees.

So, another piece of this is about guarantees at the language level. So, let's say that a person makes an error at a rate of 1% per line of code. I don't know if that's a crazy number. And it's not about the person or what they're doing in particular. I think that percentage is related to the language you're working on. Like at what rate do you introduce issues into your codebase? And in JavaScript without breaking the whole internet, it's hard to reduce that rate of introducing errors. And there are a lot of projects that evolve JavaScript in that direction.

So, the StrongScript and I forget. There are two projects out of Google that are moving JavaScript more towards a type system and using the 'use strict' annotation so that you can have safe code within certain realms. And they're doing that partly for speed. But so, there is this general move of, maybe we can get to something that has nice speed characteristics, has nice maintainability characteristics. But the road to it in JavaScript is much longer. So, if you think of… like I still can't use flexbox in every browser without doing tricks. The road to that is going to be really, really long.

Yeah. I wish we could use flexbox, right?

We still support [inaudible].

That's sad.

So, going back to one of your statements. I don't know how much, again I don't know the history of React per se. But I do know that Angular 2 was heavily inspired by Elm.

Oh, I didn't know that.

I didn't know that either.

Yeah, it was very heavily inspired by Elm.

Okay. I need to look into that. That's awesome. That's really cool. We've started to hear here and there that Elm has been a part of different libraries or frameworks, which is really exciting. So, I always have to balance this, “Oh, that's mine,” with it's actually really cool to see these ideas getting used and making people's lives nicer. So, I have to be mature and be like… [Laughter]

This is good. This is good.

I actually had a funny experience this last week. My wife and I were looking at houses in the Parade of Homes. I assume there are Parade of Homes all over the country. If not, a Parade of Homes is the thing where there's a whole bunch of homes that have just been built. And you can pay $15 and you can go walk through them all and see them. And the people who built them are of course trying to sell you stuff. [Chuckles]

Anyway, it was very funny. We were looking through this home built by a builder. And my wife and I have been in the process of building our own house now for two years and still haven't even started digging. But my wife designed our house plan on her on. And she sent that house around to several builders. And we go to this house that looks very similar to our house by a builder who we had sent our house plans to a year ago.

Oh.

So, we had that same sort of feeling like, “Oh, they stole it.” And I said, “Whether they did or they didn't, this is like imitation is the best form of flattery,” right?

Yeah.

Have you asked if the builder accepts pull requests?

Oh, very nice.

Yeah, it's [inaudible]. So, I remember when React came out. I don't know the whole history of React because you have to have worked at Facebook for that. But I remember when it came out. My first thought was, “This seems great.” This seems like it dovetails perfectly with the programming in the style of stateless functions thing that I've been having good success with for the past couple of years. I want to jump on this. And I remember when… at that time, React was considered crazy and experimental whereas now it's I think pretty mainstream. So, we adopted it early at work and had a great experience with it.

And then when I started looking into Elm on the side and started using it more, subsequent to that, I remember thinking like, “Man, this is the way I felt when React came out.” This seems like a paradigm shift. This is just better in a way that is just on a different level than previous upgrades. You look at, previous to React you had like, okay, there was Ember and Angular and Knockout and Backbone. And all of these are variations on the MVC theme. And React was the first one that was clearly a paradigm shift. Like, “This is different. This is not in the same category as these other things. Maybe it's awesome. Maybe it's not. But it's definitely very different.” And I feel the same way about Elm. And hopefully we will also look prescient as early adopters of Elm. [Laughter]

In the same way that we now do for React. So, one of the interesting things that separates us too is that I remember with React there's a lot of… for as much as React simplifies things, there's still a lot of complexity there. So, around components, right? If you look at a component and you've got your render function and then the render function looks at state and props which work differently and play by slightly different rules. And then you have the whole component life-cycle and these different hooks at different times depending on when things are mounted and so forth. In Elm you just have a function called view. And it takes a model and one other argument and then returns your view. And that's it. And that's the whole thing. There's no component. There are no rules around how to find a component.

React has in the past I think three releases has changed how component definitions work if you don't use JSX. It's just a function. And not only is it just a function, it's a stateless function. It just takes arguments and then returns a value. And somebody mentioned earlier libraries that recommend avoiding side-effects. They say, “Don't use side-effects here or bad things will happen.” But again in Elm it's guaranteed. It's a stateless function for sure.

And one thing I want to emphasize about that is from a learning perspective there's a big difference between having best practices and having tooling that supports a certain style of coding. So, I found again and again in my programming experience that if you use Prolog for example to take a language that no one gets angry about necessarily. [Chuckles]

But it teaches you to think in a way that even if you understood the core principles you wouldn't get it just by doing them in JavaScript or Java or whatever other language. And so, I think there's some benefit to… in Elm you don't even have to say, “Oh, it's better to not have side-effects here.” It's just get into the habit of writing code that way. And that's actually something you can translate to JavaScript much more easily. So, I find that this advice of, “Oh, use a stateless function,” you can internalize it much more if you've been in a realm where it's just the thing you have to do.

One of my coworkers had a great term for this. And she said learning a particular framework is horizontal growth. You get more familiar with that framework but it doesn't enrich your understanding of programming, give you more techniques that you can use in other places. But learning a different paradigm like functional programming is vertical growth. Because not only does it teach you how to use this new particular tool but it also gives you new tools that you can then bring to other projects with different frameworks, different languages, et cetera. And it's definitely been true in my experience.

Do you still see a lot of parallels between the paradigm in React and the paradigm in Elm?

Oh, definitely.

Yeah, for sure.

They both use virtual DOM. It's definitely the same underlying rendering mechanism that is start with a representation of what you want the page to look like and then under the hood you'll delegate the act of actually updating the DOM. So in that way yeah, they both do that.

And we're starting to see libraries out there that bring the ideas from Elm to React in pretty direct ways. So, you can think of it as by taking away mutation you're just in a subset. So, the things that you can do in Elm you can also do in JavaScript. Perhaps you also lose those guarantees, the guarantees of having the subset. So, you can still do the same kind of stuff. And React is quite close. So, in Richard's case his transition both with the project he first started on, the side project, and at work was going from jQuery and CoffeeScript to CoffeeScript and React to Elm. Is that right?

Yup.

What's really cool about how Richard did this is he always is really good about finding the small non-invasive way to get a better thing. So, by taking each of those steps, each transition is actually pretty smooth. Just going from jQuery to React isn't so crazy. Going from React to Elm isn't so crazy. And so, any changes you need to do or learning you need to do happens in a really gradual way. So, I think a lot of people are going to be taking that route who are getting into Elm. Or course, I prefer they just start with Elm.

Yeah, but everybody's got an existing codebase, right? You know.

Yeah.

They can't all be greenfield projects.

One of the downsides of Elm is that it's a smaller community. It's like the weird interloper in JavaScript. Even though it's inspiring a lot of people, there's nowhere near as many people using Elm as there are using React or just JavaScript in general.

That was React when it came out.

That's true. But I mean…

But we are there right now. That's totally true.

How do you get around the problem that a lot of common problems have been solved for you in JavaScript and you have to solve them yourself in Elm? Because right now I would say that's our team's biggest concern about Elm, using it more widely in our apps is we'll just end up writing a lot of library code.

Ports.

Yeah, so Richard can say more in that in integrating Elm into various projects, there's a feature of Elm called ports which lets you send messages out to JavaScript. JavaScript can do whatever you need it to do and send messages back. So essentially, you're able to communicate with some JavaScript piece of code, whatever that code happens to be. And it can do side-effects and whatever crazy things you need. And it just sends a message back into Elm. And so, Richard's used that I think for everything.

Yeah, since day one. Yeah, so that's another example of where things are a little bit less familiar but they still totally work. So, the most recent feature I shipped at work was a really big complicated… so, I work at an education company called NoRedInk. And they've been writing software for English teachers. And we're hiring by the way.

And this particular form is a way for teachers to create assignments. And there are all these different crazy parameters. They can make it a practice style. They can make it a quiz style, pretest, post-test. Each of those has all sorts of different implications. There's a start date and a due date. There's a bunch of different topics they can filter through. And two of the particular features that we needed on this page that needed to interact with all this craziness are: one is a date picker.

And we wanted specifically a date and time picker. So, we didn't want to just delegate to the normal HTML 5 stuff. We really wanted a third-party. And nobody wants to write a date picker themselves. Come on.

And the second thing that we wanted was full-text indexing for the list of topics, because we have hundreds of topics. So, we have a little search bar on the page that let the end user search for it. But that didn't go the server. It was just like, well they're already all there on the page in an accordion, all several hundred of them but Elm's fast at rendering so that's fine. But the question was, how do we use this third-party date picker and this third-party full-text indexing, specifically Lunr.js, L-U-N-R dot J-S is the one we used. Then we actually used a jQuery date/time picker for the date picker.

And basically the way ports work is what Evan said. So, you get to a point in your Elm program where like, “Okay, cool. Now it's time to show the date picker.” The user has clicked on this thing. We want to bring up the date picker. And what you do is you say, I want to send this message to a port that says, “Hey, show the date picker.” And then on the JavaScript side, you just write a little bit of connective tissue, a little bit of glue code and all that code does is it literally calls… so, you have your Elm code that you've instantiated and it's running. You get that in a var. Then you say, so you have this var called 'app' and 'app' has a field called 'ports'. So, you say 'app.ports.subscribe' or 'app.ports.datepicker.subscribe'. You give it a callback function and just write whatever you want in that callback function. So, you can invoke the date picker. You can do whatever you need.

Yeah.

So, using that, it feels like normal client/server interaction where you're just like, you have this pub/sub method where Elm is sending stuff to JavaScript. JavaScript can send stuff back to Elm. So then, the user clicks on the date in the date picker and then JavaScript sends back to a port in Elm. And yeah, it works.

Yeah. So, Richard's been extremely good at picking the right battles to fight. So, he's really good at saying, “Okay, ports will work here.” And for a majority of cases, ports is what you need. I'm actually working on a way to do tighter integration to JavaScript stuff. I don't know what the exact timeline is on that. But if you want some really crazy kind of integration I think that's going to be in the pipeline. But I generally feel that folks who get started using Elm so far haven't had showstopper issues because of integration stuff.

Yeah, that's the thing is that the worst-case scenario is that you end up writing more JavaScript. [Laughs] Like, you end up writing out to a port and you're like, “I don't know how to do this in Elm,” or, “There's not a library for this in Elm yet.” And you just say, “Okay, well let's fire off at a port and just write some more JavaScript code.” And then that's no worse than your status quo, you know? [Chuckles]

Or CoffeeScript. Actually, when I say JavaScript I generally mean CoffeeScript. [Laughter]

I like CoffeeScript.

How very uncool these days.

I was going to say the haters are going to come out now.

That's fine. I also wrote a blog post on how ES6 is not a replacement for CoffeeScript. So, bring it on.

You mentioned this new integration with JavaScript coming. Do you want to talk a little bit about other upcoming features in Elm?

Sure. So, I think we're at a point where adding features isn't really a thing we want to do. [Chuckles] So, the language itself is going to be pretty stable. We might be removing some syntax that's not very commonly used. In terms of tooling around the language we actually have a lot of cool stuff we want to do. So, one example is our debugging stuff. We just had an intern working with me this summer on Elm Reactor. So, this is our time traveling debugger. So, you can go back, take any program and rewind it and replay what happened. So, he's actually working on a… well, he was able to implement a thing that we're calling export session. So, your QA person can find a bug and then just export exactly what they did to you and you don't have to reproduce the bug. You have the reproduction.

Not only that but then if you change your code, in some cases it can actually replay it with your changed code.

Yeah, so you can just…

You can make sure it's fixed.

Yeah. So, you can easily test. So, working on debugging stuff. We have some ideas of how to… our package manger already has some cool stuff in it but we have some ideas how to make it even nicer. So, right now it'll do automatic semantic versioning. So, if you release an API change we're able to detect, “Oh, that has to be a major release.” Or if you just add as function, we know, “Okay, that's minor. That's fine.” And so, we have some ideas of how to make improvements there. But generally speaking, I'd say the core concepts of the language are… I don't see them changing very much. And most of the work will be, how do we make testing better? How do we make debugging better? So, the tooling around that.

So, that's an interesting segue. What's testing like?

Richard can probably say.

Yeah. So, the main things that I use are Elm-Test and Elm-Check, Elm-Check being a library for Elm-Test. So, there's basically one canonical testing framework. It's definitely more preliminary. I wouldn't say it's at the same level of polish as a lot of the rest of the stuff in the language. But it works a lot like RSpec or Mocha in JavaScript, Jasmine, what have you. You basically have a suite of tests and they run.

And then it reports whether they succeeded or failed. It runs on Node so it's not designed for inbrowser testing. Because if you want to do in-browser testing all the tools you already have work the same way. So, if you have Karma or Selenium, anything like that, there's no change. You just take your compiled Elm code and put it on the page and write your integration test. But for unit testing, basically Elm-Test gives you the same sort of framework that you would have, except that everything's stateless and the compiler will also check your tests and make sure that they don't have any errors, which is nice. And of course then you can access the whole Elm package ecosystem from within your tests.

So, I would say the testing stuff is adequate. And it'll work well. But it doesn't… I haven't gotten the chance to give it the polish that I have for a lot of the other parts of Elm.

Evan's spotlight of awesome has not been trained on it yet. [Laughter]

Yeah. So, I think we'll be… we have some really cool ideas of how to make it maybe the best testing thing that's out there. So, I'm excited to work on these projects in the coming months.

That's so funny. “I'm really sorry it's only adequate.”

Yeah. But it's totally fine. We use it. We get the tests running on Jenkins just right alongside our other tests. Elm-Check is pretty cool if you're into property-based testing or fuzz testing or probabilistic testing. And there's a bunch of different terms for it. But basically it randomly generates a bunch of data and then gives it to your test and runs your test a hundred times.

Yeah. So, it's a way of saying, “Yeah, but did you think of this?”

Yeah.

It'll find the list that has a zero. And then…

Right, what happens if you give it zero? What happens if you give it negative numbers? Things like that.

Yeah. So, it'll find the corner cases you didn't think of in the unit tests you wrote. So, things are alright.

So, I asked this in the chat and Jamison gave a whole bunch of answers. But I'm curious if you can tell us any websites that people have in production. I know that NoRedInk is out there. But other applications too that are built in Elm that are out in the world in production.

So, I know the company CircuitHub, they use it for some of their diagrams. There's a German company that I forget the name of, but they're using it for some internal tools. There are about five companies total that are using it for, two I know that are using it for user-facing production stuff and the others are doing… one did their 404 page or doing internal tooling kind of stuff. And I have the suspicion that there are actually quite a few more companies out there that just haven't told me about it. Every once in a while someone would be like, “Oh, I just pushed this to production.” And I'm like, “Wait, who, what? What?”

Yeah.

But yeah, so I'd say those are the bigger ones.

Certainly Prezi's making a big investment because they pay this guy full-time to do nothing but work on Elm. [Laughs]

And at Prezi we're starting to get there. So, one thing that I've also noticed is that the teams that have been the earliest adopters are smaller teams. So, teams of five. And what this typically means is you've got someone who gets what the path will be to using Elm and is able to communicate that well to their whole team. And at Prezi we have bigger teams. So, even if everyone on the team is into it, there are institutional things that make it hard to make that transition. But we're starting to see the same path from some kind of JavaScript to React and TypeScript and then having those Elm influences and hopefully getting to writing Elm in the frontend. So, our website team is actually doing some changes and re-architecting of stuff. And already they're using the Elm Architecture to set that kind of stuff up. And I think the next project they do will be in Elm. So, we'll see. We'll see.

Yeah. The other question I had is, you mentioned start-app before and you put that out there as a good place to get things rolling. Is that where you recommend that people get started with Elm?

I would get started with the Elm Architecture. So, that one's written essentially as a series of eight examples of small apps. So, it goes from a counter to a pair of counters to a random GIF getter to a pair of those, to a list of those. So, it walks you through from what's the literally most basic program you could write to let's do some HTTP stuff. Let's do animation. And to supplement that, it'd be good to check the docs. There's a guide to Elm, the complete guide. The first two chapters of that get into what is the basic of syntax and then gets into, what are the key ways of thinking in a functional way? And both of those are really key foundational things that'll help you out a lot. But I

think you can start with the Elm Architecture and go pretty far.

So, I guess the other question related to what I asked previously was, is there some kind of canonical app that people tend to build with Elm? Like people use chat apps or other apps to build Node and things like that.

I'm not sure. Do you know?

Yeah, I don't know if there's a canonical one, though. There probably should be though. [Chuckles]

I had a friend make Snake, like the game.

Oh yeah, yeah, yeah.

He started with that.

So, earlier in the history of Elm, games became easy before web apps became easy. So, something like Snake would have been the canonical one. I guess something like TodoMVC is more the typical one.

So, I'm working on a blog post that might be out by the time this airs, actually. So, maybe I should use the past tense there. But basically about a live-validated sign-up form that goes and checks all your form inputs and then goes and checks to see if your email address is taken, things like that, or your username is taken, with Ajax. Because that's something I've build a lot. And I know that it's not like the coolest thing in the world but it's definitely practical because I've built that a million times before. [Chuckles]

Yeah.

And it's always different in a very different library, framework, what have you, combination I've used.

Yeah. And if you could [inaudible] I guess when you're doing general frontend HTML interactive apps, I don't know if there's a stand by canonical one. I feel like…

It seems to vary over the years. Twitter was a thing for a while. I've seen it be different things at different times.

Yeah. So, hopefully that answers the question.

The answer is that right now there is not a canonical one.

Yeah, short version.

But maybe there will be one after I write this blog post. [Laughs]

Well, at least people have some ideas.

Yeah.

What about community? Where do you find the heart of the Elm community and find other people to talk with about Elm and get questions answered?

So, I'd say right now the core is on the Elm Discuss mailing list. And there's a really nice meet-up we do in San Francisco for people who are around. And I think those are the key ways that we talk about ideas and help people out. I'd like to get reddit more lively or try to migrate some of Elm Discuss to reddit. We'll see how that goes. But I'd say that's the core ways of getting in touch with people. And the list is super nice. People are happy to help. There are folks like Hassan who's just super smart and makes great packages and is extraordinarily helpful. I can't thank him enough for how helpful he is on the mailing list.

I am blown away by the level of detail I've seen in responses.

Yeah.

Where someone will post a newbie question and then the response will be five times as long with code sample and “Here are different ways you could do this. Let me try and help you understand…”

Yeah. He's so good. He's so good.

“Why you suck on this.” Yeah. Hassan, Jeff, Max. There's just a ton of awesome people.

Are you seeing much on Stack Overflow yet?

So, this is something that we're sort of… I'm not sure when the right time to start putting stuff on Stack Overflow will be. I guess you can mark questions as old.

Yeah, [inaudible].

But we have this concern that if we had started using Stack Overflow a year ago, essentially all the questions would be trash because it'd be like, “Hey, how do you solve this problem,” and then there was a release of the language that solved that in a coherent and nice way. And so, we have this tension of, at what point do we want to start making this the top Google search? And will that be good or bad long-term? So, I know people do ask questions there now these days.

Oh yeah. One of the other cool things that just came out, speaking of tooling and new resources, the Sublime Text plugin just got a major overhaul thanks to Texas Toland. And I've got it running on my laptop right now. It's really awesome. If I just make a mistake and I just press the build button, not only does it pop up the error message and display it right inline, but it actually even highlights inside my code where the error was so I don't have to go find the line number and things like that.

It's just like, “Here you go. This is your problem, right here.” It's pretty cool.

When was that?

I think that actually just came out Monday?

Monday, yeah. [Chuckles]

Monday the 17th. August 17th, 2015.

Yeah. So, very recent. The last compiler release laid the groundwork for these kinds of tools. And they're coming out and it's awesome. It's really cool.

Yeah. It also tells you about unused imports. So, ES6 has a modules that lets you import stuff. Elm

has a similar thing. But now right in Sublime when I hit build it says, “Hey by the way, you're not using this import anywhere.” And I say, “Oh, cool. I can definitely delete that line of code.” We're definitely the type of shop at work where we celebrate when we make pull requests that are more deletions than additions. So, it's nice to be able to have something that helps me find ways to delete code. [Chuckles]

Right, right. Just out of curiosity, Elm isn't JavaScript. But just curious is WebStorm has talked at all about putting in support for Elm.

Not as far as I know. I think this is mainly community-driven tooling right now. I think that the closest we've come to that, I know that Texas talked to, Panic makes it. It's…

JetBrains?

No, no. Coda maybe? Is that true? It's an IDE or an editor that I don't use. [Chuckles]

But he talked about, I used Sublime Text, but he was talking to them about doing integration. I think it's also…

Yeah, it's Coda.

Okay, yeah. He's also started working on improving the Atom integration. I know that there are other people who've done crazy things with the vim integration.

Yeah, yeah, yeah.

That they're really impressive. But yeah, it's all very community-driven right now. I don't think honestly that Elm is big enough to attract the attention of a big enterprise IDE yet.

You know you're big when JetBrains writes an editor for you.

Right, yeah, exactly.

That's when you've made it.

But that's understandable from their perspective. There's not enough of a market. It's an emerging technology. It's not an established one yet.

And it's been cool to see these community projects pop up and see people keep doing things that I just didn't know were possible. Like the time travel debugging is an example of this where just, I didn't realize that was a thing we could do until someone was just like, “Hey, check this out,” and I

was like, “Holy crap.” [Laughter]

I think there's… when building a healthy community it's actually quite cool to start seeing these projects come up and people getting to make really awesome stuff and own that in a real way. So, I'm really happy with how far our tooling has come just with the community stuff.

Right. I noticed that there was a Webpack loader for it. So, we're seeing a lot of stuff. [Chuckles]

Yeah. So, I wrote grunt-elm, like a Grunt integration. Somebody else wrote a Gulp integration. And I wrote the Webpack loader basically because I wanted to try out Webpack. But that one's not nearly as robust, as the Grunt one I think is probably the most robust because I used it a lot for Dreamwriter. We also at work, so we've got a Sprockets integration. We have not gone all the way through to making that a gem yet. But there's a little gist that if anyone wants that, I'm rtfeldman on Twitter and just ping me and I'll send you a gist. [Chuckles]

But what's interesting is I think we're definitely seeing more companies and people checking out Elm. And so, we're at this really cool time when you can make a super important project for this community in the next two or five or ten years. Because it's right at that time. So, I think we'll look back in a couple of months and be like, “Oh yeah, remember when we didn't have…”

Right.

That in our editors?

Remember when we didn't have Elm-Test?

Yeah, yeah, yeah.

Right.

Yeah. I ended up actually working with the guy who wrote Node-Inspector and it was funny because way back then, when he wrote it Node was nothing. And he wasn't even developing in Node full-time. But he just went and wrote Node-Inspector. And it was pretty funny. A year later he was still not doing Node full-time and people are like, “You wrote Node-Inspector? Holy cow.” [Chuckles]

Yeah. Elm's at that point right now.

Yeah. And it feels like we're starting to get those kinds of contributions where it's like, “Oh man. That's…” [Chuckles]

Like, people optimizing their workflow. It's really cool. It's a very cool time in Elm world.

Awesome.

Alright. Anything else before we get to the picks?

Oh, I have 55 million questions.

[Inaudible] have us back.

Yeah. [Chuckles]

Yeah, we might have to.

It's been fun.

Yup.

I'd definitely come back.

Yeah, if we have enough more questions, definitely.

Alright. Well, before we get to picks, we'll give a quick shout-out to our silver sponsors.

Alright. Aimee, do you have some picks for us?

Yes. So, my first pick, I started to look into Elm a little bit this week. And two, or [inaudible] because this is actually just one of the resources that I found really helpful, was by Pragmatic Studio. So, I will put a link in to them. It's just a very, very, very brief tutorial. Of course the documentation on the Elm website was also really good. But this was also something else that I found to be a really good little five, 10-minute starter article on it.

Yeah. I actually worked with the guy who runs that. And he did a, what's it called, videocast?

Screencast?

Yeah.

Yeah, yeah.

Screencast.

That also was really, really helpful.

Yeah. So, he and I worked through some of the content to make sure it was a really nice intro course. So, that stuff is really good.

Yeah. I just can't stress enough, I guess for any other newer-ish people out there, how approachable this seemed. And it seemed like a really, really a beneficial thing to start looking at. So, if all you've done is just plain old JavaScript so far, I think it'll be really helpful to start with maybe some of this.

Awesome.

And that's it for me.

Alright, Joe. Do you have some picks?

I would like to pick Elm. [Laughter]

I guess it's fair game, right?

Yup. I think it's super cool. I've been messing around with it for a while now. I think it's awesome. And I'm very interested in this correlation between Elm and the frameworks that we're seeing and things we're seeing happen nowadays in JavaScript. And even though I have picked it, feel free, anybody else who wants to, to pick Elm. [Laughter]

And then for my second pick I'm going to pick a board game I've been playing with my kids called Student Bodies which is a zombie survival board game. But unlike other zombie survival board games where you work together, in this one you are trying to be the only survivor. And when you get out the door then you lock it behind you, and so tripping your opponents while you're running around and pushing them into the zombies is all fair game. So, that's my second pick.

And I will second Aimee Knight's pick, the Pragmatic. They have some really cool stuff in their video, tutorial's actually really good. And who knows? Maybe sometime in the future we'll see a video tutorial on Pluralsight. Wink, wink, nudge, nudge. [Chuckles]

Awesome. I've got a couple of picks. The first one is Angular Remote Conf. I believe I've mentioned it on here before. But I am working on pulling together a remote conference for Angular developers. It's going to be September 24th, 25th and 26th from 12pm to 4:30pm Eastern Time. I know that makes it hard for people in the South Pacific, Australia, et cetera. But I have to pick some part of the world that it's just not going to be convenient for. And so, this time yeah, I opted to have it in the evening for the people in Europe.

And we also have an Angular podcast on this network, Adventures in Angular. And you can get that at AdventuresInAngular.com. Joe is actually on that show along with John Papa and Lukas Ruebbelke and Ward Bell, and John's daughter Katya. So, we have a good time talking about Angular over there.

That's Joe's daughter, Katya, not John's.

Oh, did I say John?

You did.

Yeah.

She's related to Joe, not John.

And then in the course of building the thing, I've really liked working with Stripe so I'm going to pick Stripe. Their API is really awesome.

And then I've been listening to a book or a series of books on Audible by Brandon Sanderson. The first one is 'Alcatraz versus the Evil Librarians'. It is hilarious. Really enjoyed it. I've just decided to give in and read all the rest of Brandon's books. So, those are my picks.

Evan, what are your picks?

I'm on a reading kick. I'm trying to decrease my time spent on the internet. So, my two are going to be books. The first one is 'Understanding Comics'. And I wasn't much of a comics person but this book just revealed that whole world to me in a really cool way with lessons about how to communicate in a presentation or in person. It was just extremely insightful, really cool book.

And the second one is 'The Glass Bead Game' by Hermann Hesse. I just love that book. It's a really nice German buildings [inaudible] book. That was really interesting.

Alright. Richard, what are your picks?

I've got three. The first one is 'The Design of Everyday Things' by Don Norman. This just totally changed the way I thought about usability from all sorts of things. The first chapter is the usability of doors and [chuckles] how…

Yeah, that book is awesome.

The user experience about using doors. It just gets wilder from there.

Yeah, like the configuration of the dials on an oven. I'm like, “Oh, yeah.” [Chuckles]

Yeah, it really changed the way I looked at the world and made me a much better design… made me much better at designing user interfaces.

Pick number two is 'Simple Made Easy' which is a talk by Rich Hickey, which just fundamentally changed the way I thought about programming. He basically draws a distinction between the word simple and easy and talks about how easy things are those that are near at hand and are familiar and comfortable and easier to pick up. Simple things are more about the opposite of complex and how in programming we often reach for the easy thing to our detriment when really what we should be looking for is the simple thing. The simple thing's going to be more maintainable and give us a better time in the long run. And after following that, that's probably the thing that started me off on the road to functional programming that eventually led to my picking up Elm. So, it seemed appropriate for this podcast.

And the third pick is our company blog, which has been getting more and more hits and more and more awesome. It's just NoRedInkTech.tumblr.com. And we basically write about all sorts of programming stuff. Elm, JavaScript, Ruby, and general design stuff. A lot of stuff on there. So, check it out.

Alright. Well, thanks for coming gentlemen.

Yeah, thanks for having us. That was fun.

And thanks to our panel, too. That was a great discussion. And hopefully we inspire some people to go check out Elm.