Hello, my name is Jeanne Grana, and today we're going to talk about Elm, which is a delightful language for front end development. When you want to do front end development today, you have to use JavaScript because it's everywhere. If you want to use react, angular, viseo, Vanilla JavaScript, you have to use JavaScript to have interactivity on your website. And the biggest advantage of JavaScript is that it's backward compatible. That means that if you have a website that is working today with JavaScript on it in 20 years, 50 years, one century, it should still work because the web platform is backward compatible. It's a big advantage, I think. But for me it's also its biggest disadvantage, because if you can break compatible, you can deprecate things. That means you can't remove things from the language, even the things that are bitwell. For example, in JavaScript, if you try to compare null and zero, null greater than zero is false, null equals to zero is false, but null greater or equals to zero is true. So a little weird, but as this is in the language since the beginning, you can't remove that, because if some websites have dependencies on this, it will break. So if you have a look at the JavaScript syntax size over time it will only grow because you can remove anything that you add to the language. So each time you add a new tiny functionality, new tiny feature to the language, it will remain forever inside the language, especially during the new ES six version where we've added a lot of things. So everything is here to stay, and it will never be removed from the language, even the mistakes and badly designed API, if there are any. So there is a lot to learn because we're not using JavaScript the same way that it was conceived. So we've added a lot of features to the language, and the language has become quite complex. There are a lot of ways to do the same thing. For example, if you try to use asynchronous operation, you can have callbacks, you can have promise, you can have generators, you can have asynch await functions. There are a lot of things to learn, a lot of way to do things, and once you've learned them, you need to learn when to use one over another. So a lot of things to learn. But even after you've learned the language itself, you have to learn its ecosystem, because usually you will want to use some framework, some library, because the standard library in JavaScript is pretty poor. So you have to learn react angular view enough to know which one to use when, or if you even need to have a framework like that. And once you learn all of that, if you want to go to production, you need to learn a little bit about tooling in JavaScript. So how webpack works, how you can configure it, parcel, et cetera. So there are a lot of bundlers, but you have to learn this also. Another drawback of JavaScript is that it's by essence dynamic. That means you can reference some part of the code dynamically, making it hard to statically analyze the code. So it's hard to optimize. You can really do a good bitcode elimination or tree shaking because you're never sure that a chunk of code is not used. With ES six modules, you can now know for sure if a file isn't used, but you can't know if inside a file that is used, everything is used or not. So you have some assets that are bigger than expected because you're forced to use something to have some chunks of code that you are not using, but still you have a complex build state because we still want to eliminate everything that we can. So it's pretty hard to optimize as a language. But for me the main drawback of JavaScript, it's low confident level because for many reasons, for example because of new learn undefined values, you can have a runtime exception in production. I will even bet my house that the majority of bugs in JavaScript are caused by null pointer exception. Undefined is not a value, et cetera. So we will see that in elm it's a bit different. You have really minor editor assistance because as the language is dynamic, a tool can only assist you to a certain point, and after that it's up to you to fix things leading to painful refactoring. If you want a comparison, just have a look at the Java ecosystem. I'm not very fond of Java, but I have to admit they have a really wonderful ecosystem for tooling. You can do a lot of refactoring from your editor. It's pretty nice. The feedback cycle is pretty slow because often you will need to go to runtime to see if something is working or not. Even if you're practicing TDD test driven development, there are a few things that you won't notice until you try to actually run your code. So it's a pretty slow feedback cycle. And the main drawback for me is that dependencies in JavaScript are risky. I can talk about that during an entire session, so I won't go into further details right here, but I have got you two links that you can check. In NPM a package can do almost everything. So it can call another server, it can do whatever it wants. So installing a dependency is always risky. In NPM everything leads us to M. So what is M? Elm is a type functional language, create fast and reliable web application. There are a lot of things in this definition we will try to break things. So first we can notice that it's really domain specific. In the definition it says it's to build a web application. So it's not used as javascript in server or for your coffee machine or for your raspberry. It's only focused on websites and web applications, so it's really specific and it does only one thing and it does it well. Also it's something that is statically typed. We've talked about Javascript being dynamic in Elm it's not. So everything can be analyzed by your tools. That means many bugs don't even compile, so you cannot send some bugs to production because it won't compile. The editor can really help you with every refactoring. And when you try to refactor your code it's always compiler driven because you will change something and the compiler will throw nice and helpful errors to help you fix what you've just broken. So refactoring is compiler driven and the feedback cycle is really fast because as you get your errors instantly when you type your code, you can know if something is wrong. In fact, in arm we're saying that once it compiles it means it work. So pretty nice. It is safer. Don't trust my word. I have a graphic right here showing the runtime exception encountered by Noradink, which is a pretty big website elearning platform and a big user of Elm. So during three years there are like 62,000 Javascript runtime exception against almost zero runtime exception with m, which is quite impressive. Of course they have like 17,000 line of code of JavaScript, so it's pretty dingling number, but you have to balance it with 200,000 line of code of m. So 17,000 line of code in JavaScript can trigger 62,000 runtime exception while 200,000 line of code elm production almost zero exception. So it's a language that is by design really safer for your production. So it's a functional programming language. So functional programming is blah blah blah. In fact, I don't care about the academic definition of functional programming. For me, functional programming just means that it's honest. It's being honest. Let me explain my point. So in JavaScript, for example, if you have a send email function here, when you're calling this function, if you don't look at the body, you don't know what happens, anything can happen. And for example, you don't know that if the user email is not provided, it will throw can error. And if you don't know that, you don't use try catch around your code and you won't catch this error in production. So in production you have something that can be broken just because you don't know how the send email function is implemented. But it could be even worse. For example, you could launch a nuclear missiles on somebody or transmit your credentials to someone. So with functional programming you wouldn't be exposed to this kind of things, because in Elm side effects are explicitly declared. So if your function can produce side effect, for example sending something over network or anything else, your function will show that it does something, so you can't have unwanted side effect. That's why I talk about honesty, because a function says exactly what it does and it doesn't do anything that you can ignore. The language is really fast, everything is static, so you can eliminate every chunks of code that is not used. You know everything that is used in phase language, pretty nice. Everything is pure. So you can have further optimization from uglyphage. Yes, so you have smaller lets and you can have some comparison on Internet. So it's really fast. If you have a look at the guide of Elm, you can see this sentence that is quite important to me. Elm has a very strong emphasis on simplicity, ease of use and quality tooling. And behind this simple sentence you have all the philosophy of m focusing on simplicity, so the language will decrease in syntax over time. It's really easy to use and everything is done for newcomers to not be lost. And the tooling is really good. So simplicity and ease of use, because it's focused on one purpose, so you don't need a lot of features inside the language. You have a very small list of features and you can learn it really fast. Even over time the language has lost some syntax more than adding more syntax. So it's simpler and simpler. The API are really well thought because you can break things because the language is compiled. So when you compatible things, you don't care about what was original source code, so you can deprecate things between versions. It's not a problem. In Elm everything is explicit, meaning that there's nothing hidden. Like in JavaScript, everything is honest and explicit. The quality stooling when you install, for example, Elm, you have a compiler install, a project starter, a package manager, a dev environment, a ripple to execute some Elm command in the terminal, and a Doc tool and the test runner. There are two test runners in Elm, but they are compatible with each other and everybody is using the same test library. So it's really nice. The documentation is enforced, meaning you can publish a package without having a documentation with it, and it's all available on the website, on the end package website. So it looks like that it's pretty nice. So you're never lost with someone else's code because you have some documentation. The versioning is enforced. I don't know if you're familiar with semantics training, but it's this triplet of numbers representing the version. The last one is called the fixed number, and when you increment it, it means that nothing has changed for the outside world. So anybody that relied on your package can update safely without breaking anything. But as soon as you've added something to your API, you need to increment the second number that is called the minor. That means something was added, but it won't break any people's code because it's only something that was added. But as soon as you have a breaking change, so you remove something, you change a behavior or anything else you need to increment the major version. So in NPM this is used, but it's only a convention, so it depends on the maintainer of the package. If they make a mistake or ignore this rule, you can update your dependencies and break your application. It's not possible because the compiler will decide which version your package has. So for example, if you try to break something, the compatible will say okay, it's a major version, so you need to increment the measure version. So when you update your dependencies, you're sure you won't break anything. So it's pretty nice. The community is awesome. In fact, if you have a look at the talks of the creator of the language events applications, you can see that it's mainly focused on how to build a community, how to animate it, how to build trust in the community, and a reflection on what is success on the online communities. So these threadholes are really nice. So if you want to have a look, we have the links to the slide at the end of the presentation. This Community gathers on slack and on a discourse which is a forum for m. So let's have a look at the syntax and for that we will go to the terminal and use elm repel. So as I said, when you install elm you have access to many tools. Here we will help use the repo, which will allow me to type some elm command inside my terminal. Lets me just move that. Okay, perfect. So let's start with something really simple. So for example a string, if you have a look at the return, it returns the value. So hello. And here you have the type of the return value. So here the type say it's a string with uppercase s. So let's try a number. First thing we can notice is that the type is a bit different. Here it's a number with lowercase n, because number only represents a type variable, meaning that the compiler knows that it's a number, but it don't know exactly what it is. Because in arm you have two types of number. You have float and you have int. So here the number is just a compiler saying okay, I know this is a number, but I'm not sure if it's float or an int. That's why we have a lowercase n right there. So you have some basic operation, for example the entire division. Here we have an int, so we can see an int, we can concatenate things maybe. Hello? So let's see something simple. Here we have some error from the compiler, because I've tried to, let's see the error. I cannot do addition with string values like this one. So in arm you don't concatenate things with the plus operator like in JavaScript, but you have to use the double plus operators. But if you have a look at this error, it's pretty nicely done, because the promise location of your code is displayed with a really great explanation of what happens and how you can fix that. So it's pretty nice. In elm the errors will guide you to working code, so it's pretty nice. So let's see, what do we have else we can have some variables. So for example, I can say is 42 equals to true. So declaring a variable is just assigning a value to a name. And here for example, we have some conditions. So if 42 so if you have a look at the syntax right here we don't have parentheses, we don't have brackets, only if the condition then here this is value that will be returned if it's true. So hello. Then you have a health and there you can return the value if it's false. When you try to press enter you can see that it returns a value. So in elm conditions are an expression and not a sentence like in JavaScript. In Javascript a condition doesn't return a value. In elm it does so this expression is equals to hello conf 42. Okay, so we have foundation. It's a functional language. So let's create a function. To declare a function, you just have to write the name of the function, the parameters. So here let's say we have two parameters, a and b, and equals to the body of the function. So here it will be a plus b. So as you can see, the syntax is really simple, really straightforward, not a lot of characters to type. So pretty nice. If you have a look at the function signature, you can see that it's pretty new. That means that it's a function which takes one number, another number and returns a number. So this is a function type signature. What do we miss? So for example, the arrays in m are called list. So it's a list of a. A is like number tie variable. It's a compiler saying okay, it's a list of something, but I don't know yet what is inside. So it's a list of a. But if you put something inside like hello, it will say okay, I know, it's a list of string, which means you can't use different kind of value inside the list. If you try you will have an error from the compiler saying okay, the second element is a number. The previous elements were string, so there is something wrong. And if you want to do this anyway, you can have a look at this link to know how to do that. If you are trying to convert this isnt to a string, you can use this function. So as you can see it will try to learn to teach you how to fix your mistake. So that's really helpful. We also have some tuples which is two or three values when you want. For example, to return two values from a function you can return a tuple. Okay, you can have three value inside the poll if you want. If you have more complex data structure you can use something that isnt, sorry, you can use something that looks like objects in JavaScript. So for example I can say that I have an object with a login being Jordan and the password being password. Wait, I need to be safe right here. Perfect. So this is a record. So this is a record, sorry. With two elements, a login and a password. So perfect, sometimes, often in arm you will try to type your value. So you will have to type this and as it's pretty long you will often use type aliases. So you can create a type alias and say okay, the user is the same thing that exactly this. And then you have access to a new function that was created with this declaration, which is the user function that can create a user. So the user function is a function that is expecting one string, another string, and returns a user. So if you do something like that, you will have a user with a login jordan and a password. So this is the first kind of type that you can create a type alias. So it's helpful, but it's not revolutionary. But in arm you also have custom types. So custom types are very much like an enemy in typescript or Java. So for example, let's take a JavaScript example. You want to retrieve something from the server. So a string, so you will declare a variable like that, for example, that will be new at first, then a boolean that will be false. True, sorry, you want to know if it's an error, so you have another boolean, okay. And you have three variables to represent only one thing. It's a remote string that we will fetch on your server that can be loading, that can be on error. So you have three variables only for this concept. And for example right here is loading is true and is can error is true also, which is kind of weird because if there was an error, it shouldn't be loading or not. So you have some incompatible states that can happen. In arm you will create a new type and say okay, my rematch string is something that is maybe not loaded or maybe it's loaded. So here it looks a lot like can enume, but you can also say that it's loaded and it contains a string. So this variant of the enume can contain a string, but you can also say for example, it's an error as it contains one error code and one error message. Oh, sorry, it's coding. So as you can see, the error is pretty nice too. So after that I can say okay, my remote string is equals to not loaded. So you have a remote string that is not loaded. When it's loading, you can say okay, it's loading. Or you can say okay, you've retrieved the string. So it contains the string. Hello, it seems something loaded. Or you can say there was an error 400 bad request. So this is kind of like can enumerate but with values inside. So it's pretty nice to really represent what you want to represent. Okay, do we have null? We don't have null inside the language maybe undefined now. In elm we have something that is called nothing. So pretty nice. I've just renamed it. In fact, if you have a look at the null reference on Google, you can maybe find this quote from Tony orr. I call it my billion dollar mistake. So Tony orr is the inverter of the new reference. So it says this is my billion dollar mistake. This has led to innumerable errors, vulnerabilities and system crashes. So Tony Rose advised to not use the null reference because this is what can cause runtime exception. So in l we've not just renamed undefined it to nothing is something quite special. If you have a look at the type, it's something that is a maybe of something. So this is a type variable, we are getting used to that. So this is a maybe. A maybe is a custom type defined like this. So maybe of a is nothing or just something of type a. So for example, you can say my string is nothing, meaning it has no value, or you can say it's just hello. So it contains a value which is hello. So the main difference with Javascript is that the compiler knows because of the type of the variable that it's can ab and it can be nothing. So you have to handle every case in arm, so the compatible will force you to handle the case where it's nothing. That's why you can't have any runtime exception because of undefined values in elm. That's pretty nice. I think we've seen almost all syntax, just two things we haven't seen. If you have a complex expression like here, you can use a latin block to split it. For example here I've split it into two variables, 24 and 1624 and 16. In the in you can use the variable that you've declared right in the lip block. So pretty simple. And you have the case of expression, which is kind of a switch in JavaScript, except that you're not matching the value itself, but also the pattern, the structure of this value. So for example here I can say if it's equal to zero, okay, I will return zero. If it's equal to one, I will return one. But if it's anything else, and here anything else is a variable, so it can catch every structure. Because a variable can contain anything, I will return that. If I'm not using this variable, the convention is to use an underscore to say I won't use the value. You can also use case of on custom types it's its main use case. For example here I have a maybe of string. I can say if it's nothing I will return my string maybe. But if it's equal, for example to just hello, it will match with this member and it will say okay, my string will contain hello. So my string is a variable that will contain hello and then you can return hello inside the body of this member. Okay, so to go further, we will build a really simple application in elm, which is head of tail. So really simple. If you have a look, we can start a new game. Here we have flipped a coin and we're asking the user to choose between head and tails. And maybe it will be right, maybe it won't. So if we have a look at the current version, this one, it's not doing anything. We only have the starting screen. So let's see the code. Looking at the code, so we have an index HTML file which will import the compiled program. So ElM compiles JavaScript and you can import the JavaScript inside your HTML, and then you will instantiate your application with the init method. So let's have a look at the code. Here we have the module declaration. So each file is a module and is declared with a name. It can expose something to other modules, then you can import something from other modules. So here we are importing some things to under a browser application and HTML. We'll see that later. And main is the earth of your program here. It's a program, as you can see with the type annotation. So it's a program which is an element. It means it will take control over an element inside the dome, and you have a few elements. So during application in Elm, we've noticed that we're always using the same pattern that was standardized under the helm architecture. So the ElM architecture is basically one data flow. So you have a model. A model is a type that you defined, and this type can contain every state of your application. So any variables that you can have inside your application is stored inside this type, the model that you define. So this model is given as parameter to a view function that you declare. So you have a view function that receives this model as argument, and you return some HTML to the end runtime. So you have a view function that returns the HTML that will be displayed. The runtime will display this HTML, and every time something happens, for example, when the user clicks on something, the runtime will generate a message, which is a type that you undefined yourself. So it will trigger a message. This message will be sent to another function that you declare, the update function. The update function will receive the current model, this message, until it will return a new model, a new updated model. This model will be transmitted to the view function to display the new view, et cetera. So it's a circular data flow that looks like a lot like redux if you're used to using redux because redux was inspired by Zelma architecture. So going back to the code, so we have the init function, which is the initial model. So here we can see that it's the first model of our applications. We also have something that is a command, we will see later what it is. We have the update function. Now let's start with the view function. So we have the view function. The view function receives the model, the model that we have declared right here. The model is a custom type with only one variant. It's in the first state of the applications in the game. So the view receives this model and returns some HTML. So in Elm, HTML is created by using n function, taking two arguments. The first one is a list of attributes, for example class id and click, et cetera. And the second is a list of child elements. So here the only child is a button with a class button primary containing the text start a new game. So if you have a look at the application, it's this button. Okay, sorry. And we have the update function which takes a message. The message is the type that we've declared here. We don't have any kind of message, so I've just put a placeholder or a message, so it receives a message, a model, and it returns a new model. But here, as you can see, we are always returning the safer model. So it's not doing anything. So our application cannot do anything because the update is not doing anything. So let's try to implement this second screen. So this one, so here it doesn't work. We need a second state in role model. So let's add a new state which is again state, meaning that we have started the game. So now what we need to do is check what is the model inside the view. So we will use case of and if it's a no game we can display what we were displaying for the start screen. But if it's a game, we need to display the game view. So I have a little helper right here. So when it's a game we can display the question and the two buttons. Let's try that. It doesn't work because if you have a look right here, we are not sending any message to the runtime. So here we need to create a new message to say okay, we need to flip the coin, so it's a message that you can create. And when we are clicking on the new start button, we will send this message. So on click, we will send this message to the application. So if we have a look, clicking on the button not trigger some messages. So we have some messages that are send it to the runtime. But if you have a look at the model, it never changed because update function is not doing anything as we said earlier. So let's have a look at the update function here. We need to know what has happened. So let's say that if our message is a flip coding, then we need to change the model. So the model was in the game and now we need a game. So let's have a look. And now it works. As you can see, we have a flipcoin message that is triggered. The flipcoin message is sent to the update function that will change the model to. Again, earlier I said that when you click on the button, you flip a coin. So here we need to store the coin state. So let's add a parameter to the game and say that it contains the coin state. So let's create a coin state model which is either head or tail. So as you can see, you can really represent what you want to represent. You don't have to use a boolean to implement things like that. So it contains a punch state. I have an error because my variant is wrong. So let's go to the error. So right here I need to give it something. Let's say I give it and here I don't care about what is the value. So I will just use underscore. It should compile. Yeah, it compiled so it works okay if I have a look now, my model contains again head, but here it's always head. So it's not very nice because the game would be pretty easy. So we need to generate a random coin. But in elm, remember it's a functional programming language, meaning there is no side effect. You can generate a random value because that will mean that the same function will return something different when you call it with the same parameters. So we need something else. In elm you don't execute side effects, you let the runtime execute them. So in the update function you can return a command, and the command is basically an order that you will give to the elm runtime to say, okay, I need you to do something, please do it and use a message to return the result value. So for example, here we want to generate a random coin. So we'll create a recipe to explain to the runtime how to generate random coin. We won't generate it, and the runtime will flip the coin according to the recipe and return the result inside the message. So the recipe is called a generator of coding state. So it's a generator that generates coinstate and then runtime will receive a command of type message that it will use to generate your value. So let's have a look. First we need to create a coding generator. So let's create a random coin which is a generator of coinstate. So for that we will use the random package. So we will say that it's a random uniform, so it's a uniform probability of ed or tail. So it will generate either ed or tail with a uniform probability. Here we cannot just give this argument because remember I said that the APIs were really well thought and what will happen if someone was using it like that? Here you're asking to the uniform method to generate a random value inside no value, so it cannot actually generate a value. So random universe needs a non empty list. And what is a not empty list? It's in fact a list with at least one element and another list that can be empty. So an unlist is one element and a list that can be empty. So it has always at least this element to generate. So here we have a random coin generator, and here in the update we need to tell the compiler that we want to generate a random coin. Once it has generated this value, we need to get it back. So for this we will create a new message which is coin flipped, which will contain a coding state. So we can give that as argument to nonhandled the generate. So once the coin is flipped, the compiler will return a new message that we need to end up. So here the coding has been flipped, so we can store it inside the state and we don't need any more side effects. So let's return command none. Here we haven't really a game add. We still have a new game waiting for the coin to be flipped. And now it will work. So if we have a look at the application, now we have a random value that is generated. Perfect. Let's create the third screen, the result screen. So let's create that with a game state. Once again we can create a type for the game state and say it is a win or loss. Okay, in the view function you have an error because you haven't under this case. So let's create the result view. Sorry. So perfect we have the result view. And now when we are clicking on this button, we need to decide what to display. So let's create a new message which is a player bet. So the player will bet on funcoin State. So here when we are clicking on ads, we want to generate a player, but on Ed. And here when we're clicking our tails want to generate a player, but on tail, so perfect, we have an error in the update because we are not handling the new message here. We will just say, okay, if my model equals to game has a coding state that the player is betting on, it's a win. Else it's a loss, sorry, else it's a loss. Okay, and we will use that and say this is a result containing the result and no command. Perfect. It compiles, it will work. Let's have a look where it is right here. So let's start a new game. As we can see, it's a tail. So if I click on tail, I win. Here it's tail again. So if I click on add it's hyper. So this is how you create application. In elm, you create some state, some model, then you have some message that can change the state of your application. And in the update function you're just updating your state accordingly. So it's pretty easy to understand and the compiler can really help you implement things because it will only compile when everything is done. So let's have a look at the advantage of Elm. So Elm has a really great developer experience because of the error messages, because of the tooling, because of the community, you have no runtime exception, which is pretty nice, very good. It has a great debugger, as you can see. I can see exactly what happens inside my application. I can go back in time to different state, I can export this to someone. So it's pretty nice. The type system is really powerful. It will always try to reduce the possibilities of your variables to handle less and less case. So it's really nice. The performance is really great and the community once again is amazing. It has some drawbacks, for example the governance model, it's basically a one man project because events API key is the one decided for everything. So if you're not happy with what he wants to do with the language, it's not good. So it depends on what you want. And some people find it a bit verbose because everything is explicit. So for example for navigation or something like that, you have to explicitly do something. But for me it's an advantage because you understand everything that happens, nothing is hidden. And the asymmetric Javascript communication can be a bit destabilizing. The debut at first, sorry, because you only can communicate with JavaScript through messages, so you send a message and you wait for an info. So it can be surprising at first. Why should you use them? Because you have a complex UI or complex model. A lot of change happening inside your application and you want to understand what is happening. Elm is really good for complex applications. You have frequent refactoring because ELm really shines during refactoring. You care for dogs? Of course, if you don't want your production to be full of dogs, Elm will help with that. If you want to go into programming functional programming language like SQL, ELM is really a gentle introduction to these languages. If you want to write better code, because since I've started Elm, my javascript has become more readable and better for me. You can start today working with elm with my workshop. So it's a workshop on GitHub that you can clone and then follow the steps. Everything is described inside the readme and if you want to have the link to this slide, they are available right here. Thank you for listening.