JavaScript Jabber

JavaScript Jabber is a weekly discussion about JavaScript, front-end development, community, careers, and frameworks.

Subscribe

Get episodes automatically

229

229 JSJ Elm with Richard Feldman


TOPICS:

1:13 No Red Ink is hiring; Richard’s book-in-progress

2:10 Frontend Masters Workshop

2:55 Elm’s primary function

5:10 Using Elm over using Haskell, React, Javascript, etc.

9:15 Increased usability of Elm with each update

13:45 Striking differences between Elm and Javascript

16:08 Community reactions to Elm

20:21 First Elm conference in September

22:11 The approach for structuring an Elm app

23:45 Realistic time frame for building an app from scratch

32:20 Writing pure functions and immutable data; how Elm uses Side-Effects

38:20 Scaling a big FP application

44:15 What Javascript developers can take away from using Elm

48:00 Richard on Twitter

PICKS

“In a World…” Movie

Building a Live-Validated Signup Form in Elm

Apple Cider Vinegar

CETUSA – Foreign exchange program

This episode is sponsored by

comments powered by Disqus

TRANSCRIPT

Charles: Hey everybody and welcome to Episode 228 of the JavaScript Jabber Show. This week on our panel, we have Aimee Knight.

Aimee: Hello!

Charles: Jamison Dance.

Jamison: I’m here!

Charles: Don’t podcast and drive, right?

Aimee: No, he’s skydiving, remember?

Charles: Oh, that’s right. Don’t skydive and Skype. I don’t know. Anyway, I’m Charles Max Wood from Devchat.tv. A quick shout out to Angular Remote Conf and React Remote Conf coming up. We also have a special guest this week and that’s Richard Feldman.

Richard: Hello.

Charles: Do you want to give us a brief introduction? We haven’t had you on for a while.

Richard: Sure. I work at [00:07:00]. We are hiring and recruiting people. We started using React when it first came out and then we also have recently gotten very into Elm. As far as we know, we have the biggest Elm code base in production of anyone. It’s like 36,000 lines of Elm code at this point. I’m writing a book, Element Action from Manning publications. That’s available for early access and I’m doing an Elm Front-end masters workshop in September. That’s like two days long.

Charles: Very cool. Just on the side, if you are interested in that Front-end Masters course, you can actually watch them live if you’re on their mailing list, they announce them and then you can pay to be around when he actually gives it as opposed to watching it off the bat. If you can’t wait, then go to Front-end Masters and get on their mailing list.

Richard: Also if you want to ask actions in real time and stuff like that.

Charles: Nah, nobody does that. We did a show on Elm. We had you and Evan on, what, a year ago?

Richard: Yeah, something like that. It was like September 2015. Back when Evan worked at Prezi. Now, he works with us.

Charles: We got you early.

Richard: Yeah.

Charles: Actually by the time this releases, we’ll be about right. Do you want to kind of give us a quick introduction to Elm and then people can go listen to the other episode if they really want to get a deeper discussion about it then we’ll probably dig in to some other areas around Elm?

Richard: Absolutely. Elm is a compile to JavaScript language. It’s completely functional. It’s not object oriented at all. Everything in Elm is immutable, everything—no functions have side-effects. It’s just basically stainless functions and immutable data and that’s the whole language.

It’s built to be really awesome at being a functional language and probably the biggest selling point is maintainability. In that year that we’ve had element production, we have not gotten a single run time exception from our Elm code. That’s still true, we’re still waiting for patient zero. It’s just the compiler is really, really good at identifying potential bugs and catching them before they can impact our end users. That’s even though we refactor our Elm code probably like three or four times as frequently as Refactor or JavaScript or Ruby code. Every time we do it, we make these big breaking changes and then the compiler says you forgot this, you forgot this, you forgot that. When it compiles, it typically just works with no regressions.

The degree of maintainability we’ve gotten out of our Elm code compared to anything else we’ve used before has really been just unparalleled, it’s been great.

Charles: I know that Jamison is a big Elm user as well.

Aimee: We did talk about Elm a while ago and I have played with it a little bit here and there. I actually, with my mentor, I was looking at some—we were kind of doing this thing where we’re comparing JavaScript to Elm to Hasco. I can’t remember, I don’t think we really got into details on the last episode. Why would someone if they are wanting to go from React to something purely functional, why would they go to Elm versus going all the way to something like Hasco or PureScipt? Do you want to talk about that?

Richard: Sure. I would say—Hasco the way you would use Hasco the browser is there’s something called GHGJS which compiles Hasco code or some sort of Hasco code to the browser. Basically, the answer that I would give is basically user experience. It’s true that all three of those are functional programming languages.

I think users of all three languages would agree, Elm is the most focused on user experience. It’s not just that it catches these areas, but it’s that the compiler really has had a ton of work to put into it to make it so that’s these areas are user friendly, so that they’re helpful to you and you can look at the area and say, “I understand what the problem is as much as the time is possible.”

It’s not just enough to say, “This is what’s wrong.” It’s to say, This is what’s wrong in a way you can say, “Now I understand what I need to do to fix it.” People who use Elm and end up on one of those other alternatives like PureScript or GHGJS, typically what they are looking for is basically the more hardcore functional abstractions. They look at Elm and they say, “I understand that this will make my code safe and reliable but I want more abstraction. I want more ways to express things in ways that—Elm’s philosophy is more like let’s focus on simplicity. Just not having abstractions unless we really think they’re going to add a lot of value and focusing on sort of the minimal set of what makes functional programming pleasant to use, what makes it reliable, and not so much asking the question how can we add more abstractions but rather asking the question what abstractions do we not need. What’s the minimal set of abstractions that’s going to get us to a good user experience?

I think if you love abstractions and you want more, that’s probably why you would choose something like PureScript of GHGJS over Elm. If you’re more interested in just base line user experience, you’re probably going to be happy with Elm.

Jamison: I’d like to give a perspective on that too. It seems like to me, Elm is the first language—there are a lot of other languages in this space like you said, there’s the Hasco, JavaScript stuff, there’s PureScript, there’s a few others. Elm seems like the first one to achieve some degree of mainstream success. I think that is because of its ruthless focus on user experience.

The people that come from Hasco miss things and the people that come to JavaScript have a much easier time learning it because it’s missing those things that the people that come from Hasco miss. To me, it feels like Evan’s made some pretty wise design choices to say, “Yes, you can have these abstractions, there’s a cost to every abstraction. We want to focus on the things that will provide the most value while still making this appealing kind of the broad mass of developers not the people who are hardcore like what you said.

Aimee: It makes a lot of sense. The experience I had and again I did not go very deep to Hasco and I was just reading code and not writing it. I was honestly very surprised as we were comparing them. I compared JavaScript to Elm to Hasco, there was a bigger gap between Hasco and JavaScript but it wasn’t so big that I couldn’t grasp what the code was doing. Whereas like the Elm code did look a little bit more JavaScript or a little more of those but yeah I’m sure it’s much easier to get started in.

Charles: Has that story changed much over the last year? Has it gotten easier? Has it gotten harder?

Richard: I would definitely say it’s gotten easier. Actually with every release, Evan makes more and more improvements to the usability of the compiler and the detail of the error messages. Literally, right now in my inbox is an update on a job issue where Evan is posting screenshots of ways in which he improved compiler messages for the next release like 0.18 Elm. It’s like both trying to zero in more on just giving you the minimal set of information you need to reproduce the error and trimming away the excess stuff off that’s just noise and also adding more hints with links to here are ways that you can potentially resolve this error. I don’t see that changing really because like Jamison said, a huge focus of the language is usability.

Charles: What has changed over the last year?

Richard: The biggest thing is Elm 0.17. It switched away from the previous sort of foundational idea of the language I guess. Everything was based around signals and FRPs, Functional Reactive Programming. I guess everything up till 0.16 based everything around the signals and 0.17. Instead, everything is based around the Elm architecture, sort of the history of how that happened is that basically Evan had these ideas for—if we designed the language for building user interfaces and it has these characteristics like everything is immutable, all the functions are pure, stainless functions, then certain things will be very reliable and nice to use then we can sort of build in a good way.

He also had some ideas about how to make a seat really reliable. It’s reduced a lot of the error prone problems that come with other state management systems. As it turned out, signals were a way that had a lot of history and a lot of papers written about it so it made sense as a good starting point. But over time, as people started building more and more applications, it sort of revealed that there was this really common pattern for how people use signals. Pretty much the best way to design your application was to use these signals in a particular way which Evan called the Elm Architecture.

At some point, it became clear that signals had gone from this usefully flexible, abstractions to just boiler plate where you can end up doing something worse than the Elm architecture very easily. Evan said, “Okay, what’s the way to get the best user experience?” The answer was just to make the Elm architecture the fundamental unit. Just have the compiler focus on that and just take signals out entirely.

This is a usability win for several reasons, not least of which was that when beginners were learning the language, I mean I saw this over and over again, signals were just the most difficult part to learn of it. It was just the thing that most people struggled with as beginners. Not having to learn that instead just learning here’s how to architect your program and having that be the first class thing not only reduced learning curve but also made it so that it unlocked additional sort of tooling and capability options that are even now just still in the process of being explored because there’s so many different things that can be done now that they don’t all have to be done in terms of signals. I would say that’s the biggest change that’s happened in the past year.

Jamison: Can you talk a little bit about how the community reacted to that change? My impression was Elm 16 was kind of an inflection point where a lot of people who hadn’t looked at Elm started hearing about it and started looking at it and there can be some temptation then to try and capitalize on success. Making a pretty major breaking change in some ways goes against the common wisdom of like we need to show people that this is dependable and that they can built in on top of it and it’ll work for them, can you talk about the thought that went into kind of managing the community throughout this decision?

Richard: Yeah, definitely. It’s interesting that you mentioned assuming that it’s dependable. One of the most striking differences between Elm and JavaScript is the feeling that you get when you need to make a big change to your code. To me, a big part of the dependability of Elm is the fact that I can make a big change like that and have my code still work afterwards just because the compiler found all the potential problems.

In JavaScript, if you’re like, “Hey, we changed the semantics of how functions work and now they’re defined in a totally different way or objects or prototypal inheritance.” If JavaScript made—TC-39 comes out with this crazy new thing and it’s radically different, I’m really scared to change my code even if I have really good test coverage, I’m just really scared that I’m going to forget something and there’s going to be some unintended consequence.

Jamison: It’s going to break your tests. You’re doomed.

Richard: That’s true. First, it’ll break my tests. Then I have to fix my tests, hopefully I do a good job fixing my tests. But then there’s always the question of like, “Did my test account for this possibility?” Even the 100% code coverage, that just tells you all the code is being exercised like some test is running it. It doesn’t tell me that it’s actually checking that the logic is sound.

I’m just scared to make big changes like that in JavaScript. But in Elm, I’m just not. I feel fearless in a way that almost feels like it ought to be irresponsible except that it’s just never in practice. I just keep making big changes like this would be nicer if I change this API and make this big breaking change to my code and do this overall. And then afterwards I’m like, “Oh yeah, it’s nicer and it also works. It didn’t have a bunch of regressions.”

A big upgrade like that from 16 to 17 is kind of the same thing where it’s like, on one hand depending on how your code was architected before, that could have been a very large change. I think that’s where most of the people in the community reacted one way or another depending on how their code is architected. As far as dependability goes, it’s almost like an exercise and demonstrating one of Elm’s strengths which is that you can upgrade from one totally different paradigm to another and actually have it end up and everything still works.

To your question of how did the community react, I think basically people broke down into three camps. One was people who were like—that’s been already using the Elm architecture and then been using signals instead of the recommended way, the sort of best practice way. They were like, “Oh yeah. This is going to be nice. Obviously, why do we have this boiling point? Let’s just get rid of it.”

Two was people who had been using signals in unusual ways in sort of going—deviating from the Elm architecture. Of course, their reaction was more negative.

Charles: You broke it, right?

Richard: Yeah it’s like—I mean of course, it’s a breaking change. It’s got to break stuff for everybody but the question was more like, “What does the process look like of transitioning from what you had to the new version of the compiler?” If you start with the Elm architecture, it’s a pretty mechanical change. I remember going through it. Honestly, a huge part of what I was changing was just like deleting arguments from functions because I need to pass addresses around anymore.

If you were not doing that, then you had a more serious architectural change to make and a lot of people were understandably are not pleased about that. They didn’t want to have to make an architectural change.

The third group of people is basically beginners who were overwhelmingly across the board just relieved because they’re like, “That’s great. Whenever I looked at the signal stuff, I was really intimidated by it and I didn’t know how I was going to get through that learning Elm but I’m really relieved that now I don’t have to.”

As far as managing the community aspect of that, there’s a lot of just—especially on the Elm’s Slack that’s like Elm.broker.com if you want to get on that—there was a lot of people just saying, “Hey, this broke my Elm code, what do I do?” Other people say, “Can you paste me some code snippets let’s see if we can figure out how to refactor what you’ve got into what works in the new world?”

On the one hand, the people who did people like this was a huge problem for them, it was a huge change, it was also pretty cool to watch the community kind of come together and help each other out and say like, “Hey, this is clearly a better world. This is clearly worth the cost of what we’re doing.” I think on the whole, it’s definitely the community’s reaction. Sort of helping each other get through that, those who were impacted more than others. But at this point, it seems like just looking at the slack and the mailing list Elm discussed, pretty much everybody has moved on. It’s like I see almost no people—

Jamison: There are no protesters just like kind of clinging to their barricade.

Richard: I wouldn’t say that there were a lot of protesters. Some people were like, “Hey, this is going to be a big change for me. I understand why it was the right decision but man, this sucks, I don’t want to have to do this work.”

Jamison: As long as everyone’s not saying, “Make Elm great again.”

Charles: Right.

Richard: I mean, there are very few people who are saying like, “This is a mistake. Let’s go back to signals.” They obviously weren’t zero people but it was like very, very few. Overwhelmingly it seems like people were, “Yep, this is the price of progress.”

Jamison: It seems like this is just kind of another demonstration of the Elm design philosophy which is make the wrong thing impossible. That’s kind of at the language level and it’s now at the application level as well. Before you could use the Elm architecture, you could not use it. And then once I’ve decided it was a good idea, then that’s the only idea. I think that can be really powerful. It turns out it’s a lot easier to write tools for one thing than for anything.

Richard: Yeah. It’s funny, another thing that I guess has happened in the past year is we’ve got our first conference coming up, Elm Conf in September co-hosted with Strange Luke. That’s actually the title of my talk, Making Impossible States Impossible.

Jamison: Yeah, that’s the thing you hear in functional programming. Make erroneous states impossible to represent kind of in the type functional programming world. They talk about that.

Richard: Yeah, it’s sort of the advanced level. The talk I’m planning on giving is sort of like an advanced that target people who already know Elm. When I first started using Elm, I sort of reflexively used it in sort of a JavaScript but better in certain ways kind of way where I was like, “Okay, here’s what I’d write in JavaScript. Let me mentally translate how I’d write than in Elm.”

As it turns out, I was only using part of its power. There were a lot of techniques that I didn’t realize I could have been using that could’ve made my code even better and easier to maintain. I just didn’t realize it and as I interacted with the community more and talked to more people, I kind of picked up some tips and tricks for how to make my code even more awesome. Now, I sort of transitioned from that beginner phase into sort of like, “Now I understand, I can actually do even more than I realized with the same tools that I had on day one.”

Jamison: I don’t want to—I want to make sure I’m not monopolizing stuff, I have more questions, I want to make sure everyone has a time to talk too. What do you got, panel?

Charles: One thing I’m wondering about is you talked about tools a bunch and it sound like there are tools for testing Elm and tools for compiling and writing Elm. I’m wondering, is there like an IDE that people generally use to write Elm or are you using a real editor like EMax or they going after some other method and generally what’s the approach for structuring an Elm app?

Richard: First of all, as a long time Vim user, I would let the EMax comment slide.

Jamison: Experience EMax, he never misses the chance to slip that in.

Richard: People use all sorts of stuff. I actually use Adam with VimMode. Before that, I used Sublime. I also used like actual standard Vim, I used those with Elm. I have different plugins and stuff. EMAx has its own plugin. There are some IDE support, I understand it Intellejay has some Elm support and also I’ve actually heard Light Table actually has the most impressive whizzbang Elm feature. It’s got some really cool stuff that none of the other plugins have. I have not actually personally experienced it yet but I’ve heard it’s really awesome and I need to check it out some time.

Aimee: Going back to more questions that would probably be good for the people who haven’t got a lot of experience with Elm, one thing that I don’t remember us talking about in the past and I feel like now is a good time to talk about it, Jamison’s doing some stuff and have had Element production for a really long time now.

If people were looking to get this going on a new project, realistically speaking, if I was going to build something from scratch with React or Angular or Elm, what do you think? If you’re going to a manager, what is a realistic time frame to get a couple devs on board and to train them and to get an app that would be equivalent to an app in React? What is the time difference there, realistically?

Richard: That question, I think, has changed over time. The reason I say that is because I think the biggest answer to that question is sort of like how many resources do you have access to.

I can tell you from personal experience, when we hire somebody new, they don’t know Elm which is totally normal. We expect that when we hire a new developer junior, senior, whatever, they’re not going to know any Elm and we just teach them. If they’re just doing Elm stuff like their whole first week, that’s like they’re pretty much up and running by the end of the week, they can go write Elm code unsupervised.

But, we’re a company that’s full of Elm developers. We have sixteen programmers and at least half of them have made production Elm commits. Most of us are doing frontend work are just doing Elm 95% of the time we’re writing frontend code.

If you’re at a company where nobody is using Elm, then obviously you don’t have that same access to those same resources. When people have questions, basically your best bet is to hop on the Elm Slack and ask someone from there. I think you’ll have a good rate of getting responses.

Whereas a year ago, the Elm Slack didn’t even exist yet. There’s an IRC channel but it wasn’t nearly as active as what the Elm Slack has been especially in the past year. I can’t really say what that would be like for somebody else because I kind of know what my experience has been and I would have to guess what it’d be for other people. I think if it’s a week for us, it’s probably more like a month for other companies but it also depends on whoever the first person is introducing Elm has done with it on the side.

When we introduce Elm, I had been using it extensively on the side to make dream writer as a side project I did. I’d already had a couple of months of just personal experience using Elm building stuff with it.

The other big thing that we did right I think that made it a lot less scary and a lot less risky was just that we introduce it incrementally. We didn’t actually start—you get the example of starting a new project which I think is sort of what most people intuitively gravitate towards. We’ve actually heard in the community over and over that that very rarely succeeds. Almost always when people get Elm in production, it’s by doing it incrementally. They say, not we’re going to have a new project in Elm but rather okay let’s take some part of some page that we need to make some change to.

We’re like this part of this page has some complicated business logic and we need to change it rather making a change by just changing the JavaScript code we have, let’s just rewrite what we have in Elm and it’s going to be easier to manage and then introduce Elm to just that page.

There’s actually a blogpost, I think it’s the top blogpost on the Elm website right now. It’s called How to Use Element Work. It’s basically just talking about—it gives the specific example of React and like here’s how to take a React component and just drop an Elm application into there. It’s kind of strange that the intuition of let’s wait for a new project, let’s wait for a greenfield project, let’s do something big.

It’s kind of the opposite of what tends to be the most successful because as it turns out, usually what ends up happening is one of two things. One is you sort of bite off more of what you can chew where you have nobody on the team has experienced Elm yet and you have this whole big project that’s now writing on this thing where nobody really knows how to use it well. Or on the flip side, you just keep waiting forever because you can never find a project that’s sort of big enough to justify using a different technology and yet small enough and low enough risk that you don’t have to worry if it turns out that people don’t get it or for whatever reason you decide to backtrack and use something else. Small incremental things seem to be the key.

Aimee: That actually makes sense. You could do very similar to the talk that Ryan is about don’t rewrite react, you’re saying you can do pretty much the same thing with Elm.

Richard: Yeah, I mean I think honestly, if you put your mind to it, if you’re like, “This week, we’re going to start on Monday and on Friday we’re going to have some Elm code in production.” I think any team can do that. Once you’ve done that, you now have a very low risk investment that you can grow from. You can say, “Now, we have this in production. We’ve got the build pipeline sorted out, we’ve learned at least enough Elm to this one small thing probably from just following that blogpost and then from there you can say, “Okay, did we like that experience? Was that good? Do we want more of this? If so, cool now we can expand it and do a little bit more in Elm, do a little bit more in Elm.”

That’s exactly how we started. We had just one part of one page using Elm and now we’ve grown that all the way to 36,000 lines of Elm code and it’s now the second most common language in our entire code base after Ruby on the backend. All of that is just we planted this one tiny seed and just like let’s get into production and see how it goes and then just grew it from there. That’s really all it takes.

Aimee: Sounds like a challenge for a lot of people.

Jamison: Aimee, you asked how long would it take. What I’m hearing is two weeks. The standard answer for when somebody asks how long does something take.

Richard: I mean it depends on where you want to get to. Is it like how long to get something in production? I honestly think that anyone could do that in about one week. If you have somebody working on that all week, I think pretty much any team can pull that off and honestly probably less than that.

Jamison: I’m just saying two weeks is my standard answer. When someone asks how long does this hard thing but you don’t know how long it actually takes, you just say two weeks.

Richard: Yeah.

Jamison: That’s a really sad story for getting started with it. I like that.

You mentioned at the beginning that the language is built of stainless functions, pure functions that don’t have side-effects. I hear this is a lot but there’s a kind of sly wink you have to do because you can do side-effects, you can talk to a database, otherwise your program can’t do anything. Can you talk about how pure functions can sort and array memory and do nothing with it, that’s all you have. But at some point—do something impure to change state and affect the outside world. Can you talk about how you do that in Elm?

Richard: Yeah, totally. The key idea here is that when you write Elm code, all you are writing is pure functions and immutable data. The Elm run time which is sort of a black box where you can send data to it and tell it to do things, it can actually run side-effects.

The distinction here is Elm’s architecture is based on this idea of model view and update. Model is a piece of data, view is a function that returns a prescription of how you want the DOM to look. You use a virtual DOM like React except faster. We actually have benchmarks about that. It’s pretty cool, Elms currently the fastest one we’ve had.

The update function which is responsible for returning any changes that you want made to your model which is your one choice of single truth and also what we call commands. A command is something that the Elm run time can translate into some sort of side-effect.

The important thing here is that in JavaScript for example, you can write a line of JavaScript code that says I want you to go out and change this value in local storage or I want you to go and run this Ajax request right now in this line of code. In Elm, you don’t do that. In Elm, all you do in your update function is if you want to do something of local storage you say, “Under these circumstances, my update function is going to return a command which is just a plain value that says. “Hey Elm run time, I want you to go do your stuff in the local storage or, “Hey Elm run time, I want you to go do Ajax.”

The important distinction there—it matters for a couple of reasons. One is that first of all, it makes things easier to test. If you want to just say it like—the great thing about pure functions is that you never have to do any mocking, you can always just be like, “Okay, I want to call this and I want to look at what it returned.” You never have to say, “Oh, sometime in the middle of that function it’s possible that it will do an Ajax request so I need to go and proxy my XHR object or my local storage or something like that to spy on it and see if gets called. You never have to that. You’re always just looking at the return value.

But the other more important thing that it does is that it means that when you’re looking at a given function, in JavaScript you need to account for all these different possibilities. If I’m calling a particular function in JavaScript and it’s like, “Oh, maybe this function is modifying local storage, maybe it’s doing a network request.” If you end up with local storage in a weird state whether you read something out of local storage, you’re like, “Hold on, why did this happen? I don’t know why local storage now has this wrong value.” Any function in your entire code base could be a potential culprit for that. You have to look at every single function. You can’t rule any of them out easily.

Whereas in Elm, there’s only one possible culprit and that’s the update function. Granted update can call up your functions but because Elm’s type system records what values functions take and what value functions return, you can very, very quickly narrow it down by just looking at what it takes and what it returns.

We talked about how update returns a command and command represents that one I’ve talked to local storage. If I have written this function, it says this function takes a string and returns a user object. I know just from knowing what that function takes and what it returns, it’s not possible in Elm for that function to do anything with local storage or to do anything with Ajax, any kind of side-effect because the only possible way to instruct the Elm run time to perform a side-effect is by having a functional return of command.

It lets me rule out all these potential culprits. I don’t even have to look at the implementation of the function, I can just look at the type and say, “Okay, it’s not this one, it’s not this one, it’s not this one.” I can just say really very quickly narrow down the potential source of bugs.

Jamison: That makes sense, cool. Another question I had, you talked about the Elm architecture and how it’s patterned for organizing your applications. Do you have any guidelines or things you learned about just kind of broad patterns for organizing functional code bases? I feel like there’s ton of literature and knowledge out there for how you build large O apps in a maintainable way. In the functional world, it seems like they focused a lot on abstractions or functions in the small but the question of what you do in the large is kind of like, “Oh your program is great. Keep doing it.” There’s not a solid of an answer, it feels like.

Richard: Yeah, absolutely. I would agree with your assessment. I think there’s a lot more literature on how to structure o apps and I think in the functional world, there is sort of more of an attitude of like don’t worry about it, just build your stuff and it’s going to be okay.

Jamison: Yeah, functions are great. Therefore if you have a large app and it’s made out of functions, your large app would be great. That seems like the attitude you encounter.

Richard: Yeah, I could speak to that because we have a very large code base. We’ve got students answering billions of questions. Actually, we cross the billion questions answered mark pretty recently. We do have a large app in a purely functional language. Basically, we kind of took the same attitude of like, “Let’s not worry about it. Let’s just write functions and build stuff and see what happens as it scales and maybe it’ll be great.” Our experience has been that yeah we just write functions and build stuff and it’s great.

The biggest takeaway here is that it seems to matter a lot more in OO than in FP. I actually think that the lack of community documentation and talking about how do you scale a big FP application, the reason it’s lacking is not so much that nobody solved it but the fact that it’s just not a big problem in practice. At least as far as a language like Elm goes, I’ve never maintained a large code base in another functional language but the reality is that when I look at our problems and I look at problems that beginners have, it actually seems like most beginners seem to run into more problems by trying to flexibly solve this problem up-front than just by ignoring it. What we did is essentially we took sort of the basic application structure that Evan wrote up to do MBC. I’ll do an update, great, and let’s just add cases as we need and keep building it up from there.

Our experience has been great, that’s really all we did. We sort of said okay, when we need to split things off, we’ll just make a new file and put functions in there and then call from the other file. As far as we can tell, that pretty much works indefinitely as far as scaling application goes. Granted, there are other questions about how to make libraries that I think there are a lot more large intuition than there are resources that spell out how to write good, functional libraries. Especially in a language like Elm that has an ML Style Module System.

As far as scaling application goes, I’m dead serious when I say that if you just start to do MBC and just keep adding code and don’t worry about it, you’re probably going to have a great time. If you do worry about it upfront and say, in particular the most user pain that I see from new users is the following situation.

Somebody comes to Elm from React in particular and tries to organize their Elm code the same way that they organize their React code, they have a really bad time. The reason is React is all about saying okay, everything is a component. Components can have their own state. Whenever I’m going to make a new thing, I’m going to make a new component with its own state. That’s sort of the fundamental metaphor of React, that’s really what they push. You read the React docs from intro to React, the word component appears over and over again. That really encourages you to think in those terms.

Whereas in Elm it’s like okay, you’ve got your model, single source of truth, you’ve got your view that translates a model into DOM modes, and you got your update function and that’s for changing the model and performing side effects and that’s it. You don’t think about splitting things up into local chunks of self contained state, i.e. components, until you absolutely have to. For the first six months I would say of our using Elm, we basically had one component per page as it were. Each page had its own state because it’s like a web page is relatively self contained.

Then, there was one exception to that. There was one really, really complicated page where the page would bring up a dialogue and that dialogue was a form with a dozen different fields and none of them had anything to do with the rest of the page. It was all self contained in that dialogue. That one thing, we gave its own state. Every other page had just one state atom and that was it. Before when those pages were in React, it was just nested state after nested state. It was like components all over the place because that’s what React encourages you to do. It’s not what Elm encourages you to do.

I think coming in with left over intuitions from React or from other JavaScript paradigms that encourage you to think in terms of okay, I really need to figure out how I’m going to split up my state and make each thing self contained and decide which component owns this state is really swimming upstream in Elm, you’re swimming against the current in the same way that if you went to React and tried to use React exactly the same way you use Elm which would be to say I want to make my React components none of them use state, they all just use props and that’s it. In fact, they’re all stateless functional components and there’s just one state app and that’s it. You can do that but you’re really swimming against the current of what React wants you to do, what it’s designed for.

It’s difficult to realize that because it seems like if you’re switching from one virtual DOM paradigm to another, it’s sort of intuitive that you would expect to be able to just use the same thing that you’re used to and just have it work the same way. I think ELM and React are a lot more different than they are similar when it comes to state management and people don’t always realize that on day one.

Jamison: That’s a great answer, it makes a lot of sense. I have more, I don’t want to monopolize though. Okay, I’m going to monopolize.

Charles: Go for it.

Jamison: We’ve talked a lot about Elm and the ease of switching to it and the ease of integrating into your project. Let’s say I just feel like I can’t sell it, I’m in a team that’s kind of hostile to the idea for whatever reason. I like the ideas of Elm but using it right this second isn’t a great fit for me. What can I as just a JavaScript developer learn from it that I can take back into JavaScript?

Richard: With an eye on the idea that you just said where some of the stuff is you learn it and it works well in Elm and it might not work in Javascript but are there things that cross that barrier?

I think that there are but I think that there are things that are not particular to Elm so much as they are just sort of the category of language that Elm fits into. For example, Elm has a type checker that prevents a lot of bugs. The way that it does that is by avoiding type mismatches. One way that you can avoid type mismatches is by using a type check language like Elm. There’s lots of other type check languages. In fact, there’s quite a few ways that you can type check your JavaScript. There’s Type Script, there’s Flow, it’s not something—even as I recall, Type In is a Google closure compiler that you can get from comments.

If you write your JavaScript in a way where you sort of avoid using some of the things that JavaScript lets you do that are maybe a little too clever and maybe a little bit more error prone than they are nice such as passing a string for an argument sometimes and other times passing it as an object, something like that sounds pretty obnoxious when you say it just like that. But in terms of what that makes you think of and how defensively you need to check all of your arguments to see what types of things they might be passing in and what kind of APIs surprises you might end up with, a lot of cases I think you’re better off just saying, nope this always takes an object, this always takes a string and it never takes either one or the other.

Writing your code pretending that you don’t have access to those features or pretending that you have a type checker that would prevent you from doing those things. In a lot of cases, it just makes your life better. When I do write JavaScript code, I sort of pretend that I have a type checker even when I don’t.

Other things will just be like the more pure functions you can write, the better. They really are reliable in ways that functions that do side-effects in the middle are not and they’re easier to test in ways that functions that functions that do side effects in the middle are not.

I actually gave a talk about Reactive Conf last year called Effects as Data. It was about how you can essentially in JavaScript write your code in the style where you are separating out all of your side-effects into something like the Elm run time except I create it by hand in the talk so much that you can write all of your functions in terms of pure and stateless functions that just return data which makes it easier to test and just have your blackbox run time execute them.

That might be a little extreme though. I’ve never actually tried doing that in JavaScript. In Elm it’s all built in so you don’t have to do any extra work for it but in JavaScript you would have to go pretty far out of your way to do that and I don’t honestly know that I would do that in practice.

Charles: Alright, well, Jamison had to run off to the airport. I know that some of the rest of us have some time constraints so I’m going to push this in the picks. But before we go into picks, do you want to give us a quick plug for anything you’re working on or if your company is hiring or how to follow you on Twitter or anything like that?

Richard: Yeah, totally. @rtfeldman on Twitter. Our company is hiring, we do lots of Elm production. We also do rails in the backend and we’re getting into Elixir. We hire remote, we don’t expect any Elm experience on day one and this is my favorite job that I’ve ever had including the companies that I started.

Charles: Oh wow.

Richard: You should absolutely work here. noredink.com/jobs. Also, you should check out the Elm conference in September, it’s Elm-conf.us.

Two things that I’m working on, Elm in Action, the book from Manning Publications, it’s in early access so you can buy it right now although not all the chapters are out yet.

The other one is Front-end Masters, doing a two-day Elm workshop so it’s a total of 16 hours. That’s in September. I guess depending on when this airs it may already happen.

Charles: I think it’ll be a close thing.

Richard: Hopefully you can still get on there.

Charles: If you’re listening, check it out now because you probably have a week. Alright, let’s go and get to picks. Aimee, do you want to start us off with picks?

Aimee: Sure. I have one that I checked out last night. I don’t know when this is coming out so it might be old news by then but it’s just a really short medium article but I was absolutely floured when I read this. It’s by Jordan Scales who is a developer at Con Academy and he dissed, kind of started digging into his modules directory and the stuff that he found is pretty shocking, just like really random things that when you NPM install express or Amber, and Babble. The kind of stuff that will land in your project is pretty crazy. If anything, it’s kind of like educational that you should be complacent in what you’re installing but also kind of good for a laugh so I will put the link for that in the show notes and that’s it for me.

Charles: Alright. I’m looking around because I’ve been really busy super busy this week, I don’t know what to pick.

Aimee: I can dig to, if you want.

Charles: You can what?

Aimee: I can give some more if you want.

Charles: Oh, go ahead.

Aimee: Okay so, another one since we’re low on picks this week. I am going to pick Apple Cider vinegar. I don’t know if it’s in another podcast or maybe just on Twitter someone was talking about this. You have to buy a specific brand, I take the Braggs Organic Apple Cider Vinegar. I take a table spoon with every meal. Again, I always pick these health things and people might laugh at me.

If nothing else, maybe the taste is invigorating because it tastes pretty awful. I feel like it helps. The basic promise of it is it will affect the pH because it’s so acidic and it’s supposed to help you burn calories that way or by combating the GI Index. That will be another pick in addition to my blogpost pick.

Charles: Awesome. This Friday which is in three days, we’re going to be getting a foreign exchange student in our house.

Aimee: I remember you talking about that, that’s so cool.

Charles: We got it worked out and booked out through none other than Jen Eames’s wife. We’re super excited. The company is CET USA. But anyway, we’re really excited to have her come and stay with us for basically the school year. She’s coming from an area of Italy that I actually lived in for five months. It’s going to be kind of fun for me to practice my Italian and I guess for her to practice her English. I’m going to pick that even though we haven’t done it yet.

Richard, what are your picks?

Richard: I’m going to second Aimee’s pick of that article about modules, that was awesome.

Aimee: It’s crazy, absolutely crazy. It’s like mildly infuriating.

Charles: I thought you were going to pick the apple cider vinegar.

Aimee: I know, I was kind of hoping too.

Richard: I’ve never tried apple cider vinegar. When I was reading that, I was like I’m so glad that Elm has its own package manager. It’s amazing. It enforces some antique versions and crazy stuff like that. It doesn’t do any of that.

My first pick is a movie that I saw recently. It’s from 2013, it’s called In A World. It’s basically about the phrase that you hear so often in trailers for movies, and especially it’s like “In A World where something something something…” The whole movie is about voice actors. It’s a comedy, really funny and really unusual movie. I’ve never really seen anything quite like it. Check that out, the movie is called In A World.

Second pick would be blog posts that I wrote a while ago and recently updated called building a live validated sign up form in Elm. It’s basically a walk through assuming that you don’t know any Elm at all, you just know Java Script and you don’t know anything about functional programming. It essentially takes you through building live validated sign up forms with Ajax and the whole line. Those would be my two picks.

Charles: Very cool, thank you for coming. We’ll go ahead and wrap this up and we’ll catch everyone next week.

Richard: Thanks for having me.

Aimee: Bye!

x