Elm Europe 2017 - Richard Feldman - Scaling Elm Apps

What people said

hombre_fatal · 2022-03 · Recommendation

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 ( [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 the JS side instead of Elm side, how to represent fetch/wait/response loop when making http requests, etc. and then the trade-offs of all of those suggestions. Being able to compile a list of best practices doesn't mean something sucks. Though the comparison to Elm isn't all that great because it doesn't even compete with Node, and if you do use it on the server with Elm.worker, you could write a whole other guide of best practices around that. Anyone who has built a massive Elm client is shimmering with trail/error knowledge that they could share in this kind of format. Anyways, be wary of developing a knee-jerk "JS sucks" response.

Read the original HN comment ↗

z5h · 2019-03 · Recommendation

You'll probably want to watch Richard Feldman's [Scaling Elm Apps]( [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.

Read the original HN comment ↗

rtfeldman · 2020-11 · Reference

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 good, and knowing that, I would have happily left it flat. Incidentally, "leave it flat" is not my stance in all cases. For example, I gave a whole talk that could have been titled "when to nest" - [VIDEO] - and my most popular Elm project uses nesting in multiple places - [LINK] But indeed, in this case, I'd happily leave Msg flat and not bother with all the lens stuff!

Read the original HN comment ↗