Lit: a library for building fast, lightweight web components

I had lit in a project at work and not having to deal with it anymore is just great. We already have another heavier component framework to do the actual application stuff anyway, so having two just because somebody wanted to optimize their resume was such a drag.

It all looked nice in theory, but one thing shadow DOM makes worse is A11y, because element ids are now scoped and all the missing describe-by, label-for for things that should link to other side of the fence are a massive pain in the ass.

Big part of it is just skill issue on our part of course.

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.

Integrating these web components into our React codebase has been pretty awful--more of a web components thing than a Lit thing, IMO. We have "scoped styles", except for certain important things like font sizes, so tons of little regressions everywhere when we swap in the web component in place of the old React one. DX-wise, we lost a lot, too. I assume the tooling will get better, or that we'll figure it out more, but it's mostly been a drag

Are you migrating from react to something else? I see the appeal of web components as a middle ground for base library when different frameworks coexist (temporarily or not), but everyone is so hellbent on monoculture this days that I don't see the point really.

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.

> so having two just because somebody wanted to optimize their resume was such a drag.

Does this actually happen a lot? Allowing for the fact that people would rarely admit to it just being about resume padding, I feel like just wanting to _use_ the thing is a far more common motivation for poorly rationalised technology choices.

I've been working on a legacy server-rendered app that has a bunch of ajax calls, and stock web components and their shadow DOM has been super helpful to keep the mess at bay. Most of the work is actually making the app more accessible, actually.

The trick is that the components really do need to be self contained, and you need to use slots and custom attributes to bridge the gaps. Styling is the most annoying part for me, but I just include the same global imports that the main page has.