Really cool app! I'm going to study this. I'd love to put the app I'm working on up as an example to share lessons learned but it's commercial work, so I'll have to make another hobby one in the future and use that :)

I alluded a bit to it in another comment here, but I'm not entirely convinced that the "you shouldn't write components" is a good design target overall vs. just being a necessity because of the limitations of Elm the language right now.

It probably hinges on what you mean by 'component'. When I say 'component', I mean a bit of UI I'm planning to reuse across multiple pages, where there might be some private model, where I would not want the internals of that model duplicated across and polluting otherwise clean page models.

Here is an example that comes to mind: I have common functionality across pages in my app where I want to let the user edit a database field.

To do this, the user can select the list of fields from a drop-down or they can type the field name into a search box, with choices being displayed as they type in real-time; they can then click on a choice and edit that field.

To submit the edit, they click an 'Update' button.

Now, this functionality is shared across different pages in my app. None of these pages should, IMHO, necessarily have to care about the intermediate states of the field-list as it is auto-completing. I simply want a function I can call from any view like this:

renderChoiceThingy : List FieldChoices -> ChoiceThingyModel -> msg -> Html msg renderChoiceThingy fieldsToPickFrom model actionOnSubmit = ....

Not only might I want multiple instances of this same thing across many pages, but I'll also want multiple instances of it on the same page sometimes. For example, let the end-user build up a list of changes and then submit them all in a batch or cancel them all at once.

Without treating this like a self-contained unit, I'm now duplicating model bits in all my pages that use this function. So it's nice to wrap that control up into a module, with its' own 'update' and 'view' and have appropriate parameters to allow the proper message types to work.

Another example (not one I've implemented); say you have an interactive colour picker, that you can click on an icon to exapnd, select the colour you want by changing sliders interactively, then have the picker disappear and the page know what colour you've selected. To me, the containing page shouldn't care about all that slider stuff and all the messaging and updating that goes on, just to draw the picker.

Would love to hear other Elm devs thoughts on this. These are the kinds of examples I don't see directly addressed when people say "don't write components". Though I suspect, having not used other 'component' frameworks like React, that people might generally mean something slightly different to what I'm thinking when they say "no components". Really interested to find out what others think about this.