Ryan, the big thing I think you're missing is the type of init. The initial state of the app is based on the URL the user navigates to. This allows for a crucial piece of SPAs, namely, the ability to retrieve state when based on the URL that the user first enters.
That being said, if we could tolerate some kind of "loading what the original URL was" state, one could simplify the API a fair bit. Requesting URL changes are just commands; we have those in *update*'s return type already. Receiving them could be by a subscription that takes a *Location -> Msg* function. It's on the client to keep track of which messages are from the URL changing and which from other events. Although I'm excited enough by the idea of *synchronously* determining the initial state of the app from the URL (first paragraph), I think Ryan raises a particularly good concern regarding composability-- what happens when there are three libraries that all want to define *program* but we can only use one? At the moment I think the best we can do is hope no such other libraries surface. -- You received this message because you are subscribed to the Google Groups "Elm Discuss" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
