> I think it's a beautiful, elegant solution

Very confused by statements like these.

They are extremely verbose.

They are too high level, preventing many low-level optimizations.

They are too low-level, preventing you from using/implementing them without going into the details of how they actually work.

They break many platform assumptions and conventions, creating no end of problems both for end users and implementers, and needing dozens of new specifications to fix glaring holes that exist only because web components exist. All of those specs? A heavy dousing of Javascript of course.

Even the people who push them heavily cannot agree on what they are good is and what the goal of them is

▲

WickyNilliams 10 hours ago | parent | next [-]

What makes custom elements good is inrerop. I can use them in react, Vue, angular, svelte, solid, or just plain ol' server rendered html. I can switch out the internals entirely for a WC lib, or not, with nobody knowing or caring.

This is a unique advantage to WCs. And it's such a compelling advantage that it makes almost all the downsides tolerable. At least if you are in a position where your component might be used in many places. Design Systems are a good example. The consumer can be any app, built on any technology.

And there are plenty of downsides. But they are mostly felt by the author, not the consumer. Similar to how TS libs can be very complex to author because of type level gymnastics, but when done right are easy to consume.

(I do not push them heavily, but I can appreciate strengths and weaknesses of all tools)

▲

troupo 10 hours ago | parent | next [-]

> At least if you are in a position where your component might be used in many places.

I think someone once called them leaf components, and on this I agree.

▲

WickyNilliams 9 hours ago | parent [-]

They don't need to be leaf components to still have this strength. I've worked with design systems which have a <my-layout> component near the root which defines sidebar, header etc slots. This still works nicely with react, Vue etc

But I agree they tend to be better suited as "leafier" components

▲

troupo 9 hours ago | parent [-]

> I've worked with design systems which have a <my-layout> component near the root which defines sidebar, header etc slots.

Funnily enough this is exactly what original proposal of web components was against :)

	▲	WickyNilliams 9 hours ago \| parent [-]
		Honestly I couldn't care less what the original proposal said! Things evolve. Utility is found in unforeseen places. That's the nature of ~everything. Personally I'm not a fan of that kind of component but not aligning with some original, preordained vision is a minor nit

▲

singpolyma3 8 hours ago | parent | prev [-]

You know what else can be used in all these contexts? Defined HTML elements

▲

publicdebates 6 hours ago | parent | prev [-]

As far as I can tell, the whole web components umbrella came into being because React/Vue got really popular, and the spec/browser people said hey let's bring the core common denominator of those into native HTML/JS, as if it would bring us closer to having native Vue/React. Which of course never happened, partly because HTML is fundamentally incapable of having anything but string attribute values, and partly because reactive DOM is basically a hard problem that can't or maybe shouldn't be solved natively.

▲

troupo 4 hours ago | parent [-]

> As far as I can tell, the whole web components umbrella came into being because React/Vue got really popular, and the spec/browser people said hey let's bring the core common denominator

First web components proposal is from 2011. First specs are from 2011-2013.

React was introduced in 2013 and didn't gain much traction until at least a year later.

Vuejs was publicly announced in 2014.

▲

publicdebates 4 hours ago | parent [-]

Right, and that proposal was withdrawn, and a new one, the one we have now, was proposed based on lessons learned from (or inspired by?) React/Vue. Maybe there was a common ancestor or general consensus about the techniques floating around in the community before proposal #1, but it was clearly inferior and flawed, and #2 was the one I'm talking about.

	▲	troupo 3 hours ago \| parent [-]
		> That proposal was withdrawn "That proposal" was a talk by Alex Russel in 2011: https://web.archive.org/web/20121119184816/https://fronteers... Web Components are not a single proposal. Their core originally is three specs: - Custom Elements - Shadow DOM - HTML Templates Custom Elements v0 was implemented by Google, but the API changed (especially with ES6 classes making their way into all major browsers), and now everyone's on Custom Elements v1. There are very little fundamental changes between the two beyond that. Shadow DOM is there, is an endless source of bizarre problems that literally no one has, and in the end will need ~30 different specs and changes to the browser to fix those problems (for a sample see https://w3c.github.io/webcomponents-cg/2022.html) HTML Templates were only implemented in Firefox, and were removed in favor of JavaScript-only HTML Modules which were eventually scrapped in favor of on-off additions to JavaScript imports (see e.g. "CSS Module scripts" https://web.dev/articles/css-module-scripts) > was proposed based on lessons learned from (or inspired by?) React/Vue. Lol. The world wishes it were so. There rarely was such an insular group of people developing major web standards as those developing web components. They were hostile to any outside input or influence and listened to no voices, and looked at no implementations but their own.