It's not possible to make slots work without a separate tree like shadow DOM. The browser can't tell what the container for a slot is vs what content should project into it.
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…
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.
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…
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…
Thanks! Elements are kept stable as long as the template containing them is rendered. The template docs try to get this across by saying that Lit "re-render only the parts of template that have changed." Maybe that…
Yes!
Import assertions were replaced with import attributes (`assert` replaced by `with`). See https://caniuse.com/mdn-javascript_statements_import_import_...
There really is no way to metaprogram against class fields except with decorators. Class fields aren't on the prototype. They're essentially Object.defineProperty() calls that occur right after the super() call of a…
Lit has always been designed partially as a prototype for where web component standards could go in the future. That's a big reason Lit is fairly conservative and un-opinionated. It doesn't try to undo or paper-over any…
Lit's just a JavaScript library published as standard modules, so it doesn't require a bundler. Using Lit efficiently is the same as using any other library. HTTP/3, import maps, and HTML preloads can make unbundled app…
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…
Lit 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 :)
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…
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…
Plates style isn't what developers expect from modern templating syntaxes. Every popular syntax today supports inline expressions.
My understanding is that in implementations any unknown type creates a "data block", which is just unprocessed text.' I wouldn't use application/json just in case browsers start supporting that and it has different…
I wrote a couple of blog posts on why we should add native templating to the DOM so we'd need fewer libraries. The time is right for a DOM templating API: https://justinfagnani.com/2025/06/26/the-time-is-right-for-a...…
Author of lit-html here. Yeah, Lit's tagged template literals and render() method are basically a shorthand for making a <template> element, marking the spots where expressions go, cloning the template, then filling in…
You should use document.importNode() to clone templates. Template contents are in a separate document from the main document, which is what makes them inert. importNode() adopts the nodes into the document so they have…
No. I would use <script type="-json"> <script> parses its contents as text, whereas <template> parses as DOM. This means you don't have to escape `<`, just `</script>`. Myself and some browser engineers been working on…
There is a spec issue open for HTML Modules [1] along with a few proposals. The concept needs some motivated champions to see it through. Microsoft has shown some interested in this lately. There are userland…
I think events are a bit unsung and underutilized in a lot of web projects. Events are really powerful and you can build systems with them that can replace proprietary framework features with interoperable protocols.…
Very uncanny! I like it :) I even have a lot of those things planned, just not enough time! I didn't do anything that required client-side JS yet, but the first things on that list are out-of-order rendering; watch mode…
I've definitely explored how those frameworks work, and I've written several signals integrations for Lit. My claim, having done that, is that template re-rendering and fine-grained reactivity are entirely compatible,…
It's not possible to make slots work without a separate tree like shadow DOM. The browser can't tell what the container for a slot is vs what content should project into it.
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…
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.
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…
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…
Thanks! Elements are kept stable as long as the template containing them is rendered. The template docs try to get this across by saying that Lit "re-render only the parts of template that have changed." Maybe that…
Yes!
Import assertions were replaced with import attributes (`assert` replaced by `with`). See https://caniuse.com/mdn-javascript_statements_import_import_...
There really is no way to metaprogram against class fields except with decorators. Class fields aren't on the prototype. They're essentially Object.defineProperty() calls that occur right after the super() call of a…
Lit has always been designed partially as a prototype for where web component standards could go in the future. That's a big reason Lit is fairly conservative and un-opinionated. It doesn't try to undo or paper-over any…
Lit's just a JavaScript library published as standard modules, so it doesn't require a bundler. Using Lit efficiently is the same as using any other library. HTTP/3, import maps, and HTML preloads can make unbundled app…
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…
Lit 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 :)
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…
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…
Plates style isn't what developers expect from modern templating syntaxes. Every popular syntax today supports inline expressions.
My understanding is that in implementations any unknown type creates a "data block", which is just unprocessed text.' I wouldn't use application/json just in case browsers start supporting that and it has different…
I wrote a couple of blog posts on why we should add native templating to the DOM so we'd need fewer libraries. The time is right for a DOM templating API: https://justinfagnani.com/2025/06/26/the-time-is-right-for-a...…
Author of lit-html here. Yeah, Lit's tagged template literals and render() method are basically a shorthand for making a <template> element, marking the spots where expressions go, cloning the template, then filling in…
You should use document.importNode() to clone templates. Template contents are in a separate document from the main document, which is what makes them inert. importNode() adopts the nodes into the document so they have…
No. I would use <script type="-json"> <script> parses its contents as text, whereas <template> parses as DOM. This means you don't have to escape `<`, just `</script>`. Myself and some browser engineers been working on…
There is a spec issue open for HTML Modules [1] along with a few proposals. The concept needs some motivated champions to see it through. Microsoft has shown some interested in this lately. There are userland…
I think events are a bit unsung and underutilized in a lot of web projects. Events are really powerful and you can build systems with them that can replace proprietary framework features with interoperable protocols.…
Very uncanny! I like it :) I even have a lot of those things planned, just not enough time! I didn't do anything that required client-side JS yet, but the first things on that list are out-of-order rendering; watch mode…
I've definitely explored how those frameworks work, and I've written several signals integrations for Lit. My claim, having done that, is that template re-rendering and fine-grained reactivity are entirely compatible,…