I used lit for a few small components on my blog, https://pdx.su, and have mostly ignored them since writing them two years ago. When I recently had to update them with a new feature, I was extremely pleased that the usual js experience of finding out that I was a million versions behind wasn't there.
Lit: a library for building fast, lightweight web components
121–130 of 180 posts
Re: Lit: a library for building fast, lightweight web components
#122I don't see the need for Lit anymore. Lately I have just been raw dogging web components without any libraries. Having a nice templating system like JSX on the server makes it a breeze. Part of using web components, for me, is that it is just javascript. There is no upgrades or deprecations to think about. Of course those things still exist on the server though, but it is easier to maintain it there.
I find that there is little practical difference between "html" tagged template literal and writing JSX. Not to mention there is a compilation step in JSX.
Re: Lit: a library for building fast, lightweight web components
#123Lit maintainer here. I should be going to bed, but I'll answer any questions if people have any! Not sure why Lit showed up on the front page tonight :)
Lots of comments in here are about shadow DOM, so let me give my take in one place:
Yes, Lit uses shadow DOM by default (for good reasons, I think!) and yes you can turn it off component-by-component, but that does bring some challenges.
Shadow DOM is most fundamentally just a private branch of the DOM tree for a component's internal DOM details.
Frameworks have this implicitly with DOM defined in a component's template vs passed as children. But that distinction isn't visible to other code, the browser, and CSS. This is both good and bad.
The biggest thing this separate tree gives us is the ability to tell what nodes are "children" - those are the light DOM children. Once you can separate children from internals, you can build slots. Slots are holes in the internals that children get rendered into.
Without something like shadow DOM you can't have slots. And without slots you don't have interoperable composition and you don't have viable container elements. You need some way to place children in an element that isn't confused with the element's own DOM.
So to me, before encapsulation and style scoping, interoperable composition is the most important feature, and that's really why Lit defaults to shadow DOM on. Without it we'd need some special `.children` property and Lit's component composition suddenly wouldn't be compatible with everyone else.
But the style encapsulation is often a major pain for developers, especially if they're trying to integrate web components into an existing system with whole-page stylesheets. It's a big blocker to a lot of design systems porting to web components.
That's one reason I proposed something called "Open Styleable Shadow Roots"[1] which would let styles from outer scopes cascade into a shadow root - a way to break open style encapsulation but keep slots. It's been hard convincing browser vendors that this is needed, but I'm holding out hope that it makes progress soon.
Re: Lit: a library for building fast, lightweight web components
#124Earlier quoted context omitted.
causes a bunch of things to no longer work though - slots, style encapsulation, ...
If you need style encapsulation, use the Shadow DOM. Slots still work IIRC.
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.
Re: Lit: a library for building fast, lightweight web components
#125Earlier quoted context omitted.
> No shadow DOM Funny you should say that when the current advise for web components is to avoid Shadow DOM (almost like the plague) > no web components As in? > no template strings Why would React need template strings? React is not the only framework that doesn't use template strings for anything (Vue, Solid, Svelte come immediately to mind). And it's hard to accuse those of being behind the times when Solid is lit…
> the current advise for web components is to avoid Shadow DOM (almost like the plague) Could you provide the source for this advice?
It's wrong - both that it's general "current advice", and the advice itself when it does pop up.
Yes, there are some people who say to build web components without shadow DOM, but I'm convinced they're only building leaf nodes so they don't need composition with slots. As soon as they try to build any kind of container element they hit big problems.
Re: Lit: a library for building fast, lightweight web components
#126Earlier quoted context omitted.
I think web components already compete extremely well for application development, and you see very complex apps built with Lit out there: Photoshop, Firefox, Chrome OS, Chrome DevTools. Apps are well served because they have more control about how components are used: they can import the same shared styles into every component, take are to not double-register elements, etc. But I think there are some important stand…
> - Open styleable shadow roots What people using web components want is to get rid of shadowDOM and not feel like they are deviating from the correct path. shadowDOM sucks, stop trying to convince the world that we are using it wrong. shadowDOM is the whole reason web components did not become mainstream (yet?).
What about shadow dom sucks?
How else do you achieve that level of encapsulation to enable portable components?
Re: Lit: a library for building fast, lightweight web components
#127Does Lit have a good component library? Like, a complete web template (eg. Bootstrap/Ant), datepicker, color picker, virtual scroll, data tables, typeahead, tab, etc. I shipped a project with Lit and I liked it, but I didn't like that I'd need to know the complete project scope up front that I could write everything from the ground up. I know I could use React component for some of the harder stuff but at that point…
In addition, to what is already posted, you also have:
- https://github.com/vaadin/web-components
- https://github.com/material-components/material-web (very, very sadly killed by google management)
Re: Lit: a library for building fast, lightweight web components
#128Earlier quoted context omitted.
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…
Good luck with your better framework, but if this is the biggest flaw… then there’s really not much to complain about.
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.
Re: Lit: a library for building fast, lightweight web components
#129I’ve been incredibly lucky to spend about 6 years of the last decade NOT having to suffer through React, and I owe it all to Lit.
Using other frameworks to set up web view’s just don’t feel the same by comparison. I just want nested web components, and I just want Lit to help me define them. Tagged template literals for constructing HTML feels so much better than suffering through JSX.
Re: Lit: a library for building fast, lightweight web components
#130I used lit for a few small components on my blog, https://pdx.su , and have mostly ignored them since writing them two years ago. When I recently had to update them with a new feature, I was extremely pleased that the usual js experience of finding out that I was a million versions behind wasn't there.
I'm confused, there's been a new major version every two years for the past decade. (Polymer 1 in 2015, Polymer 2 in 2017, Lit 1 in 2019, Lit 2 in 2021, Lit 3 in 2023.)