 Rhaid am ymlaen, mae ymlaen Jack. I'm here today to talk a bit about Elm. I've got into the habit of putting the flags of the countries I speak in at the beginning of each talk. So, I of course found the Spanish flag emoji and then it was pointed out to me backstage that this might be a bad idea given where we currently are. So, thankfully the organizer pointed my mistake out. So I've rectified it, I've got both. Hopefully that keeps everyone happy. So, yeah, I'm delighted to be here in Barcelona, the amazing city to talk about Elm. I knew it was going to be a good talk. I saw this sign when walking around yesterday and I thought to myself, it's a sign. Okay, I'm really pleased you laughed at that because I really wasn't sure how that was going to go down. My name's Jack, this is me on Twitter and mostly on the internet. You can find me on here and find links to everything. If you don't have time to do many questions afterwards, I will check Twitter afterwards and also please come and find me. I'm here all day so please come and just ask in person. I work for a company called Songkick based in London. We've also got offices in New York as well. We're a service that helps people find gigs and buy tickets to gigs. I have to mention it. We are hiring as is every other tech company in the world but please do come and chat to me if that's interesting. So, I want to talk about Elm, but before I talk about Elm, I have to talk about everyone's favourite language, JavaScript. Lee's actually done a great job of setting me up here, but I want to go back to when we first started building these kind of more heavy client-side architectures in JavaScript and what the kind of approach was. And I think we started with the MVC, the Let's Replicate Rails. And then we discovered that this didn't really work. But before we figured out that components were the way forward, we had a lot of stabs. We went MVC, we went MVVC, then we went MCVCV, MMCVCCC. None of these really worked very well and they didn't really work. They were pretty tricky to figure out. They caused lots of problems. Most frameworks at the time focused on the idea of two-way data binding and this dirty checking or polling where you have data in your view that the user sees and data in your code and you're just constantly checking the two to make sure they're kept in sync. I mean, anything that's called dirty checking can't be a good long-term solution, right? We got to a point where this was so popular that people even considered adding it to the language. Object.observe was a feature proposed. It even made it into a version of Chrome, I think, and maybe other browsers. And this led us to watch an object and get notified when this object changed. It turned out, however, that long-term this is a bad idea and people began to think that we can do better. And it was confirmed that we can do better. This library that you might have heard of came along and really pushed this idea of immutability and also components. And it's not just React doing this by any means. If you look at the later version of Angular, Ember, Vue.js, all sorts of frameworks now are very much focusing more on components rather than controllers. As said, I can skip a whole bunch of this talk. Lee wasn't lying when he tweeted me, telling me he'd set me up for success because he very much mentioned a load of stuff that I'm going to quickly touch on, too. The problem comes because on the client side, web apps have to deal with changing of data all the time. MVC worked really well on the server because you have much more control over how that data changes. You deal with post requests and you can make sense of it and control it very well. In the browser, however, you can have lots of HTTP requests going, different data sources. The user can do whatever they want. You've got browser extensions, all sorts of things that can mess with you. So really, this mutable data becomes very tricky to deal with. It can get changed from all sorts of sources and it's just a nightmare to work with as your app gets larger. So looking a bit more at the kind of trends that we've seen more recently in the direction we're going when it comes to web apps, we started to see that applications would begin to own their own state. So what we now have is mostly a single source of truth which is where all the data for your application lives. This data is stored as one big object, a JavaScript object. You could even use an immutable JS record or object, whatever type you need there. All your data is now kept in one single repository for you to manage. It doesn't all necessarily have to be there. If we look at it's a JavaScript talk, I have to do to do's as an example. If we have like a to do app, you might let the user go to a specific URL to control how they're filtering their to do's. So in the URL we have slash filter slash completed. That's a bit of state that the user is in the completed filter. So I wouldn't then duplicate that in my main application state because I'd have the data in two positions there. It's all about having a single source of truth. Most state lives in one place, but there are exceptions. As most of the answers in computer science go, it really depends, which is all I've really got for you. But anyway, once we have that state object, our UI becomes just a representation of that state at a given point in time. Again, taking to do MVC as an example, here I've got my to do and it's done is set to true. So we have that one striked out on the list. If I swap that to false, it's now not done and it's not struck through. If I swap it back though, we're right back to where we were again. Once we've got all this state in one place, it's very easy to build a UI that represents that state because we have much better control of all the data. What we've also seen, I'm a bit worried I'm going to get hunted down on Twitter for this slide, but what we have also seen is that efficient rendering, at least initially, is not a developer concern. Things like React, Ember, Angular 2, et cetera, Elm, as we'll see, are very, very good at taking the state changes and figuring out the minimal amount of changes they need to make in the DOM. Now, I'm not saying that you don't need to worry about performance and rendering performance and I'm not saying that developers didn't care about it, but at least initially the frameworks will give you a lot for free and enable this pattern to work. If React, when it first came out, was really, really slow at changing the DOM and diffing it, it wouldn't have got as popular as it is today. So it's great to see the frameworks taking on some of that burden, but we do still need to do work as developers as well. And then the tricky thing is really keeping track of how this state can change. In a typical web app, there are tons of actions a user can do that could change something. And really you want to be able to very much model those in your application and keep track of them. This is all about explicitly defining how users can modify the state through interactions like button clicks, form, fills, et cetera. And also being able to trace it. I worked for a while in a big Angular app, in fact I still do. And stuff like this, I'm not explicitly hating on Angular here, it just plays very nicely for my example. You can modify things in the view by just chucking them onto the scope, right? And there are patterns in Angular I know that let you avoid this. But things like this, it becomes very tricky to track where scope.x has been changed or where it's been mutated. You don't know what called that, you don't know where it came from and so on. It can be very tricky when a bit of data can be mutated in a ton of different places. However, what we've seen recently is a library called Redux, which takes the approach that you should explicitly define all the actions a user can take to modify the state. And these are called actions. So this function addToDo returns an object that has a type and it has some additional data, and this is an action that the user can perform. And we'll see in a minute we then have functions that can take these actions and deal with them and update the state of our app. The beautiful thing about these is because they're playing objects they can be logged and serialized and you can replay them and debug and all the rest of it. So once we have actions and we have our state we can have update functions that can take an action on the state and give us back the new state of the world. So if our state is an empty list of ToDo's and the action is user addedToDo, the update function should take both of those and give us back a new state. If you have followed Redux, these are called reducers in Redux because they can reduce an action on the state into a new state, but update function is just as good and a bit less confusing. So if we have this action, user log out and my current state has a user with name Jack in it, I can get the new state by calling update with both of those and we just get back user undefined. So we now have functions that can give us back the new state also without mutating the existing state and giving us back a whole new one. What's also really nice about this pattern is your update function encapsulates most of your business logic which makes it really easy to test. You don't have to like fire up any UI or deal with like mocking Angular or React or Ember or whatever in your test because it's just a plain function. And it also really separates your logic and your user interface which is really nice as a developer to work on. I want to talk a bit about data flow as well because as I mentioned, we kind of had the two-way data binding approach of Angular and early Embers and all the rest of it, but more recently we've been taking this almost unidirectional data flow. So on the left here we have kind of the Angular and the old way of doing it where you just go back and forth constantly, you're checking. In the new way we have this unidirectional data where data only flows in one direction around your application. So the user does something, they fill out a form, they click a button, that calls the update, that gives back the new state which is given to the view function to then re-render onto the screen in the user. And it turns out this is just much easier to reason with because you know where the data is, you know where it's come from and you know how to handle it. Recommended reading, Andre Stoltz who's definitely around here somewhere and didn't pay me to put this in honestly told me that you should all read unidirectional user interface architectures which kind of goes into that stuff and a lot of detail is a really good read. So what you end up with really is this state at the top of your app, the big red box which can take actions from components which are the blue circles, send them back up, they get dealt with and then the changes propagate through your application. But data only flows in one direction. And then our update functions get a bit more complicated and we can switch on the types and we can deal with every single user action that can occur. And then you have one place where most of your business logic sits. This is kind of good but we still hit some JavaScript issues. It's very easy to accidentally typo one of these user actions. It's very easy to forget to deal with one. It's very easy to return something in the wrong shape like your state will have a specific shape where you're expecting certain keys of values and it's very tricky to mess this up when you have a big application and it can cause weird bugs where like something in your state gets set to undefined and it's pretty tricky. It will be really nice if we can model these using types. So instead if we had a type message which says these are all the messages that a user can perform it happens to be called message because that's the terminology in Elm but you can think of these as actions. So these are actions that the user can perform. So we can have a new user or we can log out. And this is where Elm comes in. Elm tries to be a language to solve some of the problems that Lee was talking about that I just mentioned about these immutable architectures that we want to build for all the reasons Lee touched on. I'm not here to say it's the perfect language yet. I hope one day it will move towards there. I don't know if there is such a thing other than JavaScript. It's also not the perfect solution to all our problems. I'm not here to say that you should all ditch your JavaScript and rebuild an Elm although that would be great. I do think there are certain times where Elm is more applicable and also you have to bear in mind the fact that Elm is not quite as mature as JavaScript and some of the frameworks around. So if you were to Google Elm you'd probably hear that it was functional, typed and compiled but those are all a bit computer science-y for me and a bit boring. They don't make me really want to dive into Elm. So I've gone for the much more exciting, expressive, self-documenting and robust, right? Cool. Yeah. There is a learning curve to this. There's a lot of new stuff in Elm as you'll see it's very dissimilar from JavaScript. The syntax is very tricky. If there's any functional programmers and Haskell users in the room then that's good. I think you'll find the syntax a bit easier to pick up. For those who haven't, which was me, I'd never done Haskell or anything similar, it does take a bit of time but I promise you you will get used to it and then really enjoy it once you're there. So the code is very expressive. It's very functional. It's a bit lispy. So we call add with one and two. We get back three. We can map over list of numbers passing this anonymous function. The backslash, by the way, for the anonymous function is vaguely supposed to mean a lambda. That's how you can kind of remember that one and you can also do things like partially apply functions. A lot of things that anyone familiar with this style of programming will recognise. We also have this really nice syntax called pipes. So if we have the make person function that takes my name, Jack, I want to call that and take the result of it and pass it to increment age, then pass it to increment height, although I really don't want to get any taller, and then pass it to increment weight. We can, instead of going from there where you have to work from the inside out, you can use the pipes to make it look a bit cleaner. Anyone who's written any elixir will recognise this syntax as well. Unfortunately for me these days it seems to be more about incrementing weight than anything else. But we're doing okay, I think. Hopefully. I don't look too bad. The syntax as well for Elm is just really clean. It's really nice. You have increment age that takes a person. That's how we define a function. And then we take the person and then all the properties to the right of the pipe are the things that get updated. Similarly, add x and y is very clean and you can easily partially apply these functions with one argument. So add two is the result of calling add with just one argument, too. As I mentioned, Elm is typed, which makes it very self-documenting. You don't need to tell Elm what types you're working with. It can infer them automatically, but it can be really nice to add what's called type annotations. So if I have the add function, I can say it takes one integer and another integer and returns a final integer. So the type on the right-most side, it's over there for you, isn't it? Yeah, is the return value. Every other type is each argument in turn. So is even, for example, takes an integer and returns a boolean. I would encourage you to use these and annotate your functions with types. It will save you in a couple of months when you come back to the project and also kind of help the compiler out as well. Then we have what are called union types and these took me a while to kind of get my head around. They're basically a way of creating a type that can resemble one of many states. So if we go back to thinking about filtering to-dos, I might have a type called filter which can either be show all or it can be show completed or show active. And this is basically all the states that my filter can be in. What's really nice about this is I can then write a function show to-dos which takes a filter, a list of to-dos and gives me back the new list of to-dos. And I can use case which is kind of similar to switch in JavaScript. And when the case of the filter is of the show all type, I'll return all the to-dos. If it's show completed, I'll filter the list to just find the completed to-dos. And if it's show active, I'll swap it to find the not completed to-dos. This is really nice for a number of reasons. They can be checked by the compiler. So the compiler knows that you've dealt with all the cases correctly. It's very easy to change or rename one. You rename one if you forget to do it in all places. The compiler will blow up at you. And it's really nice as well to be able to work in your own terminology to say that the show to-dos function takes a filter is really, really nice. It just makes things much easier to follow as a developer. And often in these client-side apps we're working a lot with JavaScript objects, right? We'll have a big object that probably came from an API that will represent our user and all the information about them. In L, we don't quite have objects. We have something called records, but you can think of them basically the same as a JavaScript object literal. And you'll often need to pass these objects around your system. You'll have lots of functions that take a user object and do something with them. We can type these in L by creating type aliases. Type aliases are just saying, right, there's a record with this specific set of keys and I want you to act as if it's a type. So say I'm working with some API that gives me back a person which is a name and an age. I can define a type alias person and then any functions that either take a person or return a person can be typed using that person rather than just taking a record. This is really nice because your code is much clearer. It's cleaner. It's typed in your domain-specific terminology which makes it very easy to work with. The compiler will guarantee you're meeting those type requirements so you can't accidentally take a record and add an extra field to it or delete a field because the compiler will tell you that the types don't match. And we can avoid a whole class of bugs where you expect an object to have a certain property but it ends up not having it because something's gone wrong somewhere along the way. Elm is also very robust as well. If we go back to JavaScript for a minute, if I've got an object and I pass it into a JavaScript function, what guarantees can I make about that object? It turns out none, right? The function can just completely do whatever it wants to it because it gets the reference of that object and it can mutate it as much as it wants. That's why we all love JavaScript. In Elm, that's not the case. Everything is immutable. So if I have this person record in Elm, I call increment age. It can't mutate the person record. It must return a new person and then I've lost all the mutation bugs that I've ever had to deal with in my JavaScript career. So there's a whole blocks of bugs that just aren't bugs in Elm because they can never possibly occur. Elm functions are always pure as well. A pure function is a function that takes all its input as argument and it doesn't need any external input. So here, the sum function is pure because it takes A and B and it will return them added. The other sum function is not pure because it relies on some external data, window.foo. So in the case of sum, I can call it with two and two and that will always 100% guaranteed before but other sum can be whatever the hell it wants because something can be take window.foo. In Elm, you have to write pure functions, which means, again, you can't have a function weirdly change its behavior because you've accidentally relied on an external bit of data. And another problem that really hits us in JavaScript is dealing with the absence of data or something not being present. I've got a quote here. I call it my billion-dollar mistake. Does anyone know who said this? It wasn't my boss either, hiring me. No, so this... I'll give you another clue. It was the invention of the null reference in 1965. This is by a chap called Tony Hoar who said this has led to innumerable errors, vulnerabilities, and system crashes. He literally describes it as the billion-dollar mistake and one he wishes he'd never made. That was kind of the first time that null or undefined in some guys became... was implemented in language and then obviously it's been implemented in every other language since within reason. And it causes a whole load of bugs. I'm a Ruby developer as well as a JavaScript developer. We've all had the like no method foo on nil. JavaScript we've had undefined is not a function or the rest of it. So Tony Hoar made this mistake. You might say it's a horrible mistake. That did not deserve any of that applause. And it's okay if you would like to leave the room. Okay. I really thought that was going to go away but more worse than that did. Anyway, so null null, how do we represent a value being either present or empty? Because sometimes data isn't there, right? If we take like a react component it might get some data from an API and render it. But when do we know that props.api data is actually present if we're making this call asynchronously and at some point that data will come back to us. Usually this means wrapping your render calls in like ifs or checking if the data was there and using a different render function or a different component maybe and all the rest of it. In Elm we have a very British term called like maybe. You can kind of think of this like the shrug emoji or the shrug command on Slack. It's kind of like maybe this data is there and maybe it's not. So this is the type of maybe. This is built into the language. A maybe is either just a value or nothing. So maybe is one of those union types like when we created a filter. Maybe union type has some data attached to it. It's either just that bit of data or it's nothing. So if we have, if we take some imaginary value as a value I'm either just the integer five or I am nothing. And then I have the type maybe int because it's a maybe that might have an integer around or it might not. And this is really important because now you can't possibly not have data when you're referring to a variable. So if we take some list one, two, three and I pull the first thing off the list using list.head I try and times it by two. If we have data in that list this is great. That will work. I should point out this isn't valid Elm because list.head returns a maybe. If you imagine it wasn't and if this was valid list.head that would give us one times two and we get back two. But if list is empty we'll get like undefined times two and then we've got an error. We've got a runtime error and our app has blown up. So you can't ever get into this state with Elm because it makes you deal with every possibility of the value not being there. And this blows up if list.head gives us back nothing. A more concrete example say you've got an app and you have a user who can log in. You might model them as maybe a user which is a custom type you've defined. Then in your view you have to use this case statement to check if the user is present or if they're not. So you can't ever forget to deal with a case of some bit of data missing. It's just not possible and the compiler will shout at you. This takes a while to get used to. I used to hate this when I first got started with Elm all these like extra bits of work to pull data off. But it turns out to be really useful and also makes your app much more robust. Just quickly we also have a module called tasks which is used for making asynchronous work mainly HTTP requests. And tasks either fail with a specific type or they succeed with a specific type. And again you have to deal with it. You can't forget that a task might fail. You have to deal with that. When we want to run a task we hand it off to Elm in the form of a command which is a thing we give to Elm that it will run in the background for us and we'll touch on those a bit more later. As I said, there is a lot going on here. There is a big learning curve but I hope there are enough benefits to make you attempt it and I've got a load of resources at the end as well. There's another really good blog post by Andre that I'll recommend called Everywhereness as a Foundation. The Elm compiler makes sure 100% of your code is thoroughly checked against corner cases and error cases. This makes Elm be almost able to guarantee that your application won't have any runtime errors at all ever. Which sounds like a bit of a bold statement but it's actually demonstrated to be true in a couple of companies who are really using Elm. This is a quote from the creator of Elm, Evan. We also have a compiler that gives extraordinary helpful hints. It is good enough that no red ink which is a company who are writing lots of Elm runs 36,000 lines of Elm in production and has never gotten a runtime error from their Elm code in more than a year. I think it's pretty amazing. We've got like track.js at work and the number of like undefined is not a function errors that just you haven't got a hope of debugging them to be able to run something like this is pretty cool. Elm's compiler is also just amazing. Cory Haynes tweeted this the other day. So here he made a typo. So he was expected to pass selected item but he passed selected items, the plural, and Elm compared it all and figured out where his typo was. So just simple mistakes as you're spotted by Elm for you and you just spend so little time debugging compared to JavaScript applications. So I know I've got a fair amount to cover so I'll try and go fairly quickly. We're building actual apps in Elm and we have something called the Elm architecture and this is made up of three functions. We have model which just gives us the initial model of our application so that's all our data. We have the view function which can take the model and produce the HTML that will be rendered onto the screen and we have the update function which can take those messages or user actions and the current state, the current model and give us back the new model. And Elm deals behind the scenes with all this data changing and re-rendering on all of it. So when you have the what change question that Lee was talking about, Elm just does it for you and you don't have to worry about it. When your update function returns a new state, Elm will, you know, diff the views and update the DOM for you without you worrying because it's all immutable data it's much more efficient to do that as well. You can kind of think of this architecture in this kind of unidirectional flow that we saw earlier. We had the model, the view and the update and things go round in a lovely circle. So to build the hello world of these kind of apps is a counter app where we can increment and decrement numbers. Firstly, I define the model. In this case, my model is just an integer. I'm just going to call it zero. I define a function initial model which gives me back about zero. Secondly, I define the messages that the user can make or call via clicking buttons. In this case, they can either increment or decrement the number. Then I define my update. So I take in the message and the model. If the message is increment, I'll return the model with one added and if it's decrement, I'll subtract one. Fourthly, the view. Elm has a really good HTML library. The syntax of which does take a little bit of getting used to. I'll give you that. You can see there we have a button. Once we're one where we click it and we'll decrement and one where we'll increment it. Then I put it all together. Elm ships with an HTML app beginner program function where you give it the model, the view and the update and it just hooks everything up for you. Highly recommend using this to get started. Then if we run that, it does indeed work and we can click and things go. I've got a link in a bit to GitHub where all the code lives, by the way. I'll go fairly quickly through it in the interest of time, but feel free to come and grab me or raise an issue on GitHub, whatever you like. We left the view until last which is a property I really like about building Elm apps that we can just worry about the UI less and make sure our business logic is sound. Also, the update function where our core logic is would be so easy to test because it's not attached to the UI in any form. Dealing with side effects as well. So often we'll need to not only update some data but make a request to an API to fetch some data, for example. In Elm, we explicitly model those so we hand some data off to Elm in the background it will run our task or actually the peer request and then it will give some data back when that task has been run. So in Elm, we call these commands. So you give Elm a command, it will go off and it will call your update function once it's got some data back. So the Elm architecture part 2. Again, there's a bunch of code. I'll go fairly quickly. Please grab it on GitHub. Come and find me today. I'm happy to walk you through it in more detail because it can be a bit tricky to get this across to you in five minutes. We've got a new signature for our update function. It now not only returns the model but it returns a command and this is some background work for Elm to do. If you want to think of this in diagram form it kind of looks somewhat like this. The command is up there. Update function can give Elm commands. It will run them and then it will give them back to the update function. So let's say I want to grab some data from GitHub. I create a GitHub person. This has a name and company and this is data that comes back from the API. And I have a model which has the username I want to make the request for and then the GitHub person which is a maybe GitHub person because we might not have the data yet. Then we define the messages. So we've got fetch GitHub data. That will be sent when the user clicks the button. New GitHub data is what I'll get back when I've actually resolved a request and got data from the API and fetch error is if the API is down or something goes wrong in my request. Then we define the update. Notice that we're now not only returning the new model but also at any commands. So for example in the case of new GitHub data we'll return the model and we'll update the GitHub person because we've got data now and then we'll also give Elm command.none which basically means chill out you don't have any work to do. In the case of fetch GitHub data where the user has clicked the button I won't touch the model. I'll give it about the same model but I'll tell it that I want you to fetch this GitHub data with this username. I won't go into how that fetch GitHub data function works so I haven't really got time but again all the codes on GitHub. So again we've got our update function we give it back commands Elm Runzo commands and calls back to us. Then we define our view. So again we swap on the GitHub person if it's just the person I'll render the person's name and company and if it's nothing I'll show the button and have the load thing. Finally we have the initial model which username Jack Franklin GitHub person is nothing and our init function which gives us about the initial model and any initial commands we want to run. This is useful if you want to run a command when the app first runs for example. Then I hook it all together ignore the subscriptions bit I'm just going to try and pretend they don't exist for now and if we run this we can hit load and we do get my data back from the GitHub API. You'll notice as well that I'm actually using opera here which I want to make perfectly clear is not an attempt to influence anyone at this conference at all. So just another example go for this in diagram form so the user clicks a button we call update we give it the fetch GitHub data action and we return the new model and we also return the fetch GitHub data command which is over here. The view renders in the background behind the scenes we make a request the API and Elm's doing that for us. Then finally we get that data so we have this new GitHub data message that has come back over here. So we call the update with this new GitHub data in the model and we return our new model and also command.none so we've done all our work and then the view renders and we get the data back. I made this slide in keynote a long time ago when I worked for Pusher rather than Songkick and I couldn't find the original keynote so there was no way I was making this again so I've done a very subtle update which I hope hopefully I get away with. Okay to a deep breath that was a load of code right and I'm fully aware that I threw a lot of code and concepts at you in a fairly short amount of time. This does maybe seem like a lot and I'm aware there's a lot to take in but it all comes down to trading off boilerplate versus explicitness. I like that Elm makes me write a decent amount of code I like that I have to structure everything. The thing is it's much more apparent how good this is when your application grows fetching data from GitHub API you could do that in two or three lines of JavaScript but you wouldn't have any of the structure that Elm has given you here. So I think it's very hard to get across a lot of the benefits of Elm in a small application but I'd encourage you to try building bigger things with it as well. All the code is on GitHub. I'll put these slides up and I'll tweet a link but that's me on GitHub so that's the repo you can find all this code. I know I'm running out of time. I'll go fairly quickly for the rest. In Elm we kind of use components I just want to touch upon this because I saw a tweet yesterday which was really well timed by a guy called Scott. He says the more I'm using Elm the more I see that components were a mistake. Components needed to exist because types didn't in JavaScript. About types JavaScript needed a way to isolate mistakes from the rest of the system and types like the ones in Elm help us with that a load. I'm not sure entirely like I think the idea of some form of components in Elm is good but what's really interesting if you do try Elm is that you'll find you don't want to create these small components you're quite happy with this bigger kind of architecture. So I just think that's kind of something to ponder. All right very briefly the Elm ecosystem how you get up and running and all the command line tools that Elm gives you. Elm Reactor if you install Elm you run Elm Reactor it will run it on a local server on your laptop you can go to that URL and then it will run your Elm app for you. You don't need to run anything else very easy to get up and started. You could do this in like two minutes now on your laptop if you wanted. There's also Elm Package which is a package manager for Elm. It does all the things you expect. It's really cool. It's also I've got to show you this the most British package manager. Do you approve of this plan? When I install something and if I install like a specific package like the HTML package. May I add that to the package.json for you? It's a very polite package manager which I think is probably the biggest selling point for me. Anyway, there's so much more I haven't covered like I didn't have time in the half an hour which I've already gone over sorry to go into everything. So I would encourage you to check it out. I've got a bunch of links coming up. But just to summarise why or when should you consider using Elm? You're fed up of silly errors like undefined function that take up loads of debugging time. You want to develop with the confidence that types give you and a clever compiler to back you up. I found that I write way less tests when I'm writing Elm apps because I'm really confident that the compiler has got my back and will spot silly errors. You're happy to kind of ride the wave. Elm is fairly new. It's settling down. It's picking up a bit of traction. There's a lot of stuff still to be done and worked on. You're happy to kind of build some packages. You know, things like React have this humongous amount of components available on the net that you can pull down and use. Elm is a bit newer. It just doesn't have those yet. You know, more packages get added every day but was still not quite like a React or Angular or Ember state. What if this talk has put you off Elm? I hope it has not. But it does take time to learn. I know this can be a bit overwhelming. Guide.elmlang.org is like a book freely available online that talks you through everything. Highly recommend giving that a go. If you do give it a go and you get stuck, please come and find me more than happy to help. And also, Elm the language brings many concepts that Lee's already touched on that are very language agnostic. So even if you don't use Elm in production, there's a lot of stuff we can take away from this. This kind of expliciteness of the Elm architecture and how things are modeled across the app very explicitly makes things easier to work with. I don't think I need to sell these too much but types are great. They have a lot of benefits. Again, immutability using something like immutable.js for example gets you a lot more guarantees about your data that you don't have by default in JavaScript. And also the thing I like most is this process of defining your application step by step. So you define your model, define how the user can interact with it, define how those interactions are dealt with, then define your view and rinse and repeat over and over again. I think that approach has really stuck with me. Will everyone be writing Elm in one, two, or five years? Guess what? It depends. I have absolutely no idea. I think it's a really cool experiment. It's great fun. As someone who's written primarily kind of JavaScript and Ruby over the last four years picking up something very different like Elm and working with it has been really, really enjoyable. I've really enjoyed hacking on it. So I'd encourage you, even if you don't think you'll use this in production, which not many people are, to pick it up and give it a go because I think you'll have a load of fun doing so. So, yeah, as I said, I'll put the slides online and I'll tweet them with the hashtag. I'll put them in the Slack channel. But here's a few links to take away. Guide.elmlang is the best place to start. The docs are where all the API docs lives. Community has links to like the IRC, the Slack channel, et cetera, which is very active. There's my talk as well and the slides will go up on speaker deck afterwards. So thank you very much for listening. Do you use Elm in production at Songkick? So I've been at Songkick three weeks. So yes, though. So yes, yeah. No. I'd like to think maybe in the future we could, but we're not there yet. No. The supplementary question from the questioners. What would it take for them to use it? Well, is it mature enough? Is it... What would be the thing that makes your bosses go, yeah, we're going to use this? So I think once you get the Elm app built and into production, you will have, you know, it's a way more robust application. Like we've seen the people at No Reading, they've got I think now like 50,000 lines of Elm and they don't get any runtime errors. They don't spend time debugging that sort of stuff. So I think there are trade-offs, but you get a lot of benefits back. Elm is certainly way more mature than even six months ago when I first did a talk on it. I would definitely recommend using it on a kind of smaller side project, maybe an internal tool. I think it's a really good place to start to kind of show off those benefits and then start to work towards getting it into production. It's also tricky like at Songkick, I'm the only person who knows Elm, so it would be a little irresponsible to just start pushing it up and then I could just run away and be in a world of pain. But they could never fire you. Well, that's true. Yeah, I'd be indispensable, so maybe I should. I think because Elm compiles down to JavaScript that I know the answer to this question, but it's been asked, can you render Elm's server side? How do you deal with SEO? So not yet, it is being worked on. It's kind of, there are a lot of bits of Elm that are being worked on. This is one of them. There is an experiment into getting Elm rendered on the server and I would be willing to bet that it will happen, but they're not there yet. There's a few questions asking for comparisons with TypeScript and other such languages, but I feel that that will be a long discussion. Yes. But here's an interesting one. When would you not use Elm and pick just pure JavaScript instead? So I think if, so Elm really shines where you have a load of data that's changing all the time, you have a lot of user interactions and the rest of it. If it's something a bit more static where you could just layer on a little bit of JavaScript I think it would just be overkill to use something like Elm. Obviously if you, I wouldn't build any mission critical stuff in Elm yet. I think people are familiar with JavaScript. It's more evolved. The framework is more mature. So it kind of depends on how important the app is to you and being able to work on it over a long period of time and all the rest of it. I think certainly side projects is a great place to start with Elm before looking at using it for more critical bits of infrastructure. And I guess like every other framework understand its advantages and power and use it when you need that as advantages and power but if you don't... Absolutely, yeah. Yeah, I'm not, you know, if you've got a fairly static app but you want one bit of JavaScript then using Elm will be, you know, complete overkill. Excellent. And obviously a lot of people are interested in your previous circus career. So your trademark move was a double back somersault with a half twist. So could you demo it now? I've got a little pain in my foot at the moment. That's a terrible shame. Yeah, I know, sorry. What a disappointment. He'll be here all day, so maybe he'll get better. I'll throw a couple of beers at the meet-up. Who knows? Good man. Ladies and gentlemen, Jack Franklin. Thank you.