A few of the unique things I try to emphasize when talking about Lit because it's so different from a framework:
Lit is just helpers to make web components. It's implementation detail. On the outside the components are just standard HTML elements.
Because of that, Lit makes no assumption that other elements you're using in your components are made with Lit. This low coupling preserves interop, and makes it easy to incrementally adopt Lit, and incrementally leave it if you wish. Low lock-in is an important principle for us.
Because of the low coupling, Lit doesn't have any centralized scheduling, diffing, etc. Each component is its own independent render root and schedules its own updates in microtasks. This has some great upsides - it's very easy to modify scheduling per component, and decouple costly subsections of a page to limit jank.
And we get great performance from the emergent global properties of independent roots. We check for data changes in the property setters for each component, so data updates only cause component updates along the paths in the tree that both use that data and see a change. Then lit-html, the template system, doesn't use VDOM, but remembers where data is bound to the DOM and only updates that if the data changed. It's very efficient.
Also, Lit requires no compiler to toolchain. You can use it from a CDN, or with import maps, or with a tool that resolves JS modules import specifiers. You can use decorators with TypeScript, or not. You can bundle or not. We do have TypeScript and ESLint plugins for working with templates.
Lit is awesome, thanks for maintaining it. I do more Svelte these days but have used Lit in the past and was very pleased with it.
Looking forward to using Lit in the future since I think it does a really great job of getting out of your way and being supremely easy to use and standards-adjacent.
> Because of the low coupling, Lit doesn't have any centralized scheduling, diffing, etc. Each component is its own independent render root and schedules its own updates in microtasks. This has some great upsides - it's very easy to modify scheduling per component, and decouple costly subsections of a page to limit jank.
Could you share some downsides?
> Also, Lit requires no compiler to toolchain. You can use it from a CDN, or with import maps, or with a tool that resolves JS modules import specifiers. You can use decorators with TypeScript, or not. You can bundle or not. We do have TypeScript and ESLint plugins for working with templates.
This is awesome -- thanks for
As for an actual new question, I'd love to know if there are any considerations on shared data in Lit -- with the just-web-components nature of Lit, data & reactivity are hard to fit in obviously but would be very beneficial to solve in a way that is just as easy to use as the rest of lit.
I took a stab at what it could look like and wrote a demo[0] and post[1], but have not kept up with the Lit community since then to see if there's some other solution/pattern gaining steam.
This is a pretty reasonable approach -- I guess relying on the platform to supply the same import for the same identifier (URL/file path/etc in the browser) is enough for state, but I really wanted something a bit more declarative somehow...
Feels like almost all of the world is now wonderfully DOM-friendly/not hidden from HTML but maybe it just doesn't make sense to try to make state declarative in terms of the display layer anyway.
It sometimes makes working with _slotted_ children in a non-lock-in way difficult in terms of state synchronization as opposed to props.children in React. The solution here in an app would be to use a state manager, but it's much more difficult for components that do not want to require the user to use a state manager e.g. design systems.
Additionally, hydration and customElements.define() upgrade order is a different consideration compared to other mono-state frameworks when it comes to SSR.
In terms of state management:
There are plenty of tools out there like lit-mobx shopped by Adobe. The team has also made some examples that show how easy it is to integrate your own state manager into Lit using ReactiveController such as Redux. There is also work being done such as example implementations of Preact Signals integration:
Lit is great, one thing I learned from Web development in the last couple of decades is the less layers to debug between browser native support and UI application code, the better.
You have reactive properties to model the internal state of a component but what's the recommended way to manage global state? Example: I click a button in a row of a table and I make something happen outside the table, so several components upward the components tree of the page and then a few others downward in a different branch of the tree.
I'm sure there is a better way to do it but (10 seconds of thinking time) maybe a top component with just an empty div and a reactive property with the global state and the code to apply changes to the reactive properties of the appropriate children components, no matter how far down the tree? That seems something to standardize and not code from scratch every time.
There is a lit context package in lit-labs, which, like React context, can be used for passing the state across multiple layers of components; but I think that, just like with React context, it will not be sufficient if you have a lot of global state. In such a case, some state management library will probably be needed. I don't think Lit has any opinion on what such a library should be. I know some people like to leverage the web platform to its fullest, and just use a class that extends EventTarget for state management (see e.g. https://github.com/thepassle/app-tools/blob/master/state/ind...)
I'm just thinking aloud here based on your description (and note that I'm a backend/data engineer looking to build data apps with no front end experience), would this integrate well with htmx then since each component is independent?
I really like the htmx approach and have been looking for a good visualization component framework that will play nice with it.
Yes it would. Htmx works via attributes on html elements, Lit is just a layer over Web components, and Web components quite literally `extends HTMLElement` :)
Lit looks really cool it would be great to see some more examples and starter kits. Perhaps an example of how to build web components for use with other projects that are not Javascript based as well. Bundle up components into individual deployable files for example
Awesome work, thanks for maintaining it! What's the recommended strategy to do unit testing? I tried a couple of months ago to use jest but it gets messy really quick due to poor support for shadow DOM. Thank you!
It utilizes lit-html's compiled template support to transform HTML templates into lit-html templates and reuse the underlying efficient rendering / updating machinery.
A few of the unique things I try to emphasize when talking about Lit because it's so different from a framework:
Lit is just helpers to make web components. It's implementation detail. On the outside the components are just standard HTML elements.
Because of that, Lit makes no assumption that other elements you're using in your components are made with Lit. This low coupling preserves interop, and makes it easy to incrementally adopt Lit, and incrementally leave it if you wish. Low lock-in is an important principle for us.
Because of the low coupling, Lit doesn't have any centralized scheduling, diffing, etc. Each component is its own independent render root and schedules its own updates in microtasks. This has some great upsides - it's very easy to modify scheduling per component, and decouple costly subsections of a page to limit jank.
And we get great performance from the emergent global properties of independent roots. We check for data changes in the property setters for each component, so data updates only cause component updates along the paths in the tree that both use that data and see a change. Then lit-html, the template system, doesn't use VDOM, but remembers where data is bound to the DOM and only updates that if the data changed. It's very efficient.
Also, Lit requires no compiler to toolchain. You can use it from a CDN, or with import maps, or with a tool that resolves JS modules import specifiers. You can use decorators with TypeScript, or not. You can bundle or not. We do have TypeScript and ESLint plugins for working with templates.