Live data from Hacker News

If Web Components are so great, why am I not using them?

daverupert.com

121–130 of 189 posts

Re: If Web Components are so great, why am I not using them?

#121

Frankly, web components aren't great. I am using them, because I've landed in a few projects where adding a JS build step is too heavyweight for very minimal JS needs. But here are my gripes: 1. Templates are way too complicated to be useful. I have no idea what they were thinking here. 2. The shadow DOM not inheriting styles means I effectively can't use the shadow DOM for anything useful. My ideal use case would be…

it sounds like the thing you are looking for are slots and they are supported in shadow DOM with the HTMLSlotElement

No, because then the user of the custom element has to put slot attributes on the things they put in the tabs. Consider this:

    
      
        ...arbitrary HTML that should work intuitively, i.e. be styled
        like the rest of the document.
      

      
        Note the lack of slot attributes on these tab elements. That's
        because we want this to behave like normal HTML where you
        can nest without having to worry about how tab-area was implemented.
        Why should we have to care that tab-area was implemented with
        templates/slots?
      

      
        There could be any number of these tabs so you can't put them
        into slots without some sort of late-generating the slots anyway.
      
    
We want this to render like a group of tabs where "First" and its body are visible, and tabs are peeking up from behind with the texts "Second" and "Third" but the content of those tabs isn't shown until you click the tab (at which point the content of "First" is hidden).

That's not achievable with slots.

In general, I haven't found a case where templates/slots are actually useful--it's a lot of work to create a bad interface.

Re: If Web Components are so great, why am I not using them?

#122
post #115

I heard about web components a lot for years and was looking forward for an opportunity to try them. But for some reason, this is the first time I learn that it's completely reliant on JS. My impression previously was that it brings more power back to native HTML, and lets you extends HTML elements by defining your own modular custom components instead of doing so in JS the `modern` way. Instead, turns out it's doubl…

If I recall correctly, there was or is a web component concept or inplementation that does not originate frome those frameworks and I think I read about it on MDN or so. It is only that frontend devs push their frameworks so much, that most people associate web components with React and similar frameworks.

Re: If Web Components are so great, why am I not using them?

#123
Google teached me over the years that they can deprecate or remove support from one day to another, and I don't matter to them, neither as user, developer, or company owner.

So even if I love web components since it got released (and have used them in some toy apps) I can't count on them yet thanks to Google.

You can't trust anything coming from Google. There is no assurance that they announce tomorrow that they remove support for them in chrome. Or even worse, they will remove support in 6 month (killing all the developers market and destroying any production app). To announce in 3 years that they will continue the effort of removing them...

It's just sad.

Re: If Web Components are so great, why am I not using them?

#124

I wouldn't mind a sanity check on using Web Components in this context: We have a bunch of sites written in different frameworks (React, Rails + Hotwire, Phoenix + Liveview) that we'd like to have a shared set visual components between them. Think things like: - Buttons - Text spacing - Layout cards - Headers Pretty low level stuff, the most dynamic behaviour might be something like showing / hiding content in an FAQ…

Web components are really only useful for stuff that's dynamic, like a sortable table that fetches data from an AJAX request. They require javascript and have no fallback or graceful degradation in functionality at all, which means using web components for all your bog standard buttons, text content, headers, etc. could be a very bad idea (not to mention it would trash the SEO and potentially accessibility of your si…

Web components are treated like HTML elements. You can nest and combine them with semantic elements and attach attributes to them.

Say you have a component that does something with titles (h1 etc.), then you would wrap the semantic element with a web component.

You do the same with buttons, text or input fields etc.

This way you 100% retain the semantic structure (before loading JS). And it’s possible to progressively enhance the DOM if that is a goal.

Re: If Web Components are so great, why am I not using them?

#125

Earlier quoted context omitted.

The shadow DOM can inherit styles if you specify the styles that you want to inherit. Additionally, web components work just fine without the shadow DOM, it's optional, but for a great many custom elements you don't want them inheriting all the styles, because that can break the custom element.

Without the shadow dom, though, what really is the difference from just using ` ` elements? You can't use slots, you're vulnerable to bad `querySelector`s, events aren't isolated, and you get none of the performance benefits. I've tried to find a workable solution using style inheritance, but it doesn't work everywhere. On code sandbox sites like codepen.io, the stylesheet is generated for you and sometimes updated i…

> Without the shadow dom, though, what really is the difference from just using `` elements?

Having a lifecycle that you can hook into to know when to run code related to this particular instance of the custom element.

See e.g. a recent talk on web components — https://youtu.be/jBJ7eoPtmY8?t=367

Re: If Web Components are so great, why am I not using them?

#126
post #118

Earlier quoted context omitted.

> Now, every time we read `offsetHeight`, the browser sees that it has a scheduled DOM modification to apply, so it has to apply that first, before it can return a correct value. That makes perfect sense, except that I don't understand how using a shadow DOM helps in this specific case (A DOM write followed immediately by a DOM read). Won't the shadow DOM have to perform the same calculations if you modify it and the…

The shadow DOM doesn't help at all here, that's mainly about scope and isolation. The (in fairness confusingly named) virtual DOM helps by splitting up writes and reads. The goal when updating the DOM is to do all the reads in one batch, followed by all the writes in a second batch, so that they never interleave, and so that the browser can be as asynchronous as possible. A virtual DOM is just one way of batching tho…

I'm gonna apologise in advance for being unusually obtuse this morning. I'm not trying to be contentious :-)

> So to answer your question: the virtual DOM helps because it separates reads and writes from each other. Reads happen on the real DOM, writes happen on the virtual DOM, and it's only at the end of a given tick that the virtual DOM is reconciled with the real DOM, and the real DOM is updated.

I still don't understand why this can't be done (or isn't currently done) by the browser engine on the real DOM.

I'm sticking to the example given: write $FOO to DOM causing $BAR, which is calculated from $FOO, to change to $BAZ.

Using a VDOM, if you're performing all the reads first, then the read gives you $BAR (the value prior to the change).

Doing it on the real DOM, the read will return $BAZ. Obviously $BAR is different from $BAZ, due to the writing of $FOO to the DOM.

If this is acceptable, then why can't the browser engine cache all the writes to the DOM and only perform them at the end of the given tick, while performing all the reads synchronously? You'll get the same result as using the VDOM anyway, but without the overhead.

Re: If Web Components are so great, why am I not using them?

#128
post #36
post #34

Earlier quoted context omitted.

Nobody (meaning very few) care for Web Components, React or not. Even in frameworks that do support them, they're just not widely used.

Web Components are just an API, a means to an end. You might as easily say nobody cares for document.createElement() but it’s still used by underlying code all the time. If it were much easier to mix and match components that use different frameworks then people would be using web components whether they know it or not. But we’re in a React monoculture and React folks seem quite content with that.

They shouldn't be called web components in React (typical JS world term squatting). Instead they should be called React Components.

Re: If Web Components are so great, why am I not using them?

#129
Too little too late.

My bet is WASM being the Great Leap Forward because everything else that has been done in JavaScript is just layer on layer of abstraction, obfuscation and horrendous complexity.

I would rather develop in a mature language and have that transpiled to WASM rather than fight the frameworks (I still remember when Angula 5 was a 15,000 file desktop mom install !).

JavaScript has fulfilled an important role as the COBOL of the web. Low barrier to entry - anybody can do something useful without education or expense.

Now the web needs move forward to become the first choice desktop. That will take tools that can really do the whole stack, like C, Go, Java, Zig, Virgil productively.

Industry has been busy on the JS bandwagon and adding vast amounts of complexity to browsers and web infrastructure when maybe (happy for opinions to be voiced on this) we should be just adding more language runtimes to browsers.

Re: If Web Components are so great, why am I not using them?

#130
post #115

I heard about web components a lot for years and was looking forward for an opportunity to try them. But for some reason, this is the first time I learn that it's completely reliant on JS. My impression previously was that it brings more power back to native HTML, and lets you extends HTML elements by defining your own modular custom components instead of doing so in JS the `modern` way. Instead, turns out it's doubl…

> My impression previously was that it brings more power back to native HTML, and lets you extends HTML elements by defining your own modular custom components instead of doing so in JS the `modern` way.

Curious what you feel defining a custom component in the browser would look like, if not with JS?

Post reply on HN