jfagnani · HackerTrans

10 miesięcy temudiscuss

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.

jfagnani

10 miesięcy temudiscuss

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.

jfagnani

10 miesięcy temudiscuss

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.

jfagnani

10 miesięcy temudiscuss

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

jfagnani

10 miesięcy temudiscuss

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.

jfagnani

10 miesięcy temudiscuss

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 needs more detail.

There are details here: https://github.com/lit/lit/blob/main/dev-docs/design/how-lit...

jfagnani

10 miesięcy temudiscuss

Yes!

jfagnani

10 miesięcy temudiscuss

Import assertions were replaced with import attributes (`assert` replaced by `with`).

See https://caniuse.com/mdn-javascript_statements_import_import_...

jfagnani

10 miesięcy temudiscuss

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 constructor. You can't get at them at all from the class declaration.

I know more than one way to do something is sometimes a downside, but we have a large audience an a huge portion of it wants to use TypeScript and declarators, and another huge portion of it wants to use vanilla JavaScript. We factored things to give the best DX we could to each group with relatively little cost to us.

As for why metaprogramming, we want a component to update when it's state is changed. Like plain web components, Lit uses classes.

So here, we want setting `el.name` to cause the component to re-render:

    class MyElement extends LitElement {

      name = 'World';

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

We do that by replacing `name` with a getter/setter pair where the setter schedules an update of the instance. Without decorators, there's no way to see that `name` even exists, much less replace it.

Decorators actually do the replacement for us, we just have to build the thing to replace it with:

    class MyElement extends LitElement {

      @property() accessor name = 'World';

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

jfagnani

10 miesięcy temudiscuss

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 of the DOM APIs, but add to them instead.

There is a proposal in TC39 for native signals, which I think would make a huge dent towards library-less reactivity.

I'm also working on a proposal for native reactive templating which would more-or-less obsolete lit-html. I wrote about the idea some on my blog:

- The time is right for a DOM templating API https://justinfagnani.com/2025/06/26/the-time-is-right-for-a...

- What should a native DOM templating API look like? https://justinfagnani.com/2025/06/30/what-should-a-dom-templ...

jfagnani

10 miesięcy temudiscuss

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 deployment almost reasonable in some cases. You'd still miss out on minification and better compression form a bundle. Shared compression dictionaries will make this better though.

jfagnani

10 miesięcy temudiscuss

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 standards still missing that would open things up even more in the design system and standalone components side:

- Scoped custom element registries. This moves away from a single global namespace of tag names. Seems like it's about to ship in Safari. Chrome next.

- Open styleable shadow roots. Would allow page styles to flow into shadow roots. This would make building components for use with existing stylesheets easier.

- CSS Modules. Import CSS into JS. Shipping in Chrome. About to land in Firefox.

- ARIA reference target: make idref-based reference work across shadow roots

jfagnani

10 miesięcy temudiscuss

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 :)

jfagnani

10 miesięcy temudiscuss

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.

jfagnani

10 miesięcy temudiscuss

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.

jfagnani

10 miesięcy temudiscuss

Plates style isn't what developers expect from modern templating syntaxes. Every popular syntax today supports inline expressions.

jfagnani

10 miesięcy temudiscuss

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 semantics than whatever custom thing you might do, causing a webcompat issue when the native feature rolls out.

Although with JSON, it's pretty unlikely that there would be any differing semantics. JSON modules in JS are just JSON blocks with no special additions and no named exports. That's what inline versions would be as well.

jfagnani

10 miesięcy temudiscuss

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

What should a native DOM templating API look like?: https://justinfagnani.com/2025/06/30/what-should-a-dom-templ...

jfagnani

10 miesięcy temudiscuss

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

jfagnani

10 miesięcy temudiscuss

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 the correct prototype immediately (which includes custom elements). Otherwise the adopt steps are run when the elements are first attached to the document, which adds another tree walk to the insert/append operation that costs some time.

So:

    document.importNode(elem.content, true);

Then you'll have a DocumentFragment you can pull nodes out of. Or just append the whole fragment.