Your opening statement:
One place where React struggles is when one wants an event in a child component to “bubble up” to its parent. Basically, one needs to pass an action function (with a captured reference to the parent’s state).
React’s primary use case is single page applications. The primary premise of single page applications is to manage complex client state on the client side. The justification for an SPA over simple, dynamically server generated HTML/CSS pages is that client-side state is necessary for improved user experience that server-generated HTML/CSS pages cannot deliver for one reason or another.
Using channels/message passing is for when you have a DOM event which interacts with the server and you want multiple parts of your app to do something with the response.
In essence rather than “eliminating client side state” you are merely relocating client side state back to the server. Typically that approach is a lot more sensitive to the 8 fallacies of distributed systems (the first three are the most important):
- Full server side HTML/CSS pages always have to completely reload but that is usually mitigated by designing each page in such a way that each page is as effective as possible.
- Server HTML/CSS pages with jQuery/Ajax style DOM twiddling try to optimize a bit as they typically don’t require as many page loads by asynchronuosly loading additional data, introducing some client-side state which in turn causes client-side renders beside page loads.
- SPA drives this idea to the extreme by committing to a massive (or staggered) page load in the beginning, in order to later minimize server interactions to an “only as needed basis” driving client side renders primarily from changes in client side state.
- Progressive web applications (not to be confused with web pages designed with Progressive Enhancement) also enable the the page to cache itself with associated data and client side state in the browser itself to be able to offer some reduced functionality while the server cannot be reached.
So the technology trend is actually toward more and more client side autonomy in the absence of the server once the primary load is complete. This trend is partially driven by acknowleging the first 3 of the 8 fallacies of distributed systems:
- The network is reliable.
- Latency is zero.
- Bandwidth is infinite.
As a consequence:
- Network communication should not be chatty.
- You should transfer more data to minimize the number of network round trips. You should transfer less data to minimize bandwidth usage. You need to balance these two forces and find the right amount of data to send over the wire.
Your proposal of realizing (potentially fragmented) client-side (react-style) component state as server side processes:
- Is incredibly chatty over the network as each little component has to interact with it’s server side state to collaborate with another component that also renders itself on the client side.
- Requires a large number of round trips
- Potentially requires “abundant, available bandwidth”
In comparison to “React” a much more likely implementation is a “lifted up” application state (or redux-style store) on the server. Any part of the client is capable of dispatching an “action” towards the server so that the server evolves the current application state (most likely stored in a single process), which leads to a new render on the server, generating a render diff to be dispatched to the client.
There seems to be little benefit to fragmenting application state according to (visual) component boundaries over long lived server processes. React’s functional components would likely find equivalents in simple render functions that are fed the relevant fragment of application state. During renders independent parts of the view could split among short lived processes to be stitched together when completed.
However there likely is very little reason to keep more than one long lived process (to maintain application state in memory) between state update/render cycles per client.
Now in the context for internal apps over a corporate/institutional backbone network the LiveView trade-offs can be an effective solution for reducing development costs, possibly even for the couch-based consumer in well serviced, high availability urban areas but there has been a general trend of web consumption shifting to mobile devices and that is what is driving browser-based client technologies.
