This territory is well explored -- services like firebase/parse are a testament to many usecases.
IMO, this isn't per-se a new paradigm in the likes of offline-first, which is advocating for local application cache/data synced with a remote store, this offering the benefit of offline apps, with the sync/realtime benefits of network connected apps.
If you look how regular websites work, I think it is.
In my last project, people were kinda baffled, why the changes they made, didn't propagate to the other users instantly.
5 years ago everyone knew you had to refresh a page to see changes. Today everyone seems to expect these changes to be pushed to them.
It also was a fight to get this whole stuff working with React and Redux. So I think, if you want to build a good realtime site, you have to think about this stuff before choosing libraries, if you want to get good results.
For example, GraphQL has subscriptions that can be delivered via Websockets.
I don't know, after working a year with Redux, it never grew onto me. Always felt clunky :\
the solution was still pretty simple, for my app: 1. middleware that sends all actions to a server 2. websocket client that dispatches actions when they receive them. this works, but doesn't actually reconcile or keep data on the server which isn't suitable for most applications.
anyway yeah, i was surprised there was no robust or standard library...
Google is also working on GRPC for the browser. Tomorrow it could be a completely different protocol, but it's all in the pursuit of making the app more realtime.