Coming From Elm

Coming from Elm

This is part of a series of articles on how I've come to use Mithril. This isn't a basic Mithril tutorial -- for that please see Mithril's own excellent introduction.

I found Elm by accident, from a random comment on Reddit, and used it on a few personal projects.

Given I hadn't before used a purely functional language for anything other than toy experiments, using Elm also meant getting to structure non-trivial amounts of code functional style. That part wasn't hard. More challenging was learning to work with the strict type system.

Among my takeaways was experiencing firsthand a saying about ML-style type systems versus dynamic ones: with the former you spend your time in up-front design, and once things compile it's smooth sailing; with the latter it's far faster to get started and to "design as you go", but you spend time backtracking and fixing issues the compiler can't catch. (Some companies using Elm choose to start out with JavaScript, then to rewrite in Elm once the approach has solidified.)

Much as it was "fun" to use Elm, I came to realize the fun was due learning/working at something new (and the satisfaction of getting it to work) ... and that novelty of syntax or approach wasn't a good enough reason to choose a language.

What would be a good reason to choose Elm is its powerful type system (with convenient type inference): I hugely appreciated the fearless refactoring and programming-in-the-large that enabled. Plus, it worked for me personally to near fully think through/design things up-front.

One aspect that won me over completely was Elm's way of writing HTML, using functions. I'd come across it before with React's React.render(), had thought it clunky and verbose (and, embarrassingly, hadn't thought to alias it to something shorter), and had used jsx exclusively as it was available, familiar, and in my thinking at the time technically preferable.

Since Elm didn't have a jsx-like system (or have it natively usable) I pushed ahead with its existing hyperscript-like facility and quickly found it was far more powerful and versatile to express HTML in javascript, rather than the other way around -- be it to context-switch as did jsx, or to express control flow-logic with HTML constructs à la Angular. I've been suitably educated (#*).

I also really liked "TEA" (The Elm Architecture) as of v0.17, for cleanly separating concerns, and for just as cleanly recombining them in usage. Related, Elm's conveniently managed app-level model, which is "automatically" provided to the view function to render from, and to the update function to, well, update. This makes for a standardized, near-formulaic app structure that takes care of basic wiring, letting one focus on app-specific behavior. (TEA has been adapted or copied in several libraries/frameworks since.)

The code listing below hints at an Elm application's modular structure, and at its standard, repeatable initialization.

Code Listing: Elm app structure

-- Main.elm
module Main exposing (..)

import Html

import Effekts exposing (..)
import Init exposing (init)
import Types exposing (..)
import Update exposing (..)
import View exposing (view)


main : Program Never Model Msg
main =
    Html.program
        { init = init
        , update = update
        , view = view
        , subscriptions = subscriptions
        }

My reason for then not adopting Elm is mentioned here.

What I still hope to take with me is an Elm-like app structure that cleanly separates/recombines app concerns.

---

Continue to Why Mithril