3 ms·

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

by ergo14 9y ago

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.

dmitriid 9y ago
> 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) [1]: https://www.youtube.com/watch?v=y-8Lmg5Gobw https://www.youtube.com/watch?v=y-8Lmg5Gobw Around 12:50 mark: "What jumped out at us was how much infrastructure each library was bringing around to support creating widgets or components". Let's look at WCs: ooops, all the infrastructure is still there, nothing is done to make it easier.
- spankalee 9y ago
  > And w3c's opinions invariably are to the detriment of developer experience. Wow. Sorry, but I don't think you really know what you're talking about here. The Web Component specs are part of the HTML and DOM specs. Things like property initialization would fall under JavaScript and are already being addressed with JavaScript class fields with initializers. Spec authors don't go out of their way to make life hard on developers :/
- 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 ago
    What I don't understand is why people insist that WebComponents API is ServiceWorkers in this analogy, and not AppCache :)
  - dmitriid 9y ago
    Also, 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 ago
      I 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.

by ergo14 9y ago

dmitriid 9y ago

> 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) [1]: https://www.youtube.com/watch?v=y-8Lmg5Gobw https://www.youtube.com/watch?v=y-8Lmg5Gobw Around 12:50 mark: "What jumped out at us was how much infrastructure each library was bringing around to support creating widgets or components". Let's look at WCs: ooops, all the infrastructure is still there, nothing is done to make it easier.

spankalee 9y ago
> And w3c's opinions invariably are to the detriment of developer experience. Wow. Sorry, but I don't think you really know what you're talking about here. The Web Component specs are part of the HTML and DOM specs. Things like property initialization would fall under JavaScript and are already being addressed with JavaScript class fields with initializers. Spec authors don't go out of their way to make life hard on developers :/
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 ago
  What I don't understand is why people insist that WebComponents API is ServiceWorkers in this analogy, and not AppCache :)
- dmitriid 9y ago
  Also, 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 ago
    I 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.