Nice example. I’ve gone up to 3k loc myself in one elm file. It became hard to navigate, but overall felt just fine (once I suspended my intuitions from previous dev work). One thing I noticed though is that this happened accidentally. I would have organized and scoped / localized much differently had it been intentional (convenience functions at the root level that really should have been nested in a scope).
The only pain I recall though was the editor experience. I was thinking a hierarchical minimap / outline could be really awesome for this. Picture your typical project tree of files, but repurposed for functions / scope. Scrolling and opening closing necessary leafs in the hierarchy very quickly would have mitigated most if not all of the pain (filesystem after all is just an organized hierarchy).
It’s actually kind of funny how we’ll break out view functions at the root level that are only called from one function (no reuse) and could totally be scoped (or even unnecessary except for the readability of naming). For example the viewReadme in the elm packing site’s source is an example of this, package.elm-lang.org/Docs.elm at master · elm/package.elm-lang.org · GitHub is never called outside of viewContent and yet it’s at the root scope. Seems totally fine to me, but also only done this way for readability / traditional editor experience. I wonder what I’ll end up with if all of my functions are at their most narrow scope. Honestly could end up being a mess, but I want build up a big codebase though just to see if it really proves to be terrible. I’m a bit worried about horizontal line size, especially with the elm convention of 4 space indentation.
P.S. your section block comments are crazy! Very original.