[misterbwong]

Web components have their place but they're no panacea and the ecosystem is still pretty young. This is coming from someone that has been leading a decently large StencilJS web component project for over a year now.

Documentation and Google-ability of the subject isn't great so prepare to some digging and experimentation.

The current native feature set is somewhat lacking so you're definitely going to want to augment with some sort of helper framework/library. Building any significantly sized project purely native with vanillaJS would be challenging.

There are also some unique hurdles with this type of project that our org had to work through-mainly on the integration and design side of it.

[Keithamus]

I’ve been working on https://webcomponents.guide/ with some fellow experts in order to improve the documentation side of things. Hoping to offer guidelines and best practices to limit the amount of searching and experimentation required. Please take a look and provide feedback if you can!

[pjmlp]

No amount of documentation will help if React keeps acting as if Web Components don't exist.

Other than that, the website looks quite nice.

[Keithamus]

React 19 is likely to ship with Web Components support. https://github.com/facebook/react/issues/11347

[dmitriid]

That marketing copy ugh.

"New! Powerful!" It's neither

"Standard JS so it works where HTML works" says a lot about your experts

[Keithamus]

Thanks for the feedback! If you have the time, I'd love for you to contribute and improve the marketing copy: https://github.com/WebComponentsGuide/webcomponents.guide

[dmitriid]

> Web components have their place but they're no panacea and the ecosystem is still pretty young.

And yet wc proponents keep pushing them as if they were panacea.

And "ecosystems is young" is a funny statement for something that is entering its 12th year of development (and fifth year of wide availability in browsers).

> The current native feature set is somewhat lacking so you're definitely going to want to augment with some sort of helper framework/library.

If they are lacking, have glaring unsolved issues, https://twitter.com/Rich_Harris/status/1198332398561353728), and you still need to augment them with a framework/library,... what's the point then?

If any of the existing solutions had the same amount of issues that wcs have, they would never have gotten of the ground. And yet here we are 12 years and hundreds of millions of dollars of effort later

[azangru]

Examine html source of such sites as github, youtube, redhat, adobe — you will find web components either sprinkled there or being a principal building block. They are certainly a workable solution.

[dmitriid]

> Examine html source of such sites as

Just because someone uses a technology, doesn't mean it's good. I could point to plenty of sites still using first versions of Angular. Is it workable? Yes. Is it good?

Also, I'd skip youtube as an example. No idea what incentives they had internally to re-write everything in web components, but they (and the web) paid dearly for it:

- Youtube was re-written in v0 of Custom Components. Which was deprecated as soon as they re-wrote it. Chrome couldn't remove v0 from the browser until Youtube was re-written (undoubtedly at great expense) with v1 four years later

- The polyfill for v0 was famously extremely slow in Firefox. Given that Youtube is one of the most popular websites (if not the most popular), you can imagine what it did to Firefox's image.

If you have an extra billion of dollars for such shenanigans, sure, knock yourself out (especially if it helps to cripple your competition).

Also IIRC GitHub is using React as well now, but I can't find the relevant link and discussion right now.

[azangru]

> Just because someone uses a technology, doesn't mean it's good.

At least it shows that the technology is both scalable and battle-tested.

> I could point to plenty of sites still using first versions of Angular. Is it workable? Yes. Is it good?

It's legacy, as I think we will both agree. Just as jQuery is, and just as React will become sooner or later. Meanwhile, web components are the browser standard, which means that they are a model of UI code encapsulation that is here to stay.

> Also IIRC GitHub is using React as well now, but I can't find the relevant link and discussion right now.

On their promo sites, yes. And maybe in the project management tools as well. Developers of the main site are heavily into web components.

[dmitriid]

> At least it shows that the technology is both scalable and battle-tested.

So are all other technologies used on the web sites. It still doesn't make it good.

You keep pretending that if something is used somewhere means it's good.

> It's legacy, as I think we will both agree. Just as jQuery is, and just as React will become sooner or later.

So what? Neither of these technologies have the laundry list of issues that web components have. And jQuery is still used on significantly more sites than React and Web Components combined. I'd bet on survival of jQuery more than on survival of Web Components.

> Meanwhile, web components are the browser standard, which means that they are a model of UI code encapsulation that is here to stay.

Unfortunately, yes. They are here to stay: a badly designed, barely working technology that needs increasingly complex and arcane hacks to make up for its deficiencies, sucking up human resources and making browser engines incomprehensibly complex. Oh, and they also infect other standards that have to cater to them now. E.g. Scoped CSS covers 80-90% of use cases WCs are used for, but now it has to be butchered to accommodate Shadow DOM.

But yeah. It's here to stay.

As Rich Harris, the author of Svelte said, "it's almost as if congealing 2010-era best practices in the platform before we'd finished exploring this territory was a mistake" [1]

There's a reason why very few, if any, of the major frameworks, and very few of up-and-coming web frameworks use web components as the foundation. Well, not one reason, but multiple extensively documented, discussed and debated reasons. However, WC proponents couldn't care less about these reasons because "but look, it's in the browser now".

So. What.

marquee was in the browser. Custom elements v0 was in the browser. Many things were, or indeed still are, in the browser. Doesn't make them good technology. We're here 12 years after they were introduced and they still have the issues that a non-wc library by even a first year CS student wouldn't have on the first try:

- form participation, "solved" by throwing more JS at the problem

- a11y boundaries, will through more JS at the problem when AOM arrives perhaps 10 years from now

- incorporating SVGs, will never be solved. That is, doing <svg><y-axis></y-axis><x-axis></x-axis></svg> will never be possible. Not an issue for literally any non-wc framework.

- SSR is barely solved by DSD if at all

- etc. etc.

And 12 years later people are actually exploring ideas without components as those are pure overhead: https://dev.to/this-is-learning/components-are-pure-overhead...

[1] https://twitter.com/Rich_Harris/status/1513668040784814084