Elm Europe 2017 - Richard Feldman - Scaling Elm Apps

Elm Europe · 41K views · 2017 · 59:51

Open on YouTube

Functional programmingWeb developmentSoftware architecture & designtalkdated

Why Hacker News recommends it

The standard pointer for anyone asking how to organize larger Elm codebases.

What it is

Richard Feldman's Elm Europe 2017 talk on how to structure and scale large Elm applications, including when to nest messages.

Recommended by 2 HN commenters across 2 different months, 2019 to 2022.

What Hacker News said

Recommends z5h · 2019-03 · on “Ask HN: Anyone Using Elm in Production?”

You'll probably want to watch Richard Feldman's [Scaling Elm Apps]( [this video] ). I built [Component Result]( [LINK] ) to help with a pattern that occurs when scaling up apps. I'm not clear what you mean by or expect to be problematic with by cross-cutting concerns. Feel free to ping me, z5h, on the Elm slack.

Recommends hombre_fatal · 2022-03 · on “Tao of Node – Design, Architecture and Best Practices”

You can write this sort of guide for literally any tech, even the ones you think are better. I've been using Elm since it came out and I use it for everything, but you could write a "Tao of Elm" that's just as in-depth as this. Just watch rfeldman's talks about how to structure large Elm projects ( [this video] ) or watch the community chat about how to do it, it's an open question. For example, the Tao of Elm would give pointers on what you should send over ports, how granular you should even make ports, how to pick Msg types (LogIn User | LogOut vs. SetUser User), how to build a good Model, when to nest models, (a big one:) how to build parent/child communication, what should be implemented on

Cites rtfeldman · 2020-11 · on “How I write Elm applications”

From early in the article: > This [flat Msg design] does work, but at some point it becomes cumbersome to support a large number of constructors. As guessed, I'd personally stick with the simpler flat approach the article acknowledges and then tries to improve on. Nesting that data structure is (according to the article) an ergonomics improvement, but then the rest of the article is about how to solve ergonomics problems caused by the very nesting that was supposed to make things nicer! Given that, surely it's reasonable to raise the question of whether this nesting was actually an improvement after all. My conclusion at the end of the article is that in retrospect nesting did more harm than