Automating away the tedium

Now that we've seen how Elm cleans up lots of the syntactic noise of HTML, let's explore what really sets it apart from HTML.

The real power of Elm comes from the resilience in the face of change that it gives your code. When you're writing raw HTML, it's easy get something up and running, but that's just half the battle. Your idea of how your site/app should look and function will change. You'll want to add new features as well as tweak old ones. Plus, there will be obstacles you can't possibly know about until you actually start building things out. You must take measures to keep your codebase maintainable if it is to adapt to your changing needs.

Writing maintainable UI code in Elm

When you think about what it means to build a graphical user interface, it boils down to communication. You have some information, and your goal is to give the user a clear and faithful visual representation of it. Anything going on in a GUI that doesn't serve to communicate something detracts from the user experience. This means the job of the front-end developer is about humans more than it's about computers. Your code may act first on the computer, but it's all meaningless until it acts on a human mind.

However, the human-oriented part has historically been a small part of the job. Even once you've determined exactly how you want to visually represent your data, you will typically spend hours wrangling with the various quirks of all the different browsers to get things looking that way. You basically have to explain to the browser step by step how to construct a UI that matches your vision. In short, the bulk of your time coding is spent working out implementation details rather than fleshing out the actual user experience.

Anyone who writes software knows that code married to implementation details is the arch-enemy of maintainability. Details are prone to change, and every hour spent working out a detail that ends up changing is an hour wasted.

What's more, that hour you imagined spending on that small detail can end up snowballing into hours. What theoretically seems like a minor change can end up affecting huge parts of your codebase. It's just like you're building a physical structure--take out a single brick in the wrong place, and you can end up toppling an entire wall. Once your project reaches a certain scale, parts of its structure will rely on other parts to stay standing.

Elm mitigates this problem by following principles of functional programming. When you think of GUIs as visual reflections of underlying data structures, it's clear that they

To illustrate, let's see how that even our simple static to-do list page becomes easier to maintain when we separate our data (our model) from the visual representation of that data (our view).