It better be "overloaded" with irresistible benefits for you to invest X hours of your (too) valuable time in learning yet a new programming language, right? It better have: clean code, a crystal-clear syntax, an unexpectedly simple design pattern... But these are all terms already describing the Elm architecture itself!
The famous Elm architecture!
One of the most compelling reasons why so many developers have found themselves "enamored" with this functional programming language.
So, instead of being hesitant to learn Elm for... no specific reason — other than stubbornness or laziness — how about being hesitant for a reason? Any solid reason that you can find.
But for that, you should first check it out and evaluate it yourself, right?
So, let's see what the Elm architecture's powerful simplicity stems from! Then, let's dig some more for other strong reasons why you should even consider learning Elm.
1. The What Before the Why: What Is Elm, More Precisely?
A functional front-end programming language, with its own an ecosystem, that compiles to JavaScript.
Now, if you find comparative definitions to be a bit more relevant and “enlightening”, let me add that:
As compared to Ember, React or Angular (and the list could go on), Elm is significantly lighter and, therefore, remarkably faster.
And, in addition to these 2 clear selling points, Elm “owes” its reputation among front-end developers to its capabilities of:
- empowering them to refactor large projects more confidently
- easing their “issue detecting” tasks
- generating developer-friendly error messages
2. Introducing The Elm Architecture: A Quick Overview
Simplicity.
This is the word to best describe Elm's specific pattern for structuring applications.
And when you say “simple and clear” architecture, you just know that it translates into:
- code reuse
- modularity
- extensibility
- quick and easy testing
Basically, a clean and simple way of architecting web apps will always fill any developer with confidence.
Confidence to tackle complex app projects, knowing that whenever you need to refactor them, to extend their functionality with new features... they won't break.
Now, let's see which are the 3 main “pillars” that Elm's simply powerful and empowering architecture rests on:
3. It Boils Down to Its 3 Essential Parts: Model, View, and Update
Whether it's just a “Hello World” or a highly complex app that you build using Elm, the very first step to take is registering its three essential pieces:
main =
Html.beginnerProgram { model = model, view = view, update = update }Tip: the order doesn't matter really; feel free to pass the “view” function first or the “update” one, for instance...
And now, let's bring into the spotlight these 3 main parts specific to the Elm architecture: model, view, and update.
3.1. Model
It's the very state of your (future) Elm app.
… the function which describes/stores all the dynamic data (its “state” at a given time) that's moved around in your Elm app during execution.
The model can be a number, an object, an array or pretty much any state that could change in your app.
3.2. View
View is the function of the Elm architecture “responsible for” displaying the app state. Or "in charge” with its visual part, if you wish.
It's where you define how your Elm-based rendered program should look like.
And here's how it carries out its role:
- it returns HTML
- the Elm runtime is assigned to check whether the DOM matches what the View function returns
- … relying on virtual DOM to streamline the whole process
3.3. Update
More than just “a” function, Update is a whole “set of” functions... Functions to update your app's state with, to make it dynamic.
In short: each action/function creates a brand new state out of your app's current state.
And here's the Update function “in action":
It receives the Model and a Msg; practically, there's a case statement where you can control every possible Msg in your Msg Union type.
4. Overall, Why Would You Love the Elm Architecture?
OK, now that we've gone through the specific elements of Elm's design pattern, which also stand for its major strengths, let me attempt at answering your ever-present question:
“Why should I give Elm a try?”
… with a list of benefits:
- easy time-travel debugging (stemming from its conveniently restricted state)
- a surprisingly easy to understand programming language, even for junior developers
- it streamlines the entire testing process since it's designed around pure functions and update commands
5. And 3 More Good Reasons to Check Out Elm
5.1. It Appeals to Your “Passion” for Clean Code
For Elm's code is just... pure music to a developer's ears. To a developer “obsessed” with clean code (like you?).
The “update” function handles the messages sent by the “view” function and updates the state of the app (the “model”).
Note: the top line stands for the function definition... always; and this is no news to you if you're already familiar with the functional language code.
It defines the types coming in and out of the function.
Next, the second line is for naming the arguments:
function update(action, model){.Next, there's a case/of statement, not very different from a JavaScript switch statement.
Tip: each line that comes after an → defines the update to be returned for that given action.
5.2. Its Compiler Is Pure Awesomeness: Developer-Friendly Error Messages
Thanks to its compiler, Elm's famous for its particularly tough error catching.
And for its friendly compiler-generated error messages, as well, needless to add:
Some truly “enlightening” descriptions of what you did wrong, so you should know precisely what to correct.
… what values escaped your “vigilance”, for instance.
The result(s)?
- less live debugging
- fewer errors detected in production
5.3. You'll Love It if You're Already “In Love" With Strict Typing
As compared to a procedural language, a functional one — like Elm here — enforces strict typing:
It constrains the developer to be crystal-clear regarding his/her data types between input and output. To think through both the “shape” of the data coming into the function and the “shape” of the data emerging from the function.
By contrast, a procedural language treats programs as sequences of steps to take. Of operations to carry out, one by one, in a specific order.
The benefit? Zero ambiguity; you're constrained to define, from the start, what comes in and out, there's no room left for “mystery” inside your code.
For unwanted surprises that might spring up.
The END! This was me trying to shed some light on the Elm architecture — on the specific elements “responsible” for its luring simplicity — and on some of the biggest strengths of this functional programming language.
All which, hopefully, will answer your question:
“What's all this growing hype around Elm?”