3 ms·
My reasoning for never pursuing push is that a lot of semantics become implicit in the business requirements of the application itself. How does the server know
by dwaite 2y ago
My reasoning for never pursuing push is that a lot of semantics become implicit in the business requirements of the application itself. How does the server know it should push or not push data based on the client state, e.g. should it be pushing resources which could potentially already be in cache.
That leads you to one of two paths:
1. The web content needed should be communicated to the server by the client; either requests are made with Fetch with additional parameters, or via a service worker which can then populate the cache itself. However, once you are supplying logic in the page to handle these resources, there are other approaches you can make - such as having a service worker populate the cache by downloading a single archive and unpacking it.
2. The other option would be for content which is specifically never meant to be cached, such as live updates of a sporting event. There is no API however to support this, and we already do have things like WebSocket to do this.