I actually wrote a thingo on this recently. Modern front end has essentially the exact same challenges as a server which provides its API with sockets/websocket

I actually wrote a thingo on this recently. Modern front end has essentially the exact same challenges as a server which provides its API with sockets/websockets/events. A back end server with this configuration would have a handler layer for IO, business logic layer and data layer. DI and IoC ensures that the IO layer doesn't know about the data layer as the logic layer takes it as a dependency. The IO layer consumes the logic layer and the logic layer doesn't care/know about that. Front end is exactly like this. The data source is REST rather than a database. The UI layer is an event source and consumer. The logic layer notifies its consumers (the UI layer) that there has been a change. The rendering library doesn't matter, it's just a mechanism to represent the events it consumes. The problem in front end is there has been no rational mechanism for DI in the libraries. React relied on the service locator pattern to deliver dependencies so to ensure quality decoupling you would need to have wrapped your components with a million functions. ``` withTheme(withUsers(withSomethingElse(withAnotherThing(Component)) ``` So rather than that, just use a single "service", redux, and forget about DI. Everything can do anything and all your logic is done inside that one thing. Angular is no better. While they have a nice DI solution, it still relies on concrete implementations rather than abstractions. So your business logic must live within "angular services" and can not simply be "javascript" consumed by a rendering library. Vue just missed the point entirely. React context packaged this problem in an ergonomic box and, in my opinion, is a fantastic solution given the constraints. However at this point, the meta in front end programming is so irrational that it boggles my mind. In the following example, you can see that I have an application which uses React as a renderer. React consumes a package from /platform. The package has no relationship to the presentational layer. I could run the units in the package inside node or the browser console and it wouldn't care about its rendering library. The "PostStore" class exposes an API which consists of a getter and a stream. React consumes the stream, because it needs to be notified on changes. https://stackblitz.com/edit/react-ts-biohay?file=gui%2Fapp.tsx https://stackblitz.com/edit/react-ts-biohay?file=gui%2Fapp.t... Conversely, this loose coupling means that the view renderer is a small portion of the application. I could swap it out for another renderer. Preact, Svelte, whatever. Front end is a mess.