Recommended
More Related Content
What's hot
What's hot (20)
Similar to Elm - never get a runtime error anymore. Almost.
Similar to Elm - never get a runtime error anymore. Almost. (20)
Recently uploaded
Recently uploaded (20)
Elm - never get a runtime error anymore. Almost.
- 1. Elm Never get a runtime error anymore. Almost.
- 2. Montage
- 3. Secret techniques for reliable projects • Use pure functions • Avoid nulls • Immutability everywhere • Powerful type system • One global state • View is just a pure function of state
- 4. Elm
- 5. Has Haskell-like syntax, but thankfully it’s not Haskell
- 6. Elm • Pure language • No nulls • Everything is immutable • Compiler checks everything • Very opinionated
- 9. Elm Architecture is a fractal Event Handlerevent event Model UpdateView Model UpdateView Model UpdateView ModelUpdate View Action
- 17. No, not really…
- 19. Cons • Very opinionated • Tooling • Dead Code Elimination • Immaturity • Runtime errors are still possible • Some things are hard to do • Almost no libraries for “production” • Poor coverage of modern browser APIs
- 20. Is it ready for production? It depends… But if you learn it, it will make you a better JavaScript developer.
Editor's Notes
- Hi! My name is Anton, and I gonna tell you about the Elm language. There are tons of compiled-to-JS languages (https://github.com/jashkenas/coffeescript/wiki/list-of-languages-that-compile-to-js over 9000!), so, why would I want to tell you about Elm? Well, let me step back and tell you about my recent project I participated, Montage.
- This is basically a photobook editor. You upload a bunch of photos, zoom, pan, rearrange them, then click Order, and you'll receive a physical photo book in a week. It was a super fun project to work on. Also, it was technically a complex and big project. We wrote it in Dart, which is statically typed, and static typing helped a lot and eliminated a lot of bugs. We also added a powerful troubleshooting system to it - we log all user's actions starting from when they opened the editor, and every time runtime exception happens there, we send that exception to Rollbar (error aggregator service), and attach the logs of all the user actions (including HTTP requests and responses) to these exceptions, together with the user's account name. So whenever user complains something doesn't work there, we theoretically have a lot of information to help - we usually can see the exception, which just happened, all the history of user's actions, requests and responses from our servers, etc. And still, more often than not, I'm looking at all of this, and I have NO IDEA what just happened. How she ended up with that state of the app? How to help the user and at least make sure the project will be saved properly? Why the hell there's no method blah on null, since that thing just never should be null? Could we avoid all these problems and create a more reliable app, which would have less problems? Well, yeah, there're a lot of techniques, which help with that, like:
- * Use pure functions whenever it is possible, try to isolate side effects * Avoid nulls, there were tons of errors when we call something on null, it was like 80% of errors in out Rollbar. I wish it was easy in any language with nulls... * Enforce immutability. Immutable objects and values give you piece of mind nothing will ever change them, it's way easier to reason about them, and less chances to make a mistake when using them. * Use powerful type system, make the compiler check everything and catch errors for developers early, making it impossible to make runtime errors. All the errors should be caught in compile time. * Concentrate the state in one place, so we don't need to sync a lot of local states between each other Make rendering is just a pure function of the global state (like redux does currently), local states are very painful to sync. After Montage, I started to dream about some language or technology, which would solve all these problems we had with Montage, which wouldn't allow us to make runtime errors. Which would just force me to handle every case where something may go wrong, because by the Murphy's law things will go wrong if there's even a slight chance for that for some user.
- Elm is a small, simple, very opinionated, staticly typed, pure, functional reactive programming language. It has Haskell-inspired syntax, which is very concise and elegant, and the type system is also Haskell-inspired (with type inference, yay! So you don't have to write all these Foo foo = new Foo() all the time). It doesn't have nulls, it has union types, and overall the type system is quite flexible. Thankfully, it's not as flexible as in Haskell, and fear not, it's not as complex as Haskell, it's actually quite simple. Elm doesn't have typeclasses, monads, do notation, and all these crazy things like this one:
- * Elm is a pure language. You can only define pure functions there, no side effects (well, almost. E.g. you can write to console.log) But we need side effects and state, right? So, Elm solves it with FRP, i.e. it uses "signals" to route user events and other external events into the app, and respond to them. Just like in RxJavaScript, Bacon, etc. * No nulls. Ever. What to do if there's no value? You should use Maybe. But the difference is - if something returns Maybe, you HAVE TO handle both cases (when there is value and when there's no value). Otherwise, you'll get a compiler error. So, no chance of runtime error here. * Everything is immutable. When you need to change a list or a record, you create a new one. It's not as inefficient as you'd think, because it uses special data structures under the hood to make it fast. * Compiler checks everything, there's literally almost no chance to get a runtime error. It will check that you handled every possible case in your 'switch' statements, that everything type checks, that you handled all possible errors you can get from HTTP requests, that you handled possible wrong JSON responses from the server, etc. Some prolific Elm developers stated they never have seen a runtime error in their Elm apps in their code, all runtime errors are coming from the JS code. Elm is very opinionated about the architecture of your app, if you don't follow what they recommend, you gonna struggle. It's basically a single global state of the app + Command-Query pattern + view as a pure function. The good thing - it's a good architecture, from my experience (and I built 2 apps on that architecture already) - it simplifies the app significantly, and makes debugging very simple. And simple debugging is prob the biggest takeaways after Montage - if you are building a big app, you should really build mechanisms for debugging it, because you’ll need it a lot, and your app will fail in different and totally random places. I keep talking about how it’s opinionated and about Elm architecture, but what it is, really? Let’s see:
- We don't live in the world of ponies and butterflies. Using every technology or language is a tradeoff, and Elm is not an exception. Everything has pluses and minuses. I really don't like when you listen to a talk about some technology or language, and you only get ponies, but not scary dragons. But dragons are there, for sure. So, for Elm, the minuses would be:
- * It's very opinionated. If you don't like that "Elm architecture", you are pretty much doomed. It's almost impossible to use another architecture to write a web app in Elm. On the other hand, if you like it and follow the architecture, everything in the language is built with the assumption you are going to use it. * Tooling. There's a package manager, some integrations with editors, but no IDE features - i.e. no go to definition, no find usages, no refactorings, global renamings, check inferred type under cursor, etc. Coming from the Dart world, where the tools are top-notch and state of art, this looks really poor. * No tree shaking. The output of the code is not Google Closure compatible, you cannot use it to eliminate unused code (e.g. in ClojureScript or Dart you can). So, the compiled JS size could be smaller. * Immaturity. Despite the community is growing, it's still prob < 1% of the JS community. Not many packages, no millions of answers on Stack Overflow, sometimes documentation is sparse. Of course you can use JS packages, there's JS interop in place, but dealing with JS you're losing all this safety and 'no runtime errors' features. * Runtime errors are still possible (though very rare). E.g. if you call Debug.crash explicitly, or try to create incorrect regex. Even worse, sometimes you can make it compile, you won't have a runtime error, but then it silently doesn't work. E.g. if you forgot to wire a port, or used a decoder on an event, and that decoder is not compatible with the event's JSON (looking for a nonexisting field, for example). In this case you'll click to a button, and nothing gonna happen. It also is quite rare, but still possible, and this sucks. * Some simple operations are actually a big deal and require a lot of ceremony. For example, getting height of a generic DOM node is quite tricky to do, you'll have to do that either via ports, (basically, send a request to JS side, and then wait for a response. There's no guarantee JS won't throw an exception on its side). Or you can do that via so-called Native Elm - i.e. write an extension in JS, which will be mapped to Elm's function. Native Elm is how all the core library is implemented. But again, you'll have to be super careful there, things could go even worse, e.g. if you return a null, and Elm's function should return Int, you'll eventually get a runtime error somewhere INSIDE Elm code once it tries to apply e.g. multiplication or another int-specific funciton. * No production libraries. Like, gathering all the runtime errors and sending them to Rollbar, sending metrics to GA or Mixpanel, logging packages, etc. Things, which are must for production-ready apps. * A lot of browser APIs are not covered by Elm's standard lib. No File API, no Service Workers, etc. You can do them via ports (JS intro), but again - you will work in JS unsafe realm. Evan (the creator of the language) promises a lot of improvements in this field in the next version of the language though. In your real app you gonna use ports a lot - even getting a width of a DOM element is not a pure function, so you have to do that via ports, getting a signal of it. Still, I think this is a very interesting and promising language. It allows you to build very robust and easy to understand core, and move all the impurity and unsafety out of it to JS side, which is very useful for mid-large size projects. I think it's a very promising technology.
- Is it ready for production? Well, it depends… And this is probably not the answer you want to hear from me, so I’ll try to elaborate. If you build a next-gen main application for your company, and it gonna take 60 developer months and you bet all your money on it, then I wouldn’t take Elm. I’d probably take TypeScript. Since you have to have the talent pool of developers to hire, Stack Overflow answers for most problems which can arise, solid IDE and plenty of packages to use. Ironically, Elm is supposed to be used in large projects like this, but IMHO a bit too early for it. Some mid size non-central internal tool - I think a good candidate to try it out. Small front-end projects - doesn’t really matter what language to use, IMHO, as long as you can keep the whole app in your head. But if you’re building large JS projects, want to build large JS projects, want to know more how to build mid-to-large JS projects, you should really look into Elm. It will show you how to work in a pure language, how you can manage state and side effects in front-end projects, how you can build apps using Elm architecture, which is a very elegant architecture. It’s also a quite gentle introduction into functional programming, without head-cracking concepts like in Haskell. So, I encourage you to try it out, it will make you a better JavaScript developer after all. That’s it, thank you!