BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Podcasts Richard Feldman Discusses Elm and How It Compares to React.js for Front-End Programming

Richard Feldman Discusses Elm and How It Compares to React.js for Front-End Programming

Bookmarks

In this podcast Wesley Reisz talks to Richard Feldman about Elm, a front-end focussed functional programming language that compiles to JavaScript. Feldman covers being an early adopter of Elm, the architecture of Elm, immutability, semantic versioning and more.  He also compares Elm to some of the JavaScript frameworks including React.

Key Takeaways

  • Using a compiler to catch errors at compile time instead of at runtime makes refactoring the code much easier.
  • Incrementally replacing small parts of an existing JavaScript application with Elm is a safer strategy than trying to write an entirely new application in Elm.
  • Elm packages are semantically versioned and gated by the publishing process, so minor versions cannot remove functionality without bumping the major version.
  • The UI in an Elm application results in messages that transform the immutable state of the application; this allows a debugger to view the state transitions and the messages that triggered them, including record and replay of those messages.
  • Elm has been benchmarked as being faster than Angular and React whilst also producing smaller code, which is attributed to the immutable state and pure functional elements.
  • 01m:50s Richard works for NoRedInk which makes grammar and writing software for English teachers.
  • 02m:05s The software grew out of a software tool the founder commissioned to help with his class marking.
  • 02m:15s From there, other teachers wanted to use the software and so the company was founded to market it.
  • 02m:25s There are over 2 billion questions answered in the system and have over 20 engineers.
  • 02m:35s About 1/4 of the users are using iPads, but the application is browser based.
  • 02m:55s Multiple choice is the last resort; there are a lot of custom UIs for each of the different concepts that are being taught.
  • 03m:15s The back end is Ruby on Rails, with some Elixir services, and as we’ve scaled up we found that Ruby isn’t scaling where we need it to be.

What triggered the move to Elm?

  • 03m:55s Before Elm, the application was a JavaScript jungle with some jQuery, Backbone, Angular and a big mess. When React came out, it became the dominant framework.
  • 04m:50s For a variety of reasons, Elm was attractive for functional programming reasons and used for a personal project.
  • 05m:10s After a big refactoring exercise at work, the advantage of using Elm would have made it significantly quicker to write.
  • 05m:25s One of the reasons we didn’t move to Elm directly was due to the risk of bringing in new technology, but it was obvious it would have been a better choice in retrospect.
  • 05m:30s The idea to write future code in Elm came out of the back of those thoughts.
  • 05m:40s Elm was introduced in a small feature, and then in another, and before long Elm had become the dominant technology used. 

What were the advantages?

  • 06m:00s A lot of the advantages came in the feedback loop; we had to react to changes from the classroom as they find them.
  • 06m:25s Elm is conducive to change, since the compiler can really help where all the corner cases are; when it compiles, it generally runs right the first time.
  • 07m:00s Compared with React, where changes were typically made that would cause failures or logic errors.
  • 07m:25s Using Elm allowed the compiler to do the work and have shorter refactoring time; even taking into account the retraining time for new users, we would have saved more time than the run-debug loop of React.

How did you sell the change to leadership?

  • 08m:20s It was introduced piecemeal into the system, incrementally adding elements to a page to see how it would go.
  • 08m:45s It seems a common way of introducing a new language successfully involves introducing it little by little instead of writing an entirely new project in a new language.

What is a good use-case?

  • 09m:30s Anything you’re afraid to maintain.
  • 09m:50s there are hotspots in the code which get changed frequently, consider having an Elm service that can be used to add the new functionality and have a JavaScript wrapper.
  • 10m:30s It makes it possible to create a pull request of hundreds of files and know that it compiles, and so isn’t going to introduce errors.

How do you onboard new people?

  • 12m:00s Pair programming is a good way of introducing both the existing codebase and the programming language to new hires.
  • 12m:10s The compiler helps out a lot; there’s a guardrail around what can go wrong, with an error and links to more information about the issue.

What is Elm?

  • 13m:05s Elm is a functional programming language that happens to transpile into JavaScript, that allows you to write delightful web applications.
  • 13m:30s It provides great compile error messages and compiles code so you don’t have runtime error messages.
  • 14m:00s We had Rollbar checking errors (which catches errors in the existing JavaScript code) but we get no errors from Elm, because they’re already caught at compile time.
  • 14m:55s Elm is designed to force handling errors instead of just crashing.
  • 15m:00s All the primitives are built on this solid foundation, and so the libraries inherit this by default.
  • 15m:10s Elm doesn’t have a concept of null, unlike Java or JavaScript.
  • 15m:35s Elm has an optional value which forces the programmer to handle the case when the value is not present. 

What makes the Elm compiler so good?

  • 16m:50s Elm is one of the first languages that considers the compiler as an assistant, instead of something that’s just producing machine/byte-code/JavaScript.
  • 17m:15s Elm is the most cited language for good error messages.
  • 18m:00s The language is designed around a good user experience where things don’t crash.
  • 18m:30s Array access is explicitly optional because the object might not exist in the location (for example, it’s out-of-bounds).
  • 19m:00s Array.get gives a optional container back, which encodes whether a value is present or not.
  • 19m:55s There has been similar work for both typescript and flow that allows you to check for null; but Elm has this built-in and supported across the board for libraries.

How does Elm work?

  • 21m:00s npm -g elm will install all the parts required to use Elm.
  • 21m:40s You can run elm make to generate an application, along with a template HTML that will import the code.
  • 22m:00s If you’re using an existing build tool, such as gulp or grunt, and you want to integrate it in along with existing tools like webpack, then Elm can integrate with that as well.
  • 22m:10s The JavaScript library system is much larger than the Elm library system, so production applications often use both.
  • 22m:30s Elm uses a Model-View-Controller approach to build your applications.
  • 22m:35s The Model is used to represent the data of the application, as an imutable value.
  • 23m:00s Unlike other tools and approaches, Elm has a single Model store, instead of having lots of per-component stores that might exist in other systems.
  • 23m:10s The Elm runtime will take that model and pass it to a View function.
  • 23m:30s The View returns a virtual DOM that describes what the page will look like.
  • 23m:50s The update function, which is called in response to user actions on the page, will return a new immutable model representing the new state of the application.

What’s the size of the generated code?

  • 24m:45s There’s a reasonable amount of code, but it’s about to get smaller. However, it’s generally smaller than a React-MVC application.
  • 25m:20s The next release looks at asset management and dead code elimination; where a library might have additional utility functions that may not be needed.
  • 25m:50s Preliminary numbers suggest that the resulting code is really small - it should be a really great release.

If the state is immutable, isn’t the state update expensive?

  • 26m:25s The data structure isn’t cloned the whole time; it shares a lot of the nodes that were used in the previous state - and this is handled automatically by the runtime.
  • 26m:40s It performs better than Angular, Ember and React. [See http://elm-lang.org/blog/blazing-fast-html-round-two for more details]
  • 26m:55s Because it’s side-effect free, there are a lot more optimisations that can be performed that aren’t applicable to general JavaScript applications.

How is debugging improved with Elm?

  • 28m:25s When the user interacts with an Elm application, messages are generated from interaction in the user interface.
  • 28m:45s The messages encode the data of the user interface that triggered the component, and are sent to the update function.
  • 28m:55s This allows the debugger to print the message stream of what is happening in the application as it runs, with no changes required to the application itself.
  • 29m:00s It’s also possible to see the state of the model at these times, so you can time-travel backwards.
  • 29m:40s Since everything is built on this, it comes for free in your application and any other libraries from the Elm ecosystem.

Where are the sticky parts of Elm?

  • 31m:15s Elm makes a wall between the Elm ecosystem and the JavaScript ecosystem.
  • 31m:45s JavaScript interop allows calling out to libraries which exist that don’t or can’t be written in Elm, like large DOM manipulation.
  • 32m:45s Elm talks to JavaScript by sending and receiving immutable messages of data.
  • 33m:00s The other difference is that Elm is purely functional, so can’t deal with changes or side effects.
  • 33m:40s It’s similar to when you’re interacting with servers; you send a request and get an asynchronous response back later.
  • 34m:00s Elm doesn’t have a server-side story at this stage; so although you can write JavaScript on server with node, Elm doesn’t have an ecosystem for the server yet.

What’s the Elm community like?

  • 35m:00s There’s ElmConf in St Louis (attached with StrangeLoop), and ElmEurope in Paris.
  • 35m:30s The way to judge communities is what the experience is like for beginners - Elm is generally very friendly and eager to help out beginners.
  • 35m:50s The ecosystem is much smaller; Elm has its own package manager, and is really strict about a couple of things.
  • 36m:00s The first restriction is that the Elm package manager prevents publishing mixed Elm and JavaScript code.
  • 36m:35s This means that all the code published is in pure Elm, but it grows organically as functions are re-written in Elm itself.
  • 37m:00s The other benefit is that packages are semantically versioned automatically; if you remove a function then try and publish a minor version, it won’t let you until the major version is bumped. This makes the upgrade path much easier.
  • 37m:30s One attendee at QCon remarked that they migrated to Elm not because of the benefit of the language but the fact that they could move away from the breakages of packages in flux with npm.
  • 37m:45s Culturally the community has well-named packages, like elm-css or elm-test.
  • 38m:00s It means that developers tend to find existing packages and use them, rather than re-inventing their own one each time.

Resources

More about our podcasts

You can keep up-to-date with the podcasts via our RSS Feed, and they are available via SoundCloud, Apple Podcasts, Spotify, Overcast and the Google Podcast. From this page you also have access to our recorded show notes. They all have clickable links that will take you directly to that part of the audio.

Previous podcasts

Rate this Article

Adoption
Style

BT