The point of Web Components was modularity and encapsulation
twitter.com
twitter.com
We lead with principles, and the principle was fear, and the result wasn't good.
There's a beauty in having a page, where all the stuff lives & is visible together. The web's strenghts keep being interpretted as weaknesses, as things that know-better programmers want to reform & remake, to give them the comfort of programming as they know it, that gives them the top-down predictable well-ordered machine feel that writing a main() function has. The possibility, of so much, scares the programming tradition.
I really hope something good comes from this. Alas it's still kind of a PITA that WebComponents don't have a transport layer that makes sense. We'd hoped to de-bundle and be able to use HTTP Push to speed module delivery. We'd hoped we'd have module registries, a "post 1.0" effort for es2015 modules, but that never happened- we got other things instead, import-maps, import.meta, others... but figuring out how to effectively deliver a modular new thing that multiple sites can use on the web is still also another layer of unsuccess, another dimensions of modularity that never really emerged.
Great post by Lea, good initiative, and hpoeful we can start re-weaving & connecting together the web, after Shadow DOM broke us into smaller pieces.
---
semi-related, there's some interesting discussion on how some spec-authors intended/expected WebComponents to be adopted versus how they have. i'm still not sure how this addresses a lot of the concerns here, but it's an interesting discussion. and i like a lot of how it suggests that the Shadow DOM is for decoration, but that it ought have a visible apparent part to itself too, not be so isolating. this comment & @domenics follow up are both semi-interesting... but i think are also very due for a longer treatment/write-up. https://github.com/WICG/webcomponents/issues/986#issuecommen...