Lit: a library for building fast, lightweight web components

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

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

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.

> 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.

Re-implementing Lit from fundamentals is a great way to learn how it works! The core functionality is surprisingly simple, because it mostly relies on platform APIs to do the heavy lifting, like parsing templates.

I made this alternative implementation of lit-html to use as a research bed a long time ago when I was actively contributing to lit: https://github.com/ruphin/lite-html

Judging from this thread, many people have their own implementations, which is great to hear. I think there's a lot of value in solutions that are so simple that anyone can reproduce them.

Hi! Not really a question, but just an appreciation message. I haven't used the full "Lit" package a lot, but "lit-html" is incredibly useful.

I use it in almost all my personal websites. And when I don't use it, I end up reinventing half of it and realize I should have used it from the start. This command is in most of my projects:

  curl -L https://cdn.jsdelivr.net/npm/lit-html@3/lit-html.js -o ${project}/lit-html.js

Another thing I like from Lit is that with the CDN bundle, it's straightforward to experiment and use all the features without needing a build step.

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.

[1]: https://github.com/WICG/webcomponents/issues/909

Nice to see you here and THANK YOU for the amazing tool that is Lit. It's everything you want from a framework without a framework getting in your way.

I'm sold and build all my work and personal apps with it and have for many years. I wrote this article about why in 2022:

Getting Started with Web Components & Lit

https://medium.com/gitconnected/getting-started-with-web-com...

Here just to say thank you for Lit! It is a real pleasure to use (for simple and complex use-case).

Sometimes, I am wondering why it is not more widely used ...

Any whispers of something like lit being made part of the webcomponents standard?

Web components are nice because they're browser-native, but they don't support reactivity, which in hindisight, is a massive oversight, issue, whatever you want to call it - it's hindered adoption.

Lit is nice because there's a very straightforward progression from web components.

Curious which web platform features are missing that are preventing Web components to complete with React(for application development not widgets)?

I am not the one who submitted it. But someone mentioned it last night:

https://news.ycombinator.com/item?id=45107388

I assume someone else looked it up and liked it enough to submit it.

Are properties reactive?

Can I reassign name in the example by using document.querySelector?

The great thing about web components is that you can build them however works best for you.

Native web component APIs don't have the DX that many people expect though, because they are so low-level. Lit provides just that declarative reactivity on top.

Personally I find that lit abstracts quite well some pieces of functionality that you're going to implement yourself anyway to not have to write manual <template> all over your code plus the plumbing to add it to the DOM.

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.

Same here.

I have actually wrote a few web components by hand in an environment where I didn't want any external dependencies and when that requirement was dropped I really liked how easy was to convert them to LitElement (and how much nicer it is to work with them).

I also have embraced the shadow DOM which is a default, but I think it's more trouble than it's worth. Now I use LitElement without shadow DOM and it works great as well.

Which old browser capabilities are you referring to? Could you say more, or link to more details?

That’s also why I really like Aurelia framework. Its component model feels very intuitive, and it embraces standards like custom elements and decorators instead of inventing new patterns. Compared to Angular’s boilerplate or React’s hook gymnastics, Aurelia lets you write less code that looks more like plain JS/HTML. Too bad Aurelia never got the same traction as the big frontend names, because the DX is really solid.

"React is designed for the old browser capabilities and is now staying around by inertia, not by inherent quality." this makes me feel old and I guess React is famous for supporting Internet Explorer /s

Also Reddit! Any other surprise sites?

I have used both. Personally I prefer Vue a bit more.

* Built-in state management especially as in v3 (ref/reactive) is super powerful, and you can test the setup function logic by itself without any dependency on DOM which is convenient. By comparison, reactivity in Lit is basic (by design), and mostly work on the widget level -- if something changes, you need to trigger the update process of the widget.

* The lifecycle is also a bit simpler. In Lit, you often need to work with lifecycle callbacks like firstUpdated, connected, shouldUpdate, updated, disconnected etc. (You don't need to implement these for simpler widgets, but often you have to.) You can easily run into bugs if you are not careful, especially in the less common situation where your widget can be both temporarily and permanently removed from the DOM, in which case you need to make sure the state of the widget is properly perserved, which isn't a thing you need to worry about in Vue. We got bitten by this multiple times.

Unless there is a strong technical reason, I suggest that you focus on shipping features instead of changing your tech stack. Rebuilding your widgets is a very time consuming task with, well, near 0 impact on the user.

I don't know if there is a particular benefit, it's just different. On the consumer side there is no difference, because they consume Web Components, and that is what both solutions deliver. On the implementation side, I can think of a few differences:

Vue is more of a "framework" solution and has more things built-in. You can do the same things with Lit, but the implementation would look different, because you'd lean more on native APIs. A good example of that is the event model, Vue has some event model built in, but with Lit you would use EventTarget.dispatchEvent().

Lit is a runtime solution, it doesn't require a build and you can load your source directly in the browser. Vue on the other hand requires some form of compiler stage to produce something your browser can use. Compilers these days are fast, and Lit is specifically engineered to not have runtime performance overhead, so in practice this difference is rather minor. It is a very fundamental difference, so I think it's worth pointing out.

Vue can compile to other targets. If you are only delivering Web Components, this is mostly irrelevant, but in theory a consumer might be able to use the Vue components directly in their Vue project, which might give them a better DX. On the other hand, Lit is specifically designed to produce Web Components, so you'll probably have a bit less friction compares to using Vue, e.g when some Vue concept doesn't compile cleanly to Web Components.

Is there a major benefit to choosing one implementation over the other? I don't think so, unless you have a very particular requirement that one of them addresses that the other doesn't. For nearly all cases, it is just a different implementation syntax.

In most cases the only relevant metric in deciding between them is what technology your developers are more familiar/comfortable with.

>Working with a large Vue 3 project and wanting to share some of our components as re-usable web components for other sites to embed...

Make a fat bundle with a web component or even a mount() function exported and run whatever fits your devx inside, with the API surface as narrow as possible. As long as it's self contained and the size is reasonable, nobody on a consumer side cares how you cook, so optimize your own pipelines to build, test and publish it.

People will build adapters to fit it into their stuff anyway and will let you know.