4 ms·
> No API is non-opinionated. It's the difference between AppCache and Service Worker. AppCache is very easy to write, very easy to read, has a nice and simple
by rictic 9y ago
> No API is non-opinionated.
It's the difference between AppCache and Service Worker.
AppCache is very easy to write, very easy to read, has a nice and simple API. It's just the wrong API, so it's functionally almost useless.
Service Worker's API is more complex because it has hooks for the user to efficiently express exactly what they need. It's less easy to write, and less easy to read, but it's flexible enough that basically every site on the web could make good use out of having a Service Worker.
Most people won't write against the Service Worker API directly, they'll use a library.
You might say that this is a flaw of the API, that it's too complex or verbose for most users to use directly, but I think there's another angle to it. There can be many libraries and those libraries can iterate quickly. There can be only so many specs, and those specs necessarily iterate slowly.
- dmitriid 9y agoWhat I don't understand is why people insist that WebComponents API is ServiceWorkers in this analogy, and not AppCache :)
- dmitriid 9y agoAlso, this article captures the essence for AppCache vs ServiceWorkers comparisons: https://medium.com/@firt/service-workers-replacing-appcache-a-sledgehammer-to-crack-a-nut-5db6f473cc9b https://medium.com/@firt/service-workers-replacing-appcache-... Namely: 'I don’t think we need a “Service Worker’s jQuery”. We need to use Vanilla AppCache code.' Same goes for a ton of other things on the web platform. Replace "Service Worker" with "Web Components", and the sentence will still remain true.
- rictic 9y agoI don't understand what you're trying to say. I'll rephrase my position in longer form, because I think we're talking past each other. High level APIs necessarily make a lot of assumptions of how the low level details should work. When successful, users can get 80% of the benefit of the ideal low level implementation for 20% of the effort. For complex apps that 80/20 tradeoff isn't worth it, they would rather spend the extra effort to get maximum utility out of the API, even if it means mucking about with low level code. (As a non-web example, consider filesystem APIs. Most apps use just a few filesystem APIs, they just want to read strings, write strings, and list files in directories. A few apps though, like databases, can get huge benefit over having finer grained control, and need lower-level filesystem APIs.) App Cache is an example of trying to build the high level 80/20 solution first. It looked reasonable, but it failed in the details. You can't build a good low level API out of a high level one, but you can build high level APIs out of low level ones. Service Worker and Web Components take the opposite track. They are lower level APIs, sufficient to make complex apps possible. Library code can come in and build on top to provide high level 80/20 solutions. Then, after looking at the libraries that people build and use, we can pave the cowpaths and standardize good high level APIs.