Lit: a library for building fast, lightweight web components

Shadow DOM is optional in Lit - you can just disable it on a per-component basis.

causes a bunch of things to no longer work though - slots, style encapsulation, ...

It should not be the default. This is almost certainly Lit's biggest flaw.

I am currently working on a web components framework, and I scrapped everything halfway through after I realized that you very rarely want that much encapsulation. Now, you can turn it on if you really need it, and I even made a way where you can pass references to DOM elements and stylesheets and such into each component so you can pierce the shadow veil easily. I have one demo to show it off, but I'm really having trouble imagining when someone would actually want to use it. The only time I can imagine it being useful would be building component libraries inside of large organizations.

I'm not ready to show off my framework yet, but I'm very certain that this leads to a better DX.

If you need style encapsulation, use the Shadow DOM. Slots still work IIRC.

Good luck with your better framework, but if this is the biggest flaw… then there’s really not much to complain about.

Slots definitely don't work without shadow DOM and there's really no way to make them work. It's the biggest problem with turning shadow DOM off.

Thanks! That's hardly the biggest difference to Lit. I think Lit is a fantastic framework, and I'm not trying to replace it or anything. However, it's really unopinionated which is fantastic for flexibility, but it leads to every deployment looking and feeling very different.

Basically, I'm just curious what a full-stack web component framework with strong defaults could look like. This is primarily a learning exercise, and a way to experiment with integrating web components into modern framework concepts like streaming server components, resumability, automatic serialization, and type-safe RPCs. I don't know if it will ever be production-ready, but I've learned a lot and it's been a ton of fun.

>The only time I can imagine it being useful would be building component libraries inside of large organizations.

That was our use case and we are migrating away from custom elements to a more conservative approach.

Have you seen https://brisa.build/? Its not web-components first but it looks really well designed and may give you some inspo

And that's the biggest problem with Shadow DOM (and most web component specs): you can't chose the good parts. Style encapsulation is useful, slots are useful, Shadow DOM is just all around bad, having a crazy amount of edge cases and broken behaviours [1].

Can you use style encapsulation and slots without Shadow DOM? Why can't you? I only need the horse, not the horse, and the cart, and the driver, and all the cargo in the cart.

You can't because people pushing all this stuff forward never ever stopped to think whether this was a good idea, and never ever talked to anyone outside of their own group.

[1] I will keep quoting this report by Web Components Working Group to death:

--- start quote --

It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.

...

Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM. While there are ways to develop these UIs by orchestrating the relationships between elements of synthesizing the passing of content across a shadow boundary, these practices generally position accessible development out of reach for most developers, both at component creation and component consumption time.

...

Selection does not work across or within shadow roots. This makes fully-featured rich-text editors impossible to implement with web components. Some of the web's most popular editors have issues that are blocked on this functionality.

--- end quote ---

That was exactly my experience using it. Great at first, and then hitting real-world and being stuck with the lack of sharing styles (in my case).

Shadow DOM was an absolute pain in reality.