jfagnani

6 ms·

1.
by jfagnani 1y ago
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.
2.
by jfagnani 1y ago
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 bui
3.
by jfagnani 1y ago
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.
4.
by jfagnani 1y ago
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. Sh
5.
by jfagnani 1y ago
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 r
6.
by jfagnani 1y ago
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 deta
7.
by jfagnani 1y ago
Yes!
8.
by jfagnani 1y ago
Import assertions were replaced with import attributes (`assert` replaced by `with`). See https://caniuse.com/mdn-javascript_statements_import_import_...
9.
by jfagnani 1y ago
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. Y
10.
by jfagnani 1y ago
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
11.
by jfagnani 1y ago
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 deplo
12.
by jfagnani 1y ago
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
13.
by jfagnani 1y ago
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 :)
14.
by jfagnani 1y ago
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
15.
by jfagnani 1y ago
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 p
16.
by jfagnani 1y ago
Plates style isn't what developers expect from modern templating syntaxes. Every popular syntax today supports inline expressions.
17.
by jfagnani 1y ago
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
18.
by jfagnani 1y ago
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-
19.
by jfagnani 1y ago
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 spor
20.
by jfagnani 1y ago
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
21.
by jfagnani 1y ago
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
22.
by jfagnani 1y ago
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 single-file component projects,
23.
by jfagnani 1y ago
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. Context: Components tha
24.
by jfagnani 1y ago
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 (page reload);
25.
by jfagnani 1y ago
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, and neither
26.
by jfagnani 1y ago
Interesting server framework! It looks very similar in some ways to a server I started last year out of frustration with Koa and Express called Zipadee: https://github.com/justinfagnani/zipadee?tab=readme-ov-file#... T
27.
by jfagnani 1y ago
This API is definitely secure by default, and that's one of the constraints and requirements I mention in the post. The API is secure because it separates static developer controlled strings from dynamic and possibly user-controlled va
28.
by jfagnani 1y ago
Author here. I could include Svelte, but honestly it's still like the others: markup with embedded binding expressions and control flow. It would only bolster my claim that popular template syntaxes are similar.
29.
by jfagnani 1y ago
Author here. Property and event disambiguation syntax is definitely far on the easy to change side of things. I personally think the sigils are easier to read and write than perfixes, and these particular sigils have popped up independently
30.
by jfagnani 1y ago
Author here: Those don't look like HTML enough because they're not markup. Every single one of the top frameworks uses markup with interpolations as their basic template format: React, Vue, Angular, Preact, Lit, Svelte, Solid, Qui

More ›