5 ms·

I have no idea what Web Components are or why I should care. Is that the problem?

superkuh 3y ago
One part of web components is custom HTML elements which basically means HTML elements that mean nothing until javascript execution gives them meaning. You differentiate them from the normal HTML element naming by using hyphens in the names. When I go to a website and all I see if a bunch of blank gray boxes that means they're using web components. It encourages developers to not put the text or images in the HTML and instead to load them externally after the page is loaded with javascript. That's slow, brittle, and stupid for most web documents. It's the opposite of progressive enhancement that fails gracefully. Web components just leave blank nothing that ruins accessibility for screen readers.
- verisimilidude 3y ago
  When you see this, it’s a sign that someone built their web components with React/Angular/Vue on the brain. The tech is fine. You can achieve amazing progressive enhancement with web components by understanding and effectively using <template> and <slot>. However, many web component developers never learn this. The problem you’re describing is a training/marketing issue, as discussed in the post.
  - arcbyte 3y ago
    The browsers really need to make it possible to use templates and slots without javascript at all. There's no reason I shouldn't be able to define and use a custom element using HTML alone. Until then I don't know if template and slot will take off.
    - no_wizard 3y ago
      This is what everyone in userland clamors for as a baseline. Decade plus old arguments about this. I have little hope this will happen
    - verisimilidude 3y ago
      Fully agreed.
    - lenkite 3y ago
      We had HTML imports and they got rid of it. No JS means No Ads.
      - no_wizard 3y ago
        It means less invasive tracking really, not no ads. Ironically it was Firefox that killed it, not Google. Google was all in on HTML imports. It would have also given a non JS way to dynamically load HTML. Streaming would have been great with this.
        adjav 3y ago
        HTML imports required JS to be used - otherwise all you had was a `link`ed DOM tree that you couldn't access. No one has really proposed a way to dynamically load anything without JS AFAIK.
- dmazzoni 3y ago
  FWIW, all the major screen readers fully support JavaScript. There's nothing inherently inaccessible about a website that uses JavaScript. In fact, the screen readers don't actually interpret the JavaScript at all - they just react to the page dynamically changing, it doesn't matter how it's accomplished.
  - superkuh 3y ago
    There's nothing inherent no, just that javascript webpages, if some CDN doesn't load fast enough, or the dev uses some bleeding edge function not in all browsers, etc, will not end up having the text in the page. Whereas actually having the text in the page always has the text in the page. JS sites almost always fail very badly when it fails (a relatively common event). Text sites cannot fail even when they fail.
cogman10 3y ago
Nope, not a problem. Because webcomponets fix a problem that nobody is having in a way that basically only benefits angular. They are strong encapsulation around a user defined component. So if you wanted to, for example, lock down the styling on your widget, you can! (hurray?) My cynical thoughts of why google pushes this is because it's another route to get in front of adblock. Make an ad component and now it's a lot harder for an addon to change or remove that component (and easier for the website to detect when that happens).
- err4nt 3y ago
  Even though I've never used Angular, and do not build web apps at all, we have put custom HTML elements to great use at work. It's also not about locking down styling, but it's a neat way to package up _functionality_ and behaviour that otherwise would be just defined ad-hoc in JavaScript, and to provide a dead simple way to (re)use that functionality in a declarative way from HTML.
  - pariahHN 3y ago
    Similar experience, it makes it easy to integrate components into partner pages because they can treat it just like any other HTML element and we don't have to worry about the vast majority of possible namespace conflicts thanks to the shadow DOM.
  - cogman10 3y ago
    Right, and that is a separate tech from web components. React, for example, does not use web components yet does exactly what you are describing. The problem web components is solving is just the strong encapsulation. Closing the escape hatches as it were.
    - err4nt 3y ago
      HTML is supported natively in the browser, and custom HTML elements and their properties work at the same level as all other HTML elements as far as JavaScript, DOM, and dev tools are concerned. React, while it may provide similar functionality to the programmer, is not natively understood, and while it can run in browsers, the 'components' in React are not handled in the same way in the browser as native HTML elements, JavaScript and its APIs don't know about them as HTML elements, DOM isn't aware of them (only their parts), and dev tools can't offer much insight because the app that's running is an unpredictable black-box to the browser.
err4nt 3y ago
Author-defined custom HTML elements, with all of the behaviour and interactivity defined in a way the browser natively understands.
_jal 3y ago
If you default to js off, you'll spot them quickly. I generally just head to the next site on my list/search results.

One part of web components is custom HTML elements which basically means HTML elements that mean nothing until javascript execution gives them meaning. You differentiate them from the normal HTML element naming by using hyphens in the names. When I go to a website and all I see if a bunch of blank gray boxes that means they're using web components. It encourages developers to not put the text or images in the HTML and instead to load them externally after the page is loaded with javascript. That's slow, brittle, and stupid for most web documents. It's the opposite of progressive enhancement that fails gracefully. Web components just leave blank nothing that ruins accessibility for screen readers.

verisimilidude 3y ago
When you see this, it’s a sign that someone built their web components with React/Angular/Vue on the brain. The tech is fine. You can achieve amazing progressive enhancement with web components by understanding and effectively using <template> and <slot>. However, many web component developers never learn this. The problem you’re describing is a training/marketing issue, as discussed in the post.
- arcbyte 3y ago
  The browsers really need to make it possible to use templates and slots without javascript at all. There's no reason I shouldn't be able to define and use a custom element using HTML alone. Until then I don't know if template and slot will take off.
  - no_wizard 3y ago
    This is what everyone in userland clamors for as a baseline. Decade plus old arguments about this. I have little hope this will happen
  - verisimilidude 3y ago
    Fully agreed.
  - lenkite 3y ago
    We had HTML imports and they got rid of it. No JS means No Ads.
    - no_wizard 3y ago
      It means less invasive tracking really, not no ads. Ironically it was Firefox that killed it, not Google. Google was all in on HTML imports. It would have also given a non JS way to dynamically load HTML. Streaming would have been great with this.
      - adjav 3y ago
        HTML imports required JS to be used - otherwise all you had was a `link`ed DOM tree that you couldn't access. No one has really proposed a way to dynamically load anything without JS AFAIK.
dmazzoni 3y ago
FWIW, all the major screen readers fully support JavaScript. There's nothing inherently inaccessible about a website that uses JavaScript. In fact, the screen readers don't actually interpret the JavaScript at all - they just react to the page dynamically changing, it doesn't matter how it's accomplished.
- superkuh 3y ago
  There's nothing inherent no, just that javascript webpages, if some CDN doesn't load fast enough, or the dev uses some bleeding edge function not in all browsers, etc, will not end up having the text in the page. Whereas actually having the text in the page always has the text in the page. JS sites almost always fail very badly when it fails (a relatively common event). Text sites cannot fail even when they fail.

cogman10 3y ago

Nope, not a problem. Because webcomponets fix a problem that nobody is having in a way that basically only benefits angular. They are strong encapsulation around a user defined component. So if you wanted to, for example, lock down the styling on your widget, you can! (hurray?) My cynical thoughts of why google pushes this is because it's another route to get in front of adblock. Make an ad component and now it's a lot harder for an addon to change or remove that component (and easier for the website to detect when that happens).

err4nt 3y ago
Even though I've never used Angular, and do not build web apps at all, we have put custom HTML elements to great use at work. It's also not about locking down styling, but it's a neat way to package up _functionality_ and behaviour that otherwise would be just defined ad-hoc in JavaScript, and to provide a dead simple way to (re)use that functionality in a declarative way from HTML.
- pariahHN 3y ago
  Similar experience, it makes it easy to integrate components into partner pages because they can treat it just like any other HTML element and we don't have to worry about the vast majority of possible namespace conflicts thanks to the shadow DOM.
- cogman10 3y ago
  Right, and that is a separate tech from web components. React, for example, does not use web components yet does exactly what you are describing. The problem web components is solving is just the strong encapsulation. Closing the escape hatches as it were.
  - err4nt 3y ago
    HTML is supported natively in the browser, and custom HTML elements and their properties work at the same level as all other HTML elements as far as JavaScript, DOM, and dev tools are concerned. React, while it may provide similar functionality to the programmer, is not natively understood, and while it can run in browsers, the 'components' in React are not handled in the same way in the browser as native HTML elements, JavaScript and its APIs don't know about them as HTML elements, DOM isn't aware of them (only their parts), and dev tools can't offer much insight because the app that's running is an unpredictable black-box to the browser.

err4nt 3y ago

Author-defined custom HTML elements, with all of the behaviour and interactivity defined in a way the browser natively understands.

_jal 3y ago

If you default to js off, you'll spot them quickly. I generally just head to the next site on my list/search results.