3 ms·

Are they going to kill Cache API [0] as well? because if not, one can still (kinda) "server-push" stuff through that. [0] https://developer.mozilla.org/en-US/d

Are they going to kill Cache API [0] as well? because if not, one can still (kinda) "server-push" stuff through that. [0] https://developer.mozilla.org/en-US/docs/Web/API/Cache https://developer.mozilla.org/en-US/docs/Web/API/Cache

judah 4y ago
Certainly not. Cache API is a useful API that can enable faster web apps by skipping network calls altogether. It also enables offline-capable web apps. I regularly use this API to speed up my web apps -- both personal and professional. I recently wrote about using Cache API to make a web app work entirely offline: [0]. Also, I think you may be mistaken about being "(kinda) server-push" - Cache API is entirely client-driven: the server can't push items into that cache; the client (usually a service worker) must choose to do so. I don't know what you mean when you say it's like server push. [0]: https://debuggerdotbreak.judahgabriel.com/2022/07/01/offline-pwas-my-adventure-beyond-the-basics/ https://debuggerdotbreak.judahgabriel.com/2022/07/01/offline...
- nousermane 4y ago
  Cache API being "useful" and "entirely client-driven" - both great points, but how is does it contradict my statement about same API being usable for server-push (i.e. force-feeding some objects to client it didn't ask for), may I ask? Remember, "client" (assuming user didn't disable javascript) is a dumb machine that executes whatever (code downloaded from) server tells it to, within some (pretty generous) limits. Imagine index HTML containing this: <script> const cache = await caches.open('push'); cache.put('/resource.json', new Response('{"foo": "bar"}')); cache.put('/resource.gif', new Response(atob('R0lGODlh...')); </script> That, of course, assumes that rest of code would use cache.match() instead of fetch API or XHR. Or, more realistically, a wrapper that tries both.
  - judah 4y ago
    I don't deny that Cache API was usable from HTTP/2 push. I'm responding to your question asking whether Chrome will obsolete the Cache API because it was usable from HTTP/2 server push. My answer is no, of course not, because Cache API is unrelated to HTTP/2 push. It's useful for storing resources regardless of whether they're HTTP/2 push'd from the server or fetched from the client. Indeed, the primary use of Cache API is storing resources fetched from a client's service worker.

judah 4y ago

Certainly not. Cache API is a useful API that can enable faster web apps by skipping network calls altogether. It also enables offline-capable web apps. I regularly use this API to speed up my web apps -- both personal and professional. I recently wrote about using Cache API to make a web app work entirely offline: [0]. Also, I think you may be mistaken about being "(kinda) server-push" - Cache API is entirely client-driven: the server can't push items into that cache; the client (usually a service worker) must choose to do so. I don't know what you mean when you say it's like server push. [0]: https://debuggerdotbreak.judahgabriel.com/2022/07/01/offline-pwas-my-adventure-beyond-the-basics/ https://debuggerdotbreak.judahgabriel.com/2022/07/01/offline...

nousermane 4y ago
Cache API being "useful" and "entirely client-driven" - both great points, but how is does it contradict my statement about same API being usable for server-push (i.e. force-feeding some objects to client it didn't ask for), may I ask? Remember, "client" (assuming user didn't disable javascript) is a dumb machine that executes whatever (code downloaded from) server tells it to, within some (pretty generous) limits. Imagine index HTML containing this: <script> const cache = await caches.open('push'); cache.put('/resource.json', new Response('{"foo": "bar"}')); cache.put('/resource.gif', new Response(atob('R0lGODlh...')); </script> That, of course, assumes that rest of code would use cache.match() instead of fetch API or XHR. Or, more realistically, a wrapper that tries both.
- judah 4y ago
  I don't deny that Cache API was usable from HTTP/2 push. I'm responding to your question asking whether Chrome will obsolete the Cache API because it was usable from HTTP/2 server push. My answer is no, of course not, because Cache API is unrelated to HTTP/2 push. It's useful for storing resources regardless of whether they're HTTP/2 push'd from the server or fetched from the client. Indeed, the primary use of Cache API is storing resources fetched from a client's service worker.