Hacker News Reader

Comment by 8chanAnon | Hacker News Reader

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

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.

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.

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.

This is what everyone in userland clamors for as a baseline. Decade plus old arguments about this. I have little hope this will happen

Fully agreed.

We had HTML imports and they got rid of it. No JS means No Ads.

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.

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.

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.

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.

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).

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.

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.

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.

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.

If you default to js off, you'll spot them quickly.

I generally just head to the next site on my list/search results.

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

Reply on news.ycombinator.com