I've never tried it your way, so maybe I'm missing something here. But thinking in terms of pages seems like a very useful abstraction to me. I can't keep the whole application state in my head at once, so I want to be able to look at a small part of the app and know that I don't need to think about anything else right now. (It maybe won't be "literally just this page", but "this page plus a small number of well defined mechanisms for bringing data in and out of it".) I wouldn't want to give that up, and I don't know how I'd split the state if not by page (or at least something similar, like "groups of closely related pages").
If my model logic is happy to be modified by any page, and if there's a bug in my model logic, then I have no idea where to look.
You can think of it as an API. If your API is called, should it work differently depending on whether the request came from a browser or from a terminal curl? Probably not.
Similarly, if you have a message that, calls for your model to be changed (for instance, adding a product to the cart). That message describes cart logic. The product could be added directly from the product page, or the frontpage, or from a suggestion in another product page. It is probably not relevant to the cart how exactly the product came to be added.
Not all the model is like that. There is a subset of the model which exists only to describe the state of the view. But, usually, a significant part of the model is dedicated to page-independent data.
> I want to be able to look at a small part of the app
In my app, the small part of the app I'm going to look at is a single feature which may be used in multiple pages. It is easier for me to keep a consistent behaviour if that feature is independent from the view.
Fair enough. I get the sense we're working on fairly different apps.
It's also possible that if the app I'm working on were structured differently, we'd have done things more like the way you're doing things. I'm getting vague thoughts in my head along those lines, which I'll have to let ruminate and see if they go anywhere.
> If my model logic is happy to be modified by any page, and if there's a bug in my model logic, then I have no idea where to look.
I don't mean this sarcastically (hard to convey tone in written form), but is this genuinely something you have encountered with Elm in practice? Even with the time-travelling debugger?
No. Like I said, I've only worked on one Elm app, and that one doesn't let model logic be modified by any page (with some well-defined exceptions). But it's what I'd expect to sneak in if we hadn't architectured it to forbid that kind of thing. I agree that the time-travel debugger would help, but... I guess, even if that makes it less costly, I'm not seeing the benefits.
If my model logic is happy to be modified by any page, and if there's a bug in my model logic, then I have no idea where to look.