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.

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

I've never felt I'm using a framework or anything that deviates from Vanilla JS and valid HTML, which is why using it hardly causes any more cognitive load than using regular string templates and JavaScript functions. Which is something that I can't say about other frontend tools.

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.

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

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

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.

Are properties reactive?

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

Thanks for your great work.

I can't find clear information about how re-rendering and stateful third-party components interact.

Let's say I have a stateful data table web component that I use in the template. Is it going to be re-created every time the template is re-rendered (loosing its internal state)?

Is there a way to efficiently use Lit without using a bundler?

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.

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.

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.

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

"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

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.

DaisyUI and HyperUI, which are both full component libraries based on tailwind, play well with lit. You either opt out of using the shadow dom or import the global styles into the component. Both methods have official lit support.

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.

Decorators are the only way to metaprogram over class fields in JS. Otherwise they're not even detectable on the prototype.

We use them to make fields reactive mostly, and I love how declarative they are. But we use them sparingly. I personally don't love how some libraries try to put a lot of things into decorators that could have been standard class features, like a static field or a method.

edit: As mentioned by skrebbel, decorators are optional. Every decorator has a simple plain-JS way of doing it. Event reactive properties: https://lit.dev/docs/components/properties/#declaring-proper...

We also put a lot of effort into making all of our documentation and playground samples on lit.dev available in both JavaScript and TypeScript with decorators. There's a switch that will change everything on the site from JS to TS globally.

    class MyElement extends LitElement {

      name = 'World';

      render() {
        return html`<h1>Hello ${this.name}</h1>`
      }
    }

    class MyElement extends LitElement {

      @property() accessor name = 'World';

      render() {
        return html`<h1>Hello ${this.name}</h1>`
      }
    }

Just to add to a sibling comment, they are optional and not in a “optional but if you dont use them it really sucks” kind of way.

The Lit authors tried hard to use vanilla JS everywhere they could, and it shows.

Not seeing decorators in the JS version:

    export class SimpleGreeting extends LitElement {
    ...
    }
    customElements.define('simple-greeting', SimpleGreeting);

Why exactly?

They are optional for what it’s worth. They are also landing in standard JS soon.

Also Reddit! Any other surprise sites?

You have a very large axe to grind against web components and Lit, and you show up just about everywhere to make the same comments, but I'll play along anyway:

Yes, Lit templates give some special meaning to attribute names with a few prefixes. No, it's not "HTML-like". It's valid HTML. Not that it matters much. You bring this up all the time but I'm not sure what the actual criticism is. Developers seem to understand the small syntax carve-out just fine.

No, there are no custom JavaScript rules. Templates have some rules. I'm not sure why they wouldn't? In general you can't make things like tag and attribute names dynamic because you can't change them in HTML. You can actually write the template you show with what we call static templates though.

`classMap()` is a template directive. It has some rules about how it's used in templates, just like other JS functions can have rules about how their used. I'm not sure what makes that not a function.

But to your main point: Lit is not like React because it's not a framework. Lit helps you make custom elements - it's an implementation detail of some web components. Everything else about those elements: how you instantiate them, style them, where they work, etc., is all defined by the HTML and DOM standards. React is a framework, and defines its own rules about how its components work.

I’m not one of those people but I don’t see an inherent conflict in what you’re saying. My #1 criticism of React is its size and monoculture, so a React-lite alternative sounds intriguing to me. Much like Preact, which I’ve used a ton.

I guess for most people the standard is to install things from NPM which explains the format of the documentation. If you want to do something completely raw, you can replace 'lit' with something like this:

https://unpkg.com/lit@3.3.1/index.js?module

You can even dynamically import that in the a running browser console and use it directly on any webpage.

    I guess for most people the standard is to install things from NPM

    replace 'lit' with something like this:
    https://unpkg.com/lit@3.3.1/index.js?module

The browser supports module imports. But your script must be of type ”module”: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...