AMA With Luke Westby
We met up with Luke at Full Stack Toronto Conference and invited him to do an AMA with the Tech Masters Community. Luke is a co-founder and partner at http://humblespark.com. He helps build the Elm community. Since Elm is steadily gaining popularity, Luke gave us a proper introduction.
How did you get into the Elm project?
Good starting question! I had been doing JavaScript primarily before that and was on, like, day 3 of trying to set up a reasonable build process for my company’s JS programs, and it just wasn’t working … too many tools to put together and connections to keep in my head. I went home that day all mad and just happened upon a video of someone demoing Elm.
I can’t remember which video it was, but there are so many good ones out there now, and it took this person like 45 seconds to set up a working Elm environment:
$ npm install -g elm(write elm file)$ elm-make ./Main.elm
That was it. Before that day I was, like, largely against compile-to-JS tools like ClojureScript and whatnot. But I was so impressed that I decided to try it, and I loved it. Been doing it every day since.
For the uninitiated: how would you describe Elm in relation to some of those popular tools and framework out there? (Angular, React, Babel, Webpack, etc.)
Elm is a set of things: a programming language, a set of tools, a core set of libraries and a UI framework. The language has a type system and syntax, which are much more similar to different ML-style languages than the type system of TypeScript or the syntax of JavaScript. The architecture (The Elm Architecture, as it’s known) bears some similarity to using React and Redux, but the language and platform apply lots of constraints so that you’re always writing stateless functions and putting effects like HTTP requests in a very specific place all of the time. So it’s made many decisions for you about how a UI should run, and you can focus on what it should do.
I don’t think it was mentioned before, the main site for the language is elm-lang.org. With regards to Babel, the Elm platform comes with a compiler called elm-make, which will produce valid ES3. So you’re covered there. Webpack, I think, is sort of an outside concern. You don’t need Webpack if you just want to write Elm, but you can also make the choice to incorporate Elm into your existing webpack workflow using elm-webpack-loader.
For somebody learning web development, do you advise starting with Elm or starting with the basics of HTML, CSS, and JS first? In other words: is there a fast path to adoption and learning for new developers, or…?
There is an expectation that you’ll need to know HTML and CSS. Similar to how React works by producing JSX, which is representative of HTML, elm-lang/HTML contains functions like div and span, which you need to have context for.
However, to get started with Elm, if you’re new to web development you just need to know enough JavaScript to call Elm.Main.fullscreen(). As your app gets more complicated, you may need to incorporate more JavaScript to inter-operate with things Elm can’t do, but there are people in the community to help you through that, and guides, and blog posts, and tons of stuff. So in summary, you should know HTML and some CSS, but you don’t need JS to get started with Elm.
How do the benefits of Elm make it worthwhile to go all-in vs similar architecture in JS like redux?
No runtime errors. Not having to stitch together mountains of libraries into a custom framework is helpful, too. It’s quick to get started working on your actual application instead of setting stuff up.
Can we say that one of the benefits of Elm is you step outside of the mess that is the JS ecosystem?
Yes! I always try not to speak too negatively of JS, but that was a huge plus for me. Then on the other side, there’s a pleasant experience for doing interop with existing JS stuff from your Elm app too.
Can Elm replace gaming frameworks such as Phaser?
I’ve seen rumblings of people developing game frameworks for Elm. I can’t say for sure if there’s something with everything you need available right now, but it’s something that can exist and be very nice in Elm. Foundationally-speaking, there are high-perf bindings to WebGL so all the basics are there.
Elm claims to be suitable for extending existing projects instead of requiring full rewrites. Have you used Elm as part of an existing project? Also, can you share with us some details of how it makes a great fit for that scenario?
Yes! There are a couple of avenues that Elm includes for doing JavaScript interop that helps to integrate into existing projects. The most simple of these is the embed function that comes with a compiled Elm program.
So, if you want to rewrite one part of an existing page that’s either been built with a different framework or is static, you can call Elm.Main.embed(someDiv) and have Elm only deal with that part of the page. Additionally, you can call that as many times as you want and have as many Elm programs running at once as you want.
Another facility Elm provides is called ports. Ports are exit and entry points from your functional Elm code into some JavaScript running elsewhere on your page. So you can do things like build a program that handles business logic changes for a React app, and accepts user input over a port and produce a new state from a port. You can read more about ports at https://guide.elm-lang.org/interop/javascript.html. We’ve decided to take the approach I just mentioned with a client, and it’s been working well so far.
Lastly, and this is very unproven up to this point, so use with care if you decide to try it, Elm’s virtual DOM is reasonably compatible with custom elements from the web component spec. Here is a link to a project written by the creator of Elm, Evan Czaplicki, which will automatically integrate an Elm app as a React component https://github.com/evancz/react-elm-components.
Part of the negative feedback for tools like React is lacking in performance with graphics (Elm touts its performance over all the other frameworks and has its own shadow DOM), so how is it with web graphics?
I think the performance comparison you’re probably referring to can be found in this graph: http://elm-lang.org/blog/blazing-fast-html-round-two. Elm is faster than things like React and Angular because of the constraints it poses. In React, you have all these lifecycle hooks, and in Angular, you have various data-binding things that get set up.
Elm doesn’t do any of that stuff — the virtual DOM is as simple as possible so it can do a straight diff-and-patch every time, and because all of your functions are stateless, it can confidently queue updates on the correct animation frame for each render. In addition to VDOM, though, there’s an Elm library for doing WebGL graphics: https://github.com/elm-community/elm-webgl.
Truthfully, I’m not too familiar with this library.
As your constraints go up, so too does your speed. Immutability is a hell of a drug.
It is! So for those who don’t know, all data types in Elm are immutable. Every change you make to a list or a record (like objects in JS) creates a new object, so you get a lot of optimization out of being able to reference comparison to detect change.
What are some examples of Elm being used in production? Any big adopters?
At the bottom of elm-lang.org, there’s a “featured users” list. Noredink is probably the company with the largest codebase still, but that’s hard to judge. Elm is definitely transitioning from the innovator phase to the early adopter phase, so I’m confident we’ll see bigger and bigger companies announcing they use Elm.
Speaking of immutable systems, how easy it is for debugging and tracing user flow?
Right now the available tools are very basic: you have a function called Debug.log which prints out string representations of data. But! If you watch Evan Czaplicki’s talk from this year’s elm-conf, you’ll see a demo of a brand new built-in debugging UI.
The debugger will be released with the next version of Elm, which is coming in days-to-weeks from now. It’s built right into the platform, no extra work required to set it up, and it gives you the ability to time-travel through user actions and then exports them and import them. So debugging not just for devs, but also for QA and customer support.
Some personal questions: what motivates you to contribute to such a project? How did you make the jump from a user to a core contributor?
I’ve been putting so much time into Elm because it totally changed my career. I have ADHD, and trying to finish a JavaScript project when you have attention difficulties is fairly nightmarish, or at least it is for me. Elm’s whole goal is to help you focus on solving your problems rather than stitching packages together and building architecture. So since using Elm, I’ve been tons more productive, and now that I have that momentum I’ve been putting time back into the project by speaking, writing, and contributing because I want others to get that same help if they need it.
The term “core-contributor” is a tough one in Elm. The first thing to make clear is that Evan Czaplicki does virtually all of the language design and development work. So being a part of the packages team on the org means mostly reviewing bugs and answering questions and benchmarking stuff. However, that’s stuff Evan doesn’t have time to do, so he can focus on moving the platform forward.
You can hear more about my motivation to use Elm in my elm-conf talk:
Who writes all the documentation?
Evan does. Community contributions come in, but he takes communication about Elm super seriously, and he’s very good at it. So most of the docs are his.
How do you balance your time between job and OSS contributions?
Mostly it comes from having the privilege to have been able to start my own company with that in mind. My partner and I both do client work, but he values Elm and open source as much as I do so most weeks our billable hours will be a little lopsided because I spend time on OSS and conferences and stuff too. It helps us out as well; We’ve had client leads and inquiries about hiring because of it.
Silly question — why the name “Elm”?
Because it’s a nice name. That seems like a silly answer, but I’ve heard that’s the reason.
How much of your Elm work that you do for clients ends up being refactored back into the language?
Not many. One bug fix comes to mind, but other than that the platform is more than capable of doing most things at this point, and once you’ve gotten up to speed, you become comfortable getting around things that have yet to land on the platform. Though, it does help to inform feedback.
That’s more how things work with Elm contribution. People use Elm, they go out and talk about it, and provide feedback in Slack and on the mailing lists, and then all of that feedback ends up forming into ideas for new features or changes.
Do contributors have a say in the roadmap? How do you manage your roadmap with Elm?
Yes, but it’s very holistic. It’s a lot more about communicating needs in the mailing lists and in conversations with people and finding a good basis for how to approach them than it is making PRs or adding line items to a literal roadmap. Like, I think there needs to be a performance benchmarking primitive in the platform, but that’s not on a list anywhere. We’ve just been talking about what’s the best way to do it.
What’s your workflow look like? (tools, process)
So I’ve got the Elm platform installed, and when I’m starting a project, I’ll just use Chokidar or Nodemon to run Elm-make on file changes, and load a static index.html file with a local HTTP server. As the project grows, there’s a point where I’ll be like, OK it’s time to switch to webpack.
I always keep the webpack config super simple. Here is a proper explanation of the setup. And then for production, things get built to static files and deployed like you would deploy any JavaScript client.
For unit testing, there’s elm-test.
I don’t tend to deal with CI myself and don’t want to give an answer that is more guess than solid thought.
Elm-test is really great. It provides regular unit tests and property-based testing. So you can generate random inputs for functions and make assertions about the output. For this one client, since we’re doing an integration with React, we started with create-react-app, ejected the project and just added elm-webpack-loader to the config. Although, if we weren’t doing that I would do it quite the same as I described for my personal local work.
The Elm platform is very portable, and we haven’t had a problem running it inside Docker or anything like that.
Do you have any advice for anybody looking to contribute to big open source projects?
The first piece of counsel is that ramping up on open source contribution takes much time. There are subtleties to every project about how people communicate and how decisions have been made up to the point. When you want to contribute, those are going to be hard to understand all at once. So patience and willingness to listen to maintainers’ advice are key. (Of course, if the maintainer’s “advice” is mean or unwelcoming, then you shouldn’t have to be patient with that.)
The second is that you should use the project you want to contribute to before you contribute. There seems to be this interesting disconnect of “open source contribution” as a thing for its sake, rather than contributing to a thing because you see something that needs to be different and you have the time and understanding to fix it. So if one day you just decide “I want to contribute to x,” and you’re not using x, and you just decide to dive in, you’ll probably experience a lot of frustration. The best open source contributions are driven out of need and genuine understanding of what needs to be different.
Also, since I’m up on a soap box … you don’t have to be prolific with open source stuff to be a “cool” developer. Open source contribution really does require the privilege of time, and if you don’t have that and can’t make contributions, that doesn’t mean you’re less capable than people who do. It just means that you and they have different priorities and commitments. So feeling bad because you don’t contribute to open source might not be a good motivation to start if it means you’ll be overextending yourself to make it happen. I know some hiring folks at a company in the U.S. that would always send around GitHub profiles when people applied for jobs, and I would get really upset when I heard about it because that’s so far from a good indicator of someone’s abilities.
On that note, with Elm, do you have a standard that you follow for pull requests?
There’s a little bot that comments on PRs and comments and asks you to review some things before moving forward. Process-bot has one repository available. Follow their code on GitHub.
Contribution-checklist: Create better issues and pull requests, go through the checklist!
The quick summary is large PRs that come in without any prior discussion probably will not be accepted, at least until that discussion is had on the mailing list or somewhere else. Small PRs for bug fixes are expected to be thorough and present alternative fixes and explain why the chosen one is best.
As a reviewer, do you have some rule about PRs staying around until everyone’s had a chance to review?
On core stuff, it’s pretty much if Evan wants to merge it. There is an unofficial group for shared work on Elm packages and documentation. There’s also Elm Community on GitHub. On those packages, there’s an assigned maintainer to make the final call, and a fallback if people drop off the grid. Another maintainer from a different package can merge if the primary maintainer is taking too long.
Can you elaborate a bit more on how Elm uses requestAnimationFrame?
Sure! So as a user you provide an initial model, a view which is a function of the model that produces virtual DOM data, and an update function that is accepting incoming messages and updating your current model accordingly. Those messages get placed on a queue, and when the queue is populated the Elm runtime will process each message and get a new updated virtual DOM structure.
The trick is, once messages start coming in the view isn’t updated right then, a view update is simply enqueued. So even if there are more messages processed between now and the next time, the browser is going to refresh, it doesn’t bother to touch the DOM until it’s processed everything and the browser is ready to repaint. So you could have several updates to your model very rapidly, but it’s still only going to change the DOM once, and it uses requestAnimationFrame to queue that update. Also, since there’s no life cycle and the event bindings are really simple, the runtime doesn’t need to worry about timing and execution of all those extra things. It just calls patch(domNode, oldVirtualDom, view(model))
So how much different would the comparison benchmark have been if requestAnimationFrame was used to compare Elm against React, despite the fact that it’s not a fair comparison?
I’m not sure. I know React has its own scheduling stuff that it does. I think that blog post I shared about the benchmarks goes into pretty great detail about how the comparisons were done. I can also share the repo: https://github.com/evancz/react-angular-ember-elm-performance-comparison, comparing performance of Elm, React, Angular, and Ember.
Many thanks to Luke for attending the AMA! You can follow him at @luke_dot_js. If you’re a framework evangelist and want to share your success stories with the community, sign up at TechMasters.chat, and we’d love to hear from you!
