Costs & Benefits

[00:00:00]
>> Richard Feldman: Let's talk about some of the costs that Elm has. Number one it's learning a new programming language. If you have a team of people who already know and are comfortable with JavaScript learning a new programming language is of course a cost of using this technology. And it's more work to learn a programming language than it is to learn a library, a framework, something like that because there's more there.

[00:00:18]
There's also a smaller ecosystem. So, in the same way that Ruby has it's own package ecosystem, Python has it's own package ecosystem, Java has it's own package ecosystem, JavaScript does too. Elm also has it's own package ecosystem that's totally separate from the JavaScript package ecosystem. Now it's a really nice ecosystem we'll see some of the really nice characteristics that come from having a separate ecosystem but it is a lot smaller, right.

[00:00:40]
MPM is the biggest packaged ecosystem in the world there's everything you could possibly imagine on there. The same is not true of Elm's ecosystem. And finally, fewer Web APIs have first-class support than JavaScript. Anytime the browser introduces a new web API, like audio, video recording, stuff like that, JavaScript has support for it on day one, as soon as browser's implemented, JavaScript has support for it.

[00:01:01]
Whereas Elm has to sorta implement that on top of the JavaScript API, so there's a period of lag there. So if you want the absolute most bleeding edge stuff, you're always gonna have that in JavaScript, you're not always gonna have that in Elm. So not all the web APIs that are currently out there, are covered by Elm, and that’s always going to be true, to some extent, no matter what.

[00:01:20]
Okay, so, given those costs, why are companies choosing Elm, what are the benefits that they are getting out of this? So I'm gonna talk about three things. One, is measurable technical advantages. Two is it makes hiring easier, this is a counter intuitive result for most people. And three is, it's cohesive, high-quality ecosystem.

[00:01:38]
So we'll talk about each of these. So first of all measurable technical advantages, one is bundle size. So this is something that's becoming increasingly important to a lot of companies as single page applications become more and more common as the way that people are deploying their front-end applications.

[00:01:54]
So we've got a lot of popular frameworks, React, Angular, Vue, Ember, things like that. And then we've got some of the ones that are sort of focused on smaller bundle size, like Preact, Svelte, or even just writing raw JavaScript and Elm competes with the bottom row here. Elm is sort of a competitor to Preact, and Svelte and just plain JavaScript in terms of bundle sizes, it's much, much smaller than what you get with React, Angular, Vue, or Ember.

[00:02:19]
One of the differences, though, as we'll see, Elm isn't sacrificing productivity to get those gains, in fact, it's got quite a bit of productivity improvements compared to, arguably, any of these. The way that Elm's able to achieve these smaller bundle sizes is the fact, that it's a separate programming language, it get's to play by separate rules, different rules than JavaScript does.

[00:02:40]
Another is in terms of reliability. So this is a graph of our production run time exceptions between 2015 and 2018, which is when we've been using Elm in production. So we have roll bar which detects whenever our front end code crashes. [COUGH] This is a graph of the exceptions that it's logged over that period of time.

[00:02:58]
So JavaScript is about 60,000-ish and Elm this is the end of the graph. There actually, it has happened, for a long time we had zero but eventually, despite Elm's sort of goal of no runtime exceptions, we did actually hit one. It was a very sad day, but it's not enough to actually put a pixel on the graph, so it's not literally zero but it is negligible.

[00:03:23]
Also worth noting that the thing that actually caused the crash, no longer exists in the language. So it would no longer be possible today [LAUGH] and we'd be, still have a completely unblemished record if not for that one thing. So this is something that, depending on who you ask, either sounds unbelievable like there's some sorta trick.

[00:03:41]
Like it must be swallowing errors or it must be doing something else that's not quite exceptions but is essentially the same thing as exceptions. But as experienced Elm programmers will tell you, no it's just that the compiler catches them all at compile time and tells you about them.

[00:03:56]
And as we'll see over the course of the workshop, it's really difficult to accidentally cause a production runtime exception in Elm. Onboarding, this is something else that people seem to worry about but we've had the experience of hiring people straight out of a JavaScript boot camp, and having this be essentially their first professional programming job ever.

[00:04:16]
And they're writing production Elm in their first week of their first job as a programmer. We haven't seen that be a problem and I don't think that other companies have either, from what I've heard. And finally, we come to the ecosystem, so the sort of the ecosystem advantage that, Elm has.

[00:04:31]
So in JavaScript, let's say I'm starting a new JavaScript project, and I start off with, yes, I'm going to use JavaScript for this project, and I think I wanna be compatible with older browser, so maybe I'm gonna introduce Babel. And I think actually, I might want some type checking so maybe I'm gonna get TypeScript involve although there's also Flow, which seems to be less popular than TypeScript, but Facebook uses it.

[00:04:48]
Facebook has a big, high quality engineering team, so maybe I should look into that first. So it's not just that you choose JavaScript, it's that you have to pick a particular dialect of JavaScript, then once you've got your dialect set, okay well, I'm gonna need to build my UI.

[00:05:01]
It's pretty uncommon to build UIs just using vanilla JavaScript, so I'll think about something like, okay, maybe I'll use Angular or React or ViewJS or Amber, one of these different technologies to handle my View Logic. Then I think I want a state management solution for my apps, say, because a lot of these aren't concerned with that.

[00:05:16]
They don't come with an app state management solution out the box so maybe I'm gonna get into something like Redux, MobX or Relay or maybe I'll go the Observables route. And then I think okay, well, that's interesting although Redux and TypeScript, do they necessarily play well together? [SOUND] Okay, well, we'll deal with that when we come to it.

[00:05:35]
But then I gotta think about async and I like, okay, well maybe I wanna do like redux-sagas or redux-thunks or redux-promises. Or maybe redux-bservables because I don't necessarily need to use observables for async, even though I may or may not be using them for state. And then I think I got utility functions like maybe I want lodash, maybe I want jQuery, Immutable JS, Ramda.

[00:05:56]
All of these are different alternatives that may or may not mix and match well. If I'm using jQuery, is that gonna work super with React? Not really designed to work together, Immutable JS may be a better fit. Maybe jQuery has some stuff that I like, kinda old school and familiar and Immutable JS and Redux, a lot of those play together.

[00:06:11]
And then I want some third party packages, so I'm gonna use MPM or Yarn which is built on top of MPM but it's different CLI. And then maybe I want dependently type so that I can get TypeScript binding. So that doesn't necessarily play well with flow but if I show slow then I can get flow type but that doesn't necessarily play well with TypeScripts.

[00:06:28]
And then finally I have ES6 modules which if I want tree shaking I get ES6 modules but not all these packages use ES6 so maybe the tree shaking is or isn't gonna work. Okay, so this is a lot of stuff and these things compound on one another. And deciding to build a new project in JavaScript involves making a lot of decisions and accepting that not all the decisions you make are going to be compatible with one another.

[00:06:54]
In contrast, in Elm, there's one dialect that's called Elm. There's no stack for building different variants of Elm, there's just Elm that's it that's what everyone uses. In terms of UI, you have a view function, that's it, that's all there is. In terms of state, you have a thing called model, that's it.

[00:07:09]
Async is all done with update. Utilities? Elm ships with immutable functional core libraries, and that's what everyone uses. As far as packages, there's a package manager built in, you just use Elm install, and every package in the entire Elm ecosystem follows all of these things and they all work really, really well together.

[00:07:27]
And all of these concepts are things that are true for every Elm application, every Elm package in the entire ecosystem and we're gonna learn all of them today. So, to sum up, so the reason that companies are choosing Elm is number one, a cohesive ecosystem. Number two, it is fast, it has a nice performance.

[00:07:47]
It is reliable, no runtime exceptions. Tiny, tiny assets and of course, no semicolon debates. Arguably the biggest benefit of all.