5 ms·

It’s worth noting this was written by maybe the person with the most experience in the space i can think of—-the primary author of Lit / Polymer working at web

by jlukic 1y ago

It’s worth noting this was written by maybe the person with the most experience in the space i can think of—-the primary author of Lit / Polymer working at web components on Google and contributing on many core DOM specs that have become part of the web platform.

troupo 1y ago
> It’s worth noting this was written by by one of the people wrecklessly barging forward with half-baked specs that introduced significantly more problems than they solved, pushed a "solution" that requires 20+ new web specs to barely do all the things user-space is already doing while completely ignoring and gaslighting anyone who wasn't 100% on board with what they were doing. Safari argued that there should be a declarative ways for this 15 years ago
- JimDabell 1y ago
  Web components were such a big disappointment. 200% the complexity for 20% of the functionality. Everything coming out of that area seems to be hideously over-engineered while failing to solve the problems people wanted them to. My feeling is that they were focused on designing something that is aimed at building form controls, not the kinds of components web developers use in practice. They are designed to make browser vendors’ lives easier, not web developers. That’s often excused with “web components excel at ‘leaf‘ components” when what is actually meant is “web components are bad at everything else”. I would expect an actually good solution that fits in with the web’s architecture to come from the direction of HTMX, not web components. > Safari argued that there should be a declarative ways for this 15 years ago True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course).
  - troupo 1y ago
    > True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course). Safari doesn't have as many engineers (a shame) and definitely doesn't have as many people whose apparent job is just to sit on standards committees and generate specs (like Alex Russel, Justin Fangnani etc.). They did end up proposing declarative template instantiation in 2017: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal... but that mostly went nowhere
    - JimDabell 1y ago
      That looks interesting – certainly a lot simpler and closer to web developers’ needs than what ended up getting standardised. It really is a shame Apple don’t invest more in WebKit and the web standards process. Although they’ve been doing a lot better over the past few years.
  - _benton 1y ago
    Im not sure what you're referring to, they seem pretty straightforward to me. Create a class that extends HTMLElement, implement stuff in connectedCallback and attributeChangedCallback. Return a list of attributes in static observedAttributes. Or use some extended class if you want, there are plenty and they're easy to create your own.
    - troupo 1y ago
      You mean other than the 20+ web specs they added to platform (often to "fix" problems that they themselves introduced and/or that no one else has)? https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html (this list appeared after half a dozen or more specs had already been rammed through) Or that their mere existence infects nearly every spec in existence delaying and needlessly complicating actual useful specs like Scoped CSS?
      - _benton 1y ago
        I don't think it's surprising that a feature like web components would require new specs, isn't that how standard web features work?
        troupo 1y ago
        Usually a new feature: - doesn't require 20+ web specs - doesn't forget and then scramble to fix the most basic expected functionality like form participation - doesn't pollute the space so badly that actual useful specs like Scoped CSS are delayed for years because now they have to deal with all the web coponent shenanigans - hopefully doesn't take 15 years to barely do what others have been doing since time immemorial
    - JimDabell 1y ago
      Let’s take this example: <!DOCTYPE html> <title>Example</title> <cool-dog> <template shadowrootmode="open"> <style> :host { display: block; font-family: system-ui; margin: auto; width: fit-content; } ::slotted(img) { border-radius: 1em; } </style> <slot></slot> </template> <img src="https://placedog.net/512/342?random" width="512" height="342" alt="A dog" > <p>Check out this cool dog!</p> </cool-dog> <script> customElements.define( "cool-dog", class extends HTMLElement {}, ); </script> First off, what’s with the pointless JavaScript? There’s no need for imperative code here. All web components have a dash in the name; this can be inferred. But even if you want it to be explicit, this could be done with markup not imperative code. But no, it doesn’t work without the pointless JavaScript ritual. Now, I’ve noticed that since the text is a caption for the image, I should actually use <figure> and <figcaption>. So let’s do that: <!DOCTYPE html> <title>Example</title> <cool-dog> <template shadowrootmode="open"> <style> :host { display: block; font-family: system-ui; margin: auto; width: fit-content; } ::slotted(img) { border-radius: 1em; } </style> <slot></slot> </template> <figure> <img src="https://placedog.net/512/342?random" width="512" height="342" alt="A dog" > <figcaption>Check out this cool dog!</figcaption> </figure> </cool-dog> <script> customElements.define( "cool-dog", class extends HTMLElement {}, ); </script> Wait a sec! The nice round corners on the image have turned into ugly square ones. Why is that? It’s because web components can’t style anything other than their direct children. You can style the <img> when it’s a direct child of the web component, but as soon as you need anything more complex than an entirely flat hierarchy, you run into problems. Even if it’s something as simple as wrapping an <img> in a <figure> to associate it with a <figcaption>. What’s the “official” way of getting things like this done when you bring it up with the people working on the specs? Make a custom property to fake the real one and then set a global style that listens to the fake property to set it on the real one: <!DOCTYPE html> <title>Example</title> <style> img { border-radius: var(--border-radius); } </style> <cool-dog> <template shadowrootmode="open"> <style> :host { display: block; font-family: system-ui; margin: auto; width: fit-content; --border-radius: 1em; } </style> <slot></slot> </template> <figure> <img src="https://placedog.net/512/342?random" width="512" height="342" alt="A dog" > <figcaption>Check out this cool dog!</figcaption> </figure> </cool-dog> <script> customElements.define( "cool-dog", class extends HTMLElement {}, ); </script> Now let’s say I want to put a second <cool-dog> element on the page. What does that look like? You define the template once and then just use <cool-dog> a bunch of times? That would be the obvious thing to do, right? Since it’s a template? Nope. Every instance of the web component needs its own <template>. The best you can do is write some JavaScript to copy the template into each one. The developer ergonomics of this stuff is terrible. It’s full of weird limitations and footguns.
  - lenkite 1y ago
    It should have been possible to declare and use simple web-components - which use a template and a CSS class - without any Javascript.
    - _benton 1y ago
      You can with DSD.
      - JimDabell 1y ago
        You can’t. At minimum you need to call customElements.define().
        throwitaway1123 1y ago
        You absolutely can. It's the primary purpose of the DSD (Declarative Shadow DOM), one of the many new specifications people complain incessantly about. <my-component> <template shadowrootmode="open"> <style> ::slotted(*) { font-weight: bold; font-family: sans-serif; } </style> <slot></slot> </template> <p>content</p> </my-component>
- gwd 1y ago
  > wrecklessly <pedantic> It's "recklessly". "reck" is a very old word meaning "to care, heed, have a mind, be concerned about"; so "reckless" means "without taking heed". I actually thought it was directly related to "reckon" (meaning "to think or calculate"), but when I looked it up it turned out not to be the case (except much further back in the etymological tree). </pedantic>
  - troupo 1y ago
    As I get older my brain and my fingers get more and more divorced from each other :) My brain knows it "reckless", my fingers type "wreckless". Same happens to a few other words, too.
- _benton 1y ago
  What were these 20 new specs?
  - troupo 1y ago
    After multiple specs had already been pushed through, they finally decided to write down a list of what is still needed. 22 items: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html In those things like ARIA are not a single spec. It's now close to five different proposals and a huge ARIA Object Model proposal. Similar thing with Form Associated Controls: it's not one spec. It's a bunch of specs fixing idiotic issues like this: https://github.com/WICG/webcomponents/issues/814 https://github.com/WICG/webcomponents/issues/814 Note: easily half of these only exist because of web components and for web components. Literally nothing else has these issues.
    - _benton 1y ago
      Right but what were these required specs for the existing implementation?
      - troupo 1y ago
        I couldn't parse your question

by jlukic 1y ago

troupo 1y ago

> It’s worth noting this was written by by one of the people wrecklessly barging forward with half-baked specs that introduced significantly more problems than they solved, pushed a "solution" that requires 20+ new web specs to barely do all the things user-space is already doing while completely ignoring and gaslighting anyone who wasn't 100% on board with what they were doing. Safari argued that there should be a declarative ways for this 15 years ago

JimDabell 1y ago
Web components were such a big disappointment. 200% the complexity for 20% of the functionality. Everything coming out of that area seems to be hideously over-engineered while failing to solve the problems people wanted them to. My feeling is that they were focused on designing something that is aimed at building form controls, not the kinds of components web developers use in practice. They are designed to make browser vendors’ lives easier, not web developers. That’s often excused with “web components excel at ‘leaf‘ components” when what is actually meant is “web components are bad at everything else”. I would expect an actually good solution that fits in with the web’s architecture to come from the direction of HTMX, not web components. > Safari argued that there should be a declarative ways for this 15 years ago True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course).
- troupo 1y ago
  > True, but they were equally able to propose and deploy alternative solutions and mostly just went along with web components (with exceptions of course). Safari doesn't have as many engineers (a shame) and definitely doesn't have as many people whose apparent job is just to sit on standards committees and generate specs (like Alex Russel, Justin Fangnani etc.). They did end up proposing declarative template instantiation in 2017: https://github.com/WICG/webcomponents/blob/gh-pages/proposals/Template-Instantiation.md https://github.com/WICG/webcomponents/blob/gh-pages/proposal... but that mostly went nowhere
  - JimDabell 1y ago
    That looks interesting – certainly a lot simpler and closer to web developers’ needs than what ended up getting standardised. It really is a shame Apple don’t invest more in WebKit and the web standards process. Although they’ve been doing a lot better over the past few years.
- _benton 1y ago
  Im not sure what you're referring to, they seem pretty straightforward to me. Create a class that extends HTMLElement, implement stuff in connectedCallback and attributeChangedCallback. Return a list of attributes in static observedAttributes. Or use some extended class if you want, there are plenty and they're easy to create your own.
  - troupo 1y ago
    You mean other than the 20+ web specs they added to platform (often to "fix" problems that they themselves introduced and/or that no one else has)? https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html (this list appeared after half a dozen or more specs had already been rammed through) Or that their mere existence infects nearly every spec in existence delaying and needlessly complicating actual useful specs like Scoped CSS?
    - _benton 1y ago
      I don't think it's surprising that a feature like web components would require new specs, isn't that how standard web features work?
      - troupo 1y ago
        Usually a new feature: - doesn't require 20+ web specs - doesn't forget and then scramble to fix the most basic expected functionality like form participation - doesn't pollute the space so badly that actual useful specs like Scoped CSS are delayed for years because now they have to deal with all the web coponent shenanigans - hopefully doesn't take 15 years to barely do what others have been doing since time immemorial
  - JimDabell 1y ago
    Let’s take this example: <!DOCTYPE html> <title>Example</title> <cool-dog> <template shadowrootmode="open"> <style> :host { display: block; font-family: system-ui; margin: auto; width: fit-content; } ::slotted(img) { border-radius: 1em; } </style> <slot></slot> </template> <img src="https://placedog.net/512/342?random" width="512" height="342" alt="A dog" > <p>Check out this cool dog!</p> </cool-dog> <script> customElements.define( "cool-dog", class extends HTMLElement {}, ); </script> First off, what’s with the pointless JavaScript? There’s no need for imperative code here. All web components have a dash in the name; this can be inferred. But even if you want it to be explicit, this could be done with markup not imperative code. But no, it doesn’t work without the pointless JavaScript ritual. Now, I’ve noticed that since the text is a caption for the image, I should actually use <figure> and <figcaption>. So let’s do that: <!DOCTYPE html> <title>Example</title> <cool-dog> <template shadowrootmode="open"> <style> :host { display: block; font-family: system-ui; margin: auto; width: fit-content; } ::slotted(img) { border-radius: 1em; } </style> <slot></slot> </template> <figure> <img src="https://placedog.net/512/342?random" width="512" height="342" alt="A dog" > <figcaption>Check out this cool dog!</figcaption> </figure> </cool-dog> <script> customElements.define( "cool-dog", class extends HTMLElement {}, ); </script> Wait a sec! The nice round corners on the image have turned into ugly square ones. Why is that? It’s because web components can’t style anything other than their direct children. You can style the <img> when it’s a direct child of the web component, but as soon as you need anything more complex than an entirely flat hierarchy, you run into problems. Even if it’s something as simple as wrapping an <img> in a <figure> to associate it with a <figcaption>. What’s the “official” way of getting things like this done when you bring it up with the people working on the specs? Make a custom property to fake the real one and then set a global style that listens to the fake property to set it on the real one: <!DOCTYPE html> <title>Example</title> <style> img { border-radius: var(--border-radius); } </style> <cool-dog> <template shadowrootmode="open"> <style> :host { display: block; font-family: system-ui; margin: auto; width: fit-content; --border-radius: 1em; } </style> <slot></slot> </template> <figure> <img src="https://placedog.net/512/342?random" width="512" height="342" alt="A dog" > <figcaption>Check out this cool dog!</figcaption> </figure> </cool-dog> <script> customElements.define( "cool-dog", class extends HTMLElement {}, ); </script> Now let’s say I want to put a second <cool-dog> element on the page. What does that look like? You define the template once and then just use <cool-dog> a bunch of times? That would be the obvious thing to do, right? Since it’s a template? Nope. Every instance of the web component needs its own <template>. The best you can do is write some JavaScript to copy the template into each one. The developer ergonomics of this stuff is terrible. It’s full of weird limitations and footguns.
- lenkite 1y ago
  It should have been possible to declare and use simple web-components - which use a template and a CSS class - without any Javascript.
  - _benton 1y ago
    You can with DSD.
    - JimDabell 1y ago
      You can’t. At minimum you need to call customElements.define().
      - throwitaway1123 1y ago
        You absolutely can. It's the primary purpose of the DSD (Declarative Shadow DOM), one of the many new specifications people complain incessantly about. <my-component> <template shadowrootmode="open"> <style> ::slotted(*) { font-weight: bold; font-family: sans-serif; } </style> <slot></slot> </template> <p>content</p> </my-component>
gwd 1y ago
> wrecklessly <pedantic> It's "recklessly". "reck" is a very old word meaning "to care, heed, have a mind, be concerned about"; so "reckless" means "without taking heed". I actually thought it was directly related to "reckon" (meaning "to think or calculate"), but when I looked it up it turned out not to be the case (except much further back in the etymological tree). </pedantic>
- troupo 1y ago
  As I get older my brain and my fingers get more and more divorced from each other :) My brain knows it "reckless", my fingers type "wreckless". Same happens to a few other words, too.
_benton 1y ago
What were these 20 new specs?
- troupo 1y ago
  After multiple specs had already been pushed through, they finally decided to write down a list of what is still needed. 22 items: https://w3c.github.io/webcomponents-cg/2022.html https://w3c.github.io/webcomponents-cg/2022.html In those things like ARIA are not a single spec. It's now close to five different proposals and a huge ARIA Object Model proposal. Similar thing with Form Associated Controls: it's not one spec. It's a bunch of specs fixing idiotic issues like this: https://github.com/WICG/webcomponents/issues/814 https://github.com/WICG/webcomponents/issues/814 Note: easily half of these only exist because of web components and for web components. Literally nothing else has these issues.
  - _benton 1y ago
    Right but what were these required specs for the existing implementation?
    - troupo 1y ago
      I couldn't parse your question