Earlier quoted context omitted.
It is low level API to be non-opinionated. Or at least it makes sense for me to make it like that. Same as web assembly, service worksers and others - that is a step in right direction IMO. Same as for example Python providing WSGI - you don't often use WSGI directly, you use a framework on top of it like Pyramid, Django or Flask.
> It is low level API to be non-opinionated. No API is non-opinionated. It's the opinion of its authors. And w3c's opinions invariably are to the detriment of developer experience. For example, quote from [1]: "The things like property initializers for instances that were so nice in [a previous example] aren't here. And they've been stuck in committee for reasons that, frankly, just make me grumpy" (around 22:30 mark…
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.