I had lit in a project at work and not having to deal with it anymore is just great. We already have another heavier component framework to do the actual application stuff anyway, so having two just because somebody wanted to optimize their resume was such a drag.
It all looked nice in theory, but one thing shadow DOM makes worse is A11y, because element ids are now scoped and all the missing describe-by, label-for for things that should link to other side of the fence are a massive pain in the ass.
Big part of it is just skill issue on our part of course.
Integrating these web components into our React codebase has been pretty awful--more of a web components thing than a Lit thing, IMO. We have "scoped styles", except for certain important things like font sizes, so tons of little regressions everywhere when we swap in the web component in place of the old React one.
DX-wise, we lost a lot, too. I assume the tooling will get better, or that we'll figure it out more, but it's mostly been a drag
Are you migrating from react to something else? I see the appeal of web components as a middle ground for base library when different frameworks coexist (temporarily or not), but everyone is so hellbent on monoculture this days that I don't see the point really.
It should not be the default. This is almost certainly Lit's biggest flaw.
I am currently working on a web components framework, and I scrapped everything halfway through after I realized that you very rarely want that much encapsulation. Now, you can turn it on if you really need it, and I even made a way where you can pass references to DOM elements and stylesheets and such into each component so you can pierce the shadow veil easily. I have one demo to show it off, but I'm really having trouble imagining when someone would actually want to use it. The only time I can imagine it being useful would be building component libraries inside of large organizations.
I'm not ready to show off my framework yet, but I'm very certain that this leads to a better DX.
Thanks! That's hardly the biggest difference to Lit. I think Lit is a fantastic framework, and I'm not trying to replace it or anything. However, it's really unopinionated which is fantastic for flexibility, but it leads to every deployment looking and feeling very different.
Basically, I'm just curious what a full-stack web component framework with strong defaults could look like. This is primarily a learning exercise, and a way to experiment with integrating web components into modern framework concepts like streaming server components, resumability, automatic serialization, and type-safe RPCs. I don't know if it will ever be production-ready, but I've learned a lot and it's been a ton of fun.
And that's the biggest problem with Shadow DOM (and most web component specs): you can't chose the good parts. Style encapsulation is useful, slots are useful, Shadow DOM is just all around bad, having a crazy amount of edge cases and broken behaviours [1].
Can you use style encapsulation and slots without Shadow DOM? Why can't you? I only need the horse, not the horse, and the cart, and the driver, and all the cargo in the cart.
You can't because people pushing all this stuff forward never ever stopped to think whether this was a good idea, and never ever talked to anyone outside of their own group.
[1] I will keep quoting this report by Web Components Working Group to death:
--- start quote --
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.
...
Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM. While there are ways to develop these UIs by orchestrating the relationships between elements of synthesizing the passing of content across a shadow boundary, these practices generally position accessible development out of reach for most developers, both at component creation and component consumption time.
...
Selection does not work across or within shadow roots. This makes fully-featured rich-text editors impossible to implement with web components. Some of the web's most popular editors have issues that are blocked on this functionality.
I've been working on a legacy server-rendered app that has a bunch of ajax calls, and stock web components and their shadow DOM has been super helpful to keep the mess at bay. Most of the work is actually making the app more accessible, actually.
The trick is that the components really do need to be self contained, and you need to use slots and custom attributes to bridge the gaps. Styling is the most annoying part for me, but I just include the same global imports that the main page has.
> so having two just because somebody wanted to optimize their resume was such a drag.
Does this actually happen a lot? Allowing for the fact that people would rarely admit to it just being about resume padding, I feel like just wanting to _use_ the thing is a far more common motivation for poorly rationalised technology choices.
I've used it extensively myself, for creating complex web apps with many (nested) components interacting with each other.
I don't understand why Lit hasn't gained more popularity, because for me it is basically React, but then more browser-native, much less boiler plate, and much faster rendering. There are some things you have to get used to, but when you do it doesn't limit you in any way.
Re-implementing Lit from fundamentals is a great way to learn how it works! The core functionality is surprisingly simple, because it mostly relies on platform APIs to do the heavy lifting, like parsing templates.
I made this alternative implementation of lit-html to use as a research bed a long time ago when I was actively contributing to lit: https://github.com/ruphin/lite-html
Judging from this thread, many people have their own implementations, which is great to hear. I think there's a lot of value in solutions that are so simple that anyone can reproduce them.
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:
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.
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.
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:
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.
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:
I hope there can be ways without JS to populate templates with data - autoloaded from sources. This would tremendously increase the number of JS free web-sites. Also wish the web-components standard did not mandate the use of JS. It should be possible to define simple web-components (HTML+CS) declaratively and have this officially supported in standard and implementation
I think we're stuck today in a little bit of a rut of extensibility. We wind up leaning on JavaScript to get things, because it is the Turning complete language in our environment. It is the only thing that can give us an answer when CSS and HTML fail us. So we wind up piling ourselves into the JavaScript boat. We keep piling into the JavaScript boat.
Bruce yesterday brought up the great example of an empty body tag, and sort of this pathological case of piling yourself into the JavaScript boat, where you wind up then having to go recreate all of the stuff that the browser was going to do more or less for you if you'd sent markup down the wire in order to get back to the same value that was going to be provided to you if you'd done it in markup. But you did it for a good reason. Gmail has an empty body tag, not because it's stupid. Gmail does that because that's how you can actually deliver the functionality of Gmail in a way that's both meaningful and reliable and maintainable. You wind up putting all of your bets, all of your eggs, into the JavaScript basket.
....
They're the sorts of things that you use when the semantic that you're trying to express is so far away from what HTML natively has a semantic for, that you're willing to go and be completely self served for it. Taking on for yourself accessibility, UI, UX, internationalization, localization, performance, theme ability; all of this stuff is mostly taken care of for you by HTML.
--- end quote ---
14 years later, web components depend on JS to:
- participate in forms
- solve accessibility issues (not yet, but coming through a yet another JS-only standard)
- CSS modules and other imports that are moved entirely into JS
etc. etc.
-----
Slight off topic. From the same talk:
--- start quote ---
Now, we can do some of that today. We can go and look at the top million pages and figure out which JavaScript library that they're using, which features are being most heavily used, we can put those things in DOM. But is that the right place for them? It's a hard thing to figure out.
--- end quote ---
I wish they spent time figuring that out. We wouldn't have to wait a few decades for https://open-ui.org to slowly make its way into the browsers.
The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…
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
What people using web components want is to get rid of shadowDOM and not feel like they are deviating from the correct path. shadowDOM sucks, stop trying to convince the world that we are using it wrong. shadowDOM is the whole reason web components did not become mainstream (yet?).
Nothing in Web Components is forcing you to use ShadowDOM. Lit also allows you to make components without ShadowDOM if you prefer, because there are certainly cases where it can be necessary to do so (like for ARIA reference id-matching). For full single application development, it can feel like it gets in the way a lot, and you can make a good argument to use components without ShadowDOM in those contexts too.
All frontend "frameworks" do have some sort of solution to scope CSS to individual components, and without a similar solution, a native component system would not be viable. The implementation has its quirks, but it is a core capability that is necessary for some use cases. For third-party widgets or cross-application components like design systems, the ability to isolate your component from the site it is embedded in is very useful.
Think of shadowDOM as the web component alternative to scoped styles in Vue components (as an example). You don't have to use it, but it would be incredibly inconvenient if it wasn't included in the framework.
> Nothing in Web Components is forcing you to use ShadowDOM
Yes. There is just one thing forcing someone to use shadowDOM: slots. You can't use slots without shadowDOM or at least use something like this.children to capture the content inside the <custom-element></custom-element>.
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.
I disagree completely. Shadow DOM is a huge help and when combined with per-component CSS using the :host() and nesting pattern, makes for very small CSS files and very short CSS class names. In other words, as far away from Tailwind as you can get.
It's also possible to import shared CSS in a base class and add it with super.styles() so you don't lose anything.
You don't want to enable portable components all the time. If most of the components you use to create your app is made by yourself, those boundaries are annoying, not helpful.
Please do not refer to CSS type imports in JS as CSS Modules.
CSS Modules has an established meaning for over a decade, one that is still relevant today. The CSS type imports are very different, and arguably worse.
Call them CSSStyleSheet imports of you need a name suggestion.
Another pain in the ass is the fact web components are registered globally. Good luck marrying this with npm dependency hell where two transitive dependencies both import a button.
The good part of react and friends is it's just javascript and the class is imported and referenced normally, not with a weak string-binding-through-registry kind of way.
Now add types to the mix and shadow dom and it brings constant problems without any upside.
What I wonder is whether there are any developments related to Lit regarding server-side rendering (SSR). This is one of the reasons I'm experimenting with Svelte now. To me Lit was taking away frustrations with the inefficiencies of React. But for me Svelte seems to fill that gap too, and it also has SSR, among other niceties. But I do like the philosophy of Lit & Web Components. Sometimes I think a framework that would be like Svelte but uses Lit under the hood would seem like the best of both worlds.
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)?
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.
So let me get this straight: HTML was originally built to have markup and style both in the same containers, and it was clunky and hard to maintain, so CSS was invented, to abstract away the styles so that content and style could be separate. And that worked pretty well. And then someone came along and said: you know what would be great? Removing all the useful abstractions and going back to the HTML 1.0 way of putting it all in one container. And rewriting HTML in JavaScript to make it less maintainable. And so on. Am I getting this right? Correct me if I'm wrong.
I used Lit components in a large FE project, enjoyed doing so and am happy with my choice. I don't use the shadow DOM at all.
The project is Converse.js, an XMPP chat client. It's an old project that was originally created back in 2013 with Backbone.js.
I first replaced all templates with `lit-html` when I first heard about that, and then when lit-element (and now "lit") came out, I started rewriting the project to use that.
This app has since been integrated into many different websites that rely on other frameworks like React and the fact that Converse.js is a web component (<converse-root />) makes this easier.
I don't see the need for Lit anymore. Lately I have just been raw dogging web components without any libraries. Having a nice templating system like JSX on the server makes it a breeze.
Part of using web components, for me, is that it is just javascript. There is no upgrades or deprecations to think about. Of course those things still exist on the server though, but it is easier to maintain it there.
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.
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.
I find that there is little practical difference between "html" tagged template literal and writing JSX. Not to mention there is a compilation step in JSX.
I mean sure, as long as it runs on the server. Personally I feel JSX is way more expressive. The JSX I write runs on server side rendering to HTML. That way there will be no flash of unstyled content, cumulative layout shift, or any other jank. It looks correct even before the javascript has been downloaded, except it isn't interactive yet.
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.
Same about the shadowDOM. The only criticism I have about Lit is that the creators think shadowDOM is amazing and people not liking it are using it wrong. Lit lacks a good direction and someone with vision leading it but it became the technical pet project of a few.
For the frontend work that I did, Lit was a godsend. It really helps you build components and apps without getting in the way.
In comparison, Angular is a monster, and React is designed for the old browser capabilities, and is now staying around by inertia, not by inherent quality.
Funny you should say that when the current advise for web components is to avoid Shadow DOM (almost like the plague)
> no web components
As in?
> no template strings
Why would React need template strings? React is not the only framework that doesn't use template strings for anything (Vue, Solid, Svelte come immediately to mind). And it's hard to accuse those of being behind the times when Solid is literally the reason for the upcoming native signals proposal
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.
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.
In a parallel discussion happening on Mastodon, someone says:
> People coming from React-land can have a hard time reasoning about the difference between a custom element and a template render function and when best to use each
> This abuse of the component system can indeed lead to a massive explosion in nodes on a page and the performance tanks because of that
I know I certainly have that hard time deciding when I need a custom element and when a render function.
> As soon as they try to build any kind of container element they hit big problems.
That's not true. Web components that render nothing will contain only their children as nodes, that's good enough for a good amount of container use cases.
Web Components Community Group: 2022. You are one of the authors:
--- start quote ---
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM.
...
Selection does not work across or within shadow roots. This makes fully-featured rich-text editors impossible to implement with web components. Some of the web's most popular editors have issues that are blocked on this functionality
...
Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM.
--- end quote ---
Those are just the tip of the iceberg as these are very explicitly stated in the doc.
Then there's the issues of shifting the responsibility to both developers and consumers to handle Shadow DOM correctly.
Styling/themeing is still pain despite several different specs like shadow parts.
Shadow DOM is a kind of retcon for the web. As I’ve written in the past, shadow DOM upends a lot of developer expectations and invalidates many tried-and-true techniques that worked fine in the pre-shadow DOM world.
Perhaps I care about the direction in which the web is pushed by a very small number of people incapable of seeing beyond their solutions and incapable of admitting their own mistakes.
At no point have I ever gotten the impression that you are even remotely open to seeing other points of view so it’s a bit hard to take the moralistic tone of the brave defender of the web part seriously. I think you just want to yell at people.
Web Components have been in development for 14 years. If you think this is the first discussion of web components, you clearly haven't been paying attention.
All there is to say was said years ago. Today it should be enough to know that, for example, "form associated custom elements cannot be a submit button" issue was opened 6 years ago, in 2019: https://github.com/WICG/webcomponents/issues/814
Imagine if any web framework had issues like that.
That doesn't even begin to cover things like "now every useful spec has to be acutely aware of Shadow DOM shenanigans" which delayed any number of specs like scoped CSS etc
It’s just like an LLM stuck on a loop. It’s just years and years of making the exact same comments, not responding to any counter arguments and then demanding that people take you seriously.
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.
I thankfully migrated or left all Aurelia projects, but every time someone mentions it, I remember new horror stories.
Its .html temples were shipped unmodified directly to the client (yes, including comments). Except they weren't actually html, and sometimes the browser would try to clean them up, breaking the template.
Reactivity was achieved through all kinds of weird mechanisms (eg monkey-patching arrays to watch for mutations). It would frequently resort to polling on every tick or break completely.
DI used TypeScripts experimental decorators, even long after it was clear that it would never become stable.
On the other hand, templates weren't type checked.
Never had issues with the HTML. Templates sometimes showed comments in dev mode, but in production builds they were stripped and everything minified. I never used Webpack or other bundlers, only the "dumber.js" from their CLI, so maybe was something related to that?
And yeah, probably they monkey-patched arrays and such, but that was just the way of the world before proxies and native signals. The cool part is Aurelia stuck to web standards, and those “weird mechanisms” were basically polyfills, so even old versions still run solid today, sometimes even faster by leveraging native features.
> The cool part is Aurelia stuck to web standards, and those “weird mechanisms” were basically polyfills
I could agree that Aurelia looks like you’re sticking to standards¹. If you don’t think about it, then everything kinda works 90% of the time.
But when you actually try to understand what goes on behind the scenes, like you can with React and Angular, there are just so many footguns, especially around composition and reactivity.
Even simple things like passing optional props² or detecting if a <slot> is occupied involved depressing amounts of reverse-engineering.
I’ve heard that Aurelia 2 supposedly fixes many of my issues, but I believe the core idea is beyond fixing. React, Solid and others have more powerful approaches that require fewer concepts to understand.
¹ Although there are still tons of custom concepts and syntax to learn.
I thankfully migrated or left all Aurelia projects, but every time someone mentions it, I remember new horror stories.
Its .html temples were shipped unmodified directly to the client. Except they weren't actually html, and sometimes the browser would try to clean them up, breaking the template.
Reactivity was achieved through all kinds of weird mechanisms (eg monkey-patching arrays to watch for mutations). It would frequently resort to polling on every tick or break completely.
DI used TypeScripts experimental decorators, even long after it was clear that it would never become stable.
On the other hand, templates weren't type checked.
"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
You think that in 14 years many critiques from many authors didn't appear on the front page? It's not a big deal to reach the front page of HN.
No worries, web components themselves have a very nice critique in the form of their own community report https://w3c.github.io/webcomponents-cg/2022.html listing all the issues that many people had been taking about for literal years before this report.
There have been many that have hit the front page over the years. If you're not aware of a technology's shortcomings then you're a bad proponent of said technology. They're also almost the antithesis of what the HTMX crowd also preaches as "the one true way" and meanwhile, Wordpressers will continue developing the majority of the world's websites blissfully unaware that either technology even exists.
Hands down the most underrated front end library out there. It powers some major projects like ChromeOS, Chrome Devtools, I think most of Firefox’s UI, Photoshop for the web, MDN etc.
I just came across this resource the other day and found it super helpful, thought I would share it here for anyone who’s interested in working with Lit.
I really like the standalone lit-html rendering library but never really saw a need for Lit. Honestly, I find it hard to see a need for more than <any client-side rendering lib> + Web Components when I want client-side rendering.
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.
Vue can be used as an ordinary JS library without special build setup. You can even load the library from a CDN as a global variable like the old jQuery days.
Vue _does_ have some sort of build step, because components use special macros that aren't imported, and the compiler (vite) even complains when you actually import them saying it's not necessary. The build also rewrites your code to some other format that I assume is more optimized because it can do some sort of static analysis.
Are these the main reasons for Vue to use a compiler if it's not necessary? Injecting dependencies and rewriting some code to allow better performance while retaining the nice syntax?
Tree shaking, that is removing code that is not used.
Bundling several files into one to save on requests.
Transpiling, that is, if you want to write code in a different language to javascript eg. Typescript then vite will compile that to javascript.
Linting ie. Reformatting your code to standardise it across developers.
Vulnerability checking, are your dependencies out of date?
Execution of build tasks eg. Preparing static assets like images.
Packaging your app for deployment eg. Zipping
Including logging and hot reload triggers during development.
Bundling environment specific changes eg. Different backend urls if deploying to test envs.
Running unit tests on rebuild to avoid regressions.
Having said all that, the bundling for me is a disadvantage as my own code changes more than 3rd party libs and they are cached. I'm less fussed with types and a lot of the tests and env stuff can be done with a single-file express server for development.
The main advantage for me is that a buildless app will still work correctly in 6 months- permacomputing considerations.
IRRC Vue will compile your templates on the fly if you don't pre-compile them, so you will be punished twice -- in performance and in bundle size for skipping the build step.
If you can eat the cost to get something in return, it's a nice trade off.
>Working with a large Vue 3 project and wanting to share some of our components as re-usable web components for other sites to embed...
Make a fat bundle with a web component or even a mount() function exported and run whatever fits your devx inside, with the API surface as narrow as possible. As long as it's self contained and the size is reasonable, nobody on a consumer side cares how you cook, so optimize your own pipelines to build, test and publish it.
People will build adapters to fit it into their stuff anyway and will let you know.
Lit is fantastic lib as a way out from legacy web framework (since can be injected in any framework including Vue, Angular, React). I used it as a way out out of old Vue2 project
I used lit for a few small components on my blog, https://pdx.su, and have mostly ignored them since writing them two years ago. When I recently had to update them with a new feature, I was extremely pleased that the usual js experience of finding out that I was a million versions behind wasn't there.
I'm confused, there's been a new major version every two years for the past decade. (Polymer 1 in 2015, Polymer 2 in 2017, Lit 1 in 2019, Lit 2 in 2021, Lit 3 in 2023.)
As I recall inside Google it was maybe one in a thousand elements that needed any changes at all. I updated the entire internal codebase of many tens of thousands of elements in a couple weeks of part time work.
But more importantly Lit 2 and Lit 3 are interoperable, so there's not the same pressure to update. When an element or library updates from Lit 2 to Lit 3, it can do that as a point release, because its public API is the same. This really reduces the amount of upgrade toil you have to deal with.
I love Lit! I have been using it to develop a in-app widget for product updates here: https://supanotice.com (the in app-widget opens up if you click on the bubble in the bottom right corner)
Really love the abstraction that makes web components easy to use.
Love Lit. I've pushed hard for Web Components at work for a while now with some success (the shine is definitely coming off of Angular for a lot of people there) and I've only used Lit to build my personal projects for a long time.
I love it when I visit one of my pages and use Lighthouse to check it out and have nearly straight across 100 scores. Also, I usually have really great performance on phones as well because the pages are so light and quick to render.
You can also use Web Components directly and manipulate them like regular HTML elements, no need to add a framework. Even using Shadow DOM isn't required.
Does Lit have a good component library? Like, a complete web template (eg. Bootstrap/Ant), datepicker, color picker, virtual scroll, data tables, typeahead, tab, etc.
I shipped a project with Lit and I liked it, but I didn't like that I'd need to know the complete project scope up front that I could write everything from the ground up. I know I could use React component for some of the harder stuff but at that point might as well use React and avoid bundling two systems
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.
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.
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.
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>`
}
}
The proposal is stuck at stage 3. AFAIK, to proceed to stage 4, it needs two independent implementations, but Firefox [0] and Chromium [1] didn't see any progress in this area for about a year. Personally, after working with Angular for many years, that's not a language feature I am looking forward to.
I love lit. I've been using lit in production since 2020 and I have never looked back. There is so much to say about lit, but I think the biggest win is that it's built on a very stable foundation. Building apps on top of native web components coupled with all the modern QoL features with Lit allows me to without the fear of some new framework/update coming along to the ecosystem - which in the FE world means the last X years worth of code becomes outdated. Native web components are a stable feature in all browsers and I can just focus on building - more engineering teams need to give it a try
If you're curious about lit and like longer form content - I recommend watching the [0] http 203 video that talks about lit element and other tools like it
Lit is amazing, one of the most concise framework out there. For deepening my understanding of concepts around Lit, I once built LittleLit, a 37 lines of code framework around Lit-html that helps understand how simple and elegant the moving pieces of this tech can be.
I’ve been using Lit to develop my Minecraft skin editor and it has been really nice to work with. Having initially tried working with vanilla web components, then creating my own wrapper class to make them easier to work with, I can say that Lit makes web components really nice to work with.
I’ve been incredibly lucky to spend about 6 years of the last decade NOT having to suffer through React, and I owe it all to Lit.
Using other frameworks to set up web view’s just don’t feel the same by comparison. I just want nested web components, and I just want Lit to help me define them. Tagged template literals for constructing HTML feels so much better than suffering through JSX.
I used lit for a project a couple years ago, and loved it. It had some warts, mostly around working with React components and the Shadow DOM. But it's barebones IIRC. One of the things I loved about it was that it was focused on implementing and using WebComponents via the standard, rather than re-inventing all their own thing.
Is the better DX using lit worth the price having to deal with another library? I thought webcomponents came to enable native components and now we need another library
The evolution of lit is fascinating to watch because it's built and promoted by people with rather visible and public dislike of everything React. And yet, it's already turned into React-lite.
// classMap looks like a regular JS function, but it's not.
// Both of these will produce an error
<div class="my-widget ${classMap(dynamicClasses)} ${classMap(dynamicClasses)}">Static and dynamic</div>
<div data-class="${classMap(dynamicClasses)}">Static and dynamic</div>
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.
Time to put the nail in that coffin! I use a static template to select and return components dynamically. It's a key aspect of my own internal "framework," made with Lit.
I love that I get to choose how everything works. I have custom systems for routing, styling, signals, API interactions. I control who gets passed what and when. It makes the app feel light, responsive, and -- most importantly, it fits in my head and I understand how it's put together because I chose it, not because I learned it from someone.
> You have a very large axe to grind against web components and Lit
Yes, yes I do. Because Web Components are almost 15 years now, and they still struggle with the most basic of things. How's that abandoned roadmap going? https://w3c.github.io/webcomponents-cg/2022.html
> No, there are no custom JavaScript rules. Templates have some rules.
That is "here are regular JS functions. However, you cannot use them as regular JS functions in these specific contexts". Reminds me of certain very specific rules about specific functions in specific contexts in some other framework. Can't put my finger on it.
> I'm not sure what makes that not a function.
I never said it doesn't make it a function.
> But to your main point: Lit is not like React because it's not a framework.
Yeah, React wasn't a framework either, but just a library. Everything about DOM elements that React produces, how you instantiate them, style them, where they work etc. is all defined by the HTML and DOM standards.
But then React grew in the number of features, and can no longer be called a library even though still the only thing it does is output some DOM nodes.
I guess you'll insist on Lit being "just a library" even after it adds a ton of other functionality all other frameworks already have or are moving towards.
> I'm not sure what the actual criticism is
The criticism is usual: Lit is rapidly absorbing all the features from all the other frameworks and becoming a framework itself while many of its developers and proponents can't stop shitting all over other frameworks.
I'm not sure how those links support your "lit proponents shit on other JavaScript libraries/frameworks", which was my complain about your post, or if that would even warrant as an excuse for you personally being an ass to the lit's maintainer directly.
Web Components is a pretty niche technology and as such it really appeals to some people, and it doesn't appeal to others, and that's okay. You don't have to like it, it isn't meant to be a good fit for everyone. But for some people it might fit really well with their requirements, and they probably have legitimate reasons for that.
If I understand correctly, your criticism is that the people for whom Web Components is a good fit are publicly discussing the reasons why they prefer it over other solutions?
The main problem is that for a "niche technology" it sure infects too many standards, requires an insane amount of new standards and makes supporting things needlessly complicated.
There are some good parts in the ~30 standards they require, but instead of just the good parts you get the whole horse, and the cart it's attached to, and the cargo in the cart.
> your criticism is that the people for whom Web Components is a good fit are publicly discussing the reasons why they prefer it over other solutions?
Ha this guy again, I recognize you too. I also don't understand your obsession with trolling on Lit and Web Components. You keep coming with the same arguments. And always very emotional. I get the feeling that it is something personal that you have against Lit / Web Components. And you're clearly a hater, and haters are gonna hate regardless of whatever happens.
I do wonder, why are you on this crusade? Are you afraid that people are at some point gonna be persuaded by Lit / Web Components, and that you need to be there to prevent that from happening?
By what I understood, I would expect him to use web components a lot even though he dislikes a few things, otherwise that would be really weird and a waste of life time.
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.
The developers of data-star.dev are working on something interesting they call "Rocket", but it's currently a WiP and hidden behind a paywall so I can't really compare it to Lit. Lit is great though, used it myself a few times (e.g. github.com/romshark/demo-islands). But I still think there's a learning curve to Lit. Better than raw vanilla JS custom elements API, but still not as simple as it could be.
I'm all for a lightweight approach to software development. But I don't understand the concept here.
Looking at the first example:
First I had to switch it from TS to JS. As I don't consider something that needs compilation before it runs to be lightweight.
Then, the first line is:
import {html, css, LitElement} from 'lit';
What is this? This is not a valid import. At least not in the browser. Is the example something that you have to compile on the server to make it run in the browser?
And when I use the "download" button on the playground version of the first example, I get a "package.json" which defines dependencies. That is also certainly not something a browser can handle.
So do I assume correctly that I need to set up a webserver, a dependency manager, and a serverside runtime to use these "light weight" components?
Or am I missing something? What would be the minimal amount of steps to save the example and actually have it run in the browser?
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:
I estimate the vast majority of "web projects" begin with npm installing something of some sort, yes. React is dominating the web development space (judging from the average "popular web stack 2025" search result), and it and a significant portion of the competing platforms start with installing some dependencies with npm (or yarn, or what have you). Especially projects that compete in the same space as Lit.
That isn't a criticism of projects that don't use npm, and it doesn't make them less valid, but it makes sense for the documentation to match the average developer's experience.
I had lit in a project at work and not having to deal with it anymore is just great. We already have another heavier component framework to do the actual application stuff anyway, so having two just because somebody wanted to optimize their resume was such a drag.
It all looked nice in theory, but one thing shadow DOM makes worse is A11y, because element ids are now scoped and all the missing describe-by, label-for for things that should link to other side of the fence are a massive pain in the ass.
Big part of it is just skill issue on our part of course.
Integrating these web components into our React codebase has been pretty awful--more of a web components thing than a Lit thing, IMO. We have "scoped styles", except for certain important things like font sizes, so tons of little regressions everywhere when we swap in the web component in place of the old React one. DX-wise, we lost a lot, too. I assume the tooling will get better, or that we'll figure it out more, but it's mostly been a drag
Are you migrating from react to something else? I see the appeal of web components as a middle ground for base library when different frameworks coexist (temporarily or not), but everyone is so hellbent on monoculture this days that I don't see the point really.
Shadow DOM is optional in Lit - you can just disable it on a per-component basis.
It should not be the default. This is almost certainly Lit's biggest flaw.
I am currently working on a web components framework, and I scrapped everything halfway through after I realized that you very rarely want that much encapsulation. Now, you can turn it on if you really need it, and I even made a way where you can pass references to DOM elements and stylesheets and such into each component so you can pierce the shadow veil easily. I have one demo to show it off, but I'm really having trouble imagining when someone would actually want to use it. The only time I can imagine it being useful would be building component libraries inside of large organizations.
I'm not ready to show off my framework yet, but I'm very certain that this leads to a better DX.
>The only time I can imagine it being useful would be building component libraries inside of large organizations.
That was our use case and we are migrating away from custom elements to a more conservative approach.
Good luck with your better framework, but if this is the biggest flaw… then there’s really not much to complain about.
Thanks! That's hardly the biggest difference to Lit. I think Lit is a fantastic framework, and I'm not trying to replace it or anything. However, it's really unopinionated which is fantastic for flexibility, but it leads to every deployment looking and feeling very different.
Basically, I'm just curious what a full-stack web component framework with strong defaults could look like. This is primarily a learning exercise, and a way to experiment with integrating web components into modern framework concepts like streaming server components, resumability, automatic serialization, and type-safe RPCs. I don't know if it will ever be production-ready, but I've learned a lot and it's been a ton of fun.
Have you seen https://brisa.build/? Its not web-components first but it looks really well designed and may give you some inspo
causes a bunch of things to no longer work though - slots, style encapsulation, ...
If you need style encapsulation, use the Shadow DOM. Slots still work IIRC.
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.
And that's the biggest problem with Shadow DOM (and most web component specs): you can't chose the good parts. Style encapsulation is useful, slots are useful, Shadow DOM is just all around bad, having a crazy amount of edge cases and broken behaviours [1].
Can you use style encapsulation and slots without Shadow DOM? Why can't you? I only need the horse, not the horse, and the cart, and the driver, and all the cargo in the cart.
You can't because people pushing all this stuff forward never ever stopped to think whether this was a good idea, and never ever talked to anyone outside of their own group.
[1] I will keep quoting this report by Web Components Working Group to death:
--- start quote --
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.
...
Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM. While there are ways to develop these UIs by orchestrating the relationships between elements of synthesizing the passing of content across a shadow boundary, these practices generally position accessible development out of reach for most developers, both at component creation and component consumption time.
...
Selection does not work across or within shadow roots. This makes fully-featured rich-text editors impossible to implement with web components. Some of the web's most popular editors have issues that are blocked on this functionality.
--- end quote ---
That was exactly my experience using it. Great at first, and then hitting real-world and being stuck with the lack of sharing styles (in my case).
Shadow DOM was an absolute pain in reality.
I've been working on a legacy server-rendered app that has a bunch of ajax calls, and stock web components and their shadow DOM has been super helpful to keep the mess at bay. Most of the work is actually making the app more accessible, actually.
The trick is that the components really do need to be self contained, and you need to use slots and custom attributes to bridge the gaps. Styling is the most annoying part for me, but I just include the same global imports that the main page has.
> so having two just because somebody wanted to optimize their resume was such a drag.
Does this actually happen a lot? Allowing for the fact that people would rarely admit to it just being about resume padding, I feel like just wanting to _use_ the thing is a far more common motivation for poorly rationalised technology choices.
I made a state management lib for Lit, that's just as lightweight (258 lines) and intuitive:
https://github.com/gitaarik/lit-state
I've used it extensively myself, for creating complex web apps with many (nested) components interacting with each other.
I don't understand why Lit hasn't gained more popularity, because for me it is basically React, but then more browser-native, much less boiler plate, and much faster rendering. There are some things you have to get used to, but when you do it doesn't limit you in any way.
Re-implementing Lit from fundamentals is a great way to learn how it works! The core functionality is surprisingly simple, because it mostly relies on platform APIs to do the heavy lifting, like parsing templates.
I made this alternative implementation of lit-html to use as a research bed a long time ago when I was actively contributing to lit: https://github.com/ruphin/lite-html
Judging from this thread, many people have their own implementations, which is great to hear. I think there's a lot of value in solutions that are so simple that anyone can reproduce them.
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 :)
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:
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.
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
Aren’t a lot of components leaf nodes, with no slots? Does the shadow dom have any benefits for them?
We used to put a link to the overall stylesheet in the webcomponents. That works pretty good
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...
Thanks, great article. It’s always good to understand the context of where libraries fit into the web ecosystem and why they exist. Much appreciated!
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 ...
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.
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...
I hope there can be ways without JS to populate templates with data - autoloaded from sources. This would tremendously increase the number of JS free web-sites. Also wish the web-components standard did not mandate the use of JS. It should be possible to define simple web-components (HTML+CS) declaratively and have this officially supported in standard and implementation
The irony is that the original vision of web components was what you wanted. See Alex Russels "a vision for the Future": https://web.archive.org/web/20121119184816/https://fronteers...
--- start quote ---
I think we're stuck today in a little bit of a rut of extensibility. We wind up leaning on JavaScript to get things, because it is the Turning complete language in our environment. It is the only thing that can give us an answer when CSS and HTML fail us. So we wind up piling ourselves into the JavaScript boat. We keep piling into the JavaScript boat.
Bruce yesterday brought up the great example of an empty body tag, and sort of this pathological case of piling yourself into the JavaScript boat, where you wind up then having to go recreate all of the stuff that the browser was going to do more or less for you if you'd sent markup down the wire in order to get back to the same value that was going to be provided to you if you'd done it in markup. But you did it for a good reason. Gmail has an empty body tag, not because it's stupid. Gmail does that because that's how you can actually deliver the functionality of Gmail in a way that's both meaningful and reliable and maintainable. You wind up putting all of your bets, all of your eggs, into the JavaScript basket.
....
They're the sorts of things that you use when the semantic that you're trying to express is so far away from what HTML natively has a semantic for, that you're willing to go and be completely self served for it. Taking on for yourself accessibility, UI, UX, internationalization, localization, performance, theme ability; all of this stuff is mostly taken care of for you by HTML.
--- end quote ---
14 years later, web components depend on JS to:
- participate in forms
- solve accessibility issues (not yet, but coming through a yet another JS-only standard)
- SSR is still mostly tied to JS and specific JS frameworks (and Declarative Shadow DOM doesn't really solve the issue because it requires you to duplicate a lot of code). See also https://ionic.io/blog/the-quest-for-ssr-with-web-components-...
- CSS modules and other imports that are moved entirely into JS
etc. etc.
-----
Slight off topic. From the same talk:
--- start quote ---
Now, we can do some of that today. We can go and look at the top million pages and figure out which JavaScript library that they're using, which features are being most heavily used, we can put those things in DOM. But is that the right place for them? It's a hard thing to figure out.
--- end quote ---
I wish they spent time figuring that out. We wouldn't have to wait a few decades for https://open-ui.org to slowly make its way into the browsers.
> Lit has always been designed partially as a prototype for where web component standards could go in the future.
> There is a proposal in TC39 for native signals,
Which originated (or the modern versions of signals originated) in Solid, not in Lit.
Let me quote the readme: https://github.com/tc39/proposal-signals
--- start quote ---
The current draft is based on design input from the authors/maintainers of Angular, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…
-- end quote ---
They never claimed that signals originated in lit. They were just responding to the comment that there's no native reactivity in web components...
Curious which web platform features are missing that are preventing Web components to complete with React(for application development not widgets)?
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
> - Open styleable shadow roots
What people using web components want is to get rid of shadowDOM and not feel like they are deviating from the correct path. shadowDOM sucks, stop trying to convince the world that we are using it wrong. shadowDOM is the whole reason web components did not become mainstream (yet?).
Nothing in Web Components is forcing you to use ShadowDOM. Lit also allows you to make components without ShadowDOM if you prefer, because there are certainly cases where it can be necessary to do so (like for ARIA reference id-matching). For full single application development, it can feel like it gets in the way a lot, and you can make a good argument to use components without ShadowDOM in those contexts too.
All frontend "frameworks" do have some sort of solution to scope CSS to individual components, and without a similar solution, a native component system would not be viable. The implementation has its quirks, but it is a core capability that is necessary for some use cases. For third-party widgets or cross-application components like design systems, the ability to isolate your component from the site it is embedded in is very useful.
Think of shadowDOM as the web component alternative to scoped styles in Vue components (as an example). You don't have to use it, but it would be incredibly inconvenient if it wasn't included in the framework.
> Nothing in Web Components is forcing you to use ShadowDOM
Yes. There is just one thing forcing someone to use shadowDOM: slots. You can't use slots without shadowDOM or at least use something like this.children to capture the content inside the <custom-element></custom-element>.
But that is quite the important feature lacking.
In my mind this has always made no sense to me, why slots aren’t independent of the shadow dom.
Same thing with how css is handled, especially since we have @layer and @scoped now
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.
I disagree completely. Shadow DOM is a huge help and when combined with per-component CSS using the :host() and nesting pattern, makes for very small CSS files and very short CSS class names. In other words, as far away from Tailwind as you can get.
It's also possible to import shared CSS in a base class and add it with super.styles() so you don't lose anything.
What about shadow dom sucks?
How else do you achieve that level of encapsulation to enable portable components?
You don't want to enable portable components all the time. If most of the components you use to create your app is made by yourself, those boundaries are annoying, not helpful.
The point is you mostly don't want this level of encapsulation
Please do not refer to CSS type imports in JS as CSS Modules.
CSS Modules has an established meaning for over a decade, one that is still relevant today. The CSS type imports are very different, and arguably worse.
Call them CSSStyleSheet imports of you need a name suggestion.
About CSS Modules – Are you referring to this? https://caniuse.com/mdn-javascript_statements_import_import_...
Seems like this feature was removed from Chrome.
Import assertions were replaced with import attributes (`assert` replaced by `with`).
See https://caniuse.com/mdn-javascript_statements_import_import_...
>- ARIA reference target: make idref-based reference work across shadow roots
How is this even supposed to work if each shadow dom has it's own scope of ids? `#id#subid` or something?
What if I want to ref to the outside?
The whole thing is not made for web development.
You can start with the Web Components Community Report: https://w3c.github.io/webcomponents-cg/2022.html
Or with opinions like this: https://dev.to/ryansolid/web-components-are-not-the-future-4...
O if you want to go down the technical rabbit hole, you can search for all the issues people have with them, e.g.: https://x.com/Rich_Harris/status/1841467510194843982
Another pain in the ass is the fact web components are registered globally. Good luck marrying this with npm dependency hell where two transitive dependencies both import a button.
The good part of react and friends is it's just javascript and the class is imported and referenced normally, not with a weak string-binding-through-registry kind of way.
Now add types to the mix and shadow dom and it brings constant problems without any upside.
I am not the one who submitted it. But someone mentioned it last night:
https://news.ycombinator.com/item?id=45107388
I assume someone else looked it up and liked it enough to submit it.
Are properties reactive?
Can I reassign name in the example by using document.querySelector?
Yes!
What I wonder is whether there are any developments related to Lit regarding server-side rendering (SSR). This is one of the reasons I'm experimenting with Svelte now. To me Lit was taking away frustrations with the inefficiencies of React. But for me Svelte seems to fill that gap too, and it also has SSR, among other niceties. But I do like the philosophy of Lit & Web Components. Sometimes I think a framework that would be like Svelte but uses Lit under the hood would seem like the best of both worlds.
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)?
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...
Is there a way to efficiently use Lit without using a bundler?
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.
So let me get this straight: HTML was originally built to have markup and style both in the same containers, and it was clunky and hard to maintain, so CSS was invented, to abstract away the styles so that content and style could be separate. And that worked pretty well. And then someone came along and said: you know what would be great? Removing all the useful abstractions and going back to the HTML 1.0 way of putting it all in one container. And rewriting HTML in JavaScript to make it less maintainable. And so on. Am I getting this right? Correct me if I'm wrong.
I used Lit components in a large FE project, enjoyed doing so and am happy with my choice. I don't use the shadow DOM at all.
The project is Converse.js, an XMPP chat client. It's an old project that was originally created back in 2013 with Backbone.js.
I first replaced all templates with `lit-html` when I first heard about that, and then when lit-element (and now "lit") came out, I started rewriting the project to use that.
This app has since been integrated into many different websites that rely on other frameworks like React and the fact that Converse.js is a web component (<converse-root />) makes this easier.
If you're interested, here's the Github repo: https://github.com/conversejs/converse.js And you can demo it here: https://chat.conversejs.org/
You'll need an XMPP account (see https://providers.xmpp.net/ for possible providers).
I don't see the need for Lit anymore. Lately I have just been raw dogging web components without any libraries. Having a nice templating system like JSX on the server makes it a breeze.
Part of using web components, for me, is that it is just javascript. There is no upgrades or deprecations to think about. Of course those things still exist on the server though, but it is easier to maintain it there.
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.
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.
Yeah, it does require some more boilerplate. I abstract some of it JSX, and with LLMs writing boilerplate code isn't that annoying anymore.
I find that there is little practical difference between "html" tagged template literal and writing JSX. Not to mention there is a compilation step in JSX.
Don't know the current state of lit-html and similar, but Typescript support was the biggest thing missing for me when I used it several years ago.
In simple scenarios like just dropping it in an html page, codepen, or something like that I really enjoyed it though.
I mean sure, as long as it runs on the server. Personally I feel JSX is way more expressive. The JSX I write runs on server side rendering to HTML. That way there will be no flash of unstyled content, cumulative layout shift, or any other jank. It looks correct even before the javascript has been downloaded, except it isn't interactive yet.
I have been using Lit in production for 3 years now. I think it is the best abstraction over the web components API out there.
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.
Same about the shadowDOM. The only criticism I have about Lit is that the creators think shadowDOM is amazing and people not liking it are using it wrong. Lit lacks a good direction and someone with vision leading it but it became the technical pet project of a few.
The ability to locally scope styles is a great feature of shadow DOM. For that alone I can see why it's being pushed.
It's trivially easy to create Lit components without shadow DOM so I don't really care and use both.
For the frontend work that I did, Lit was a godsend. It really helps you build components and apps without getting in the way.
In comparison, Angular is a monster, and React is designed for the old browser capabilities, and is now staying around by inertia, not by inherent quality.
Which old browser capabilities are you referring to? Could you say more, or link to more details?
No shadow DOM, no web components, no template strings, etc.
> No shadow DOM
Funny you should say that when the current advise for web components is to avoid Shadow DOM (almost like the plague)
> no web components
As in?
> no template strings
Why would React need template strings? React is not the only framework that doesn't use template strings for anything (Vue, Solid, Svelte come immediately to mind). And it's hard to accuse those of being behind the times when Solid is literally the reason for the upcoming native signals proposal
> the current advise for web components is to avoid Shadow DOM (almost like the plague)
Could you provide the source for this advice?
It may have actually started with Web Components Community Group report itself: https://w3c.github.io/webcomponents-cg/2022.html
--- start quote ---
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM. We urge browser vendors to recognize these barriers and work to make Shadow DOM more usable by more developers.
--- end quote ---
And probably continued in HTML Web Components https://blog.jim-nielsen.com/2023/html-web-components/
A more technical and measured take on Shadow DOM is here: https://nolanlawson.com/2023/12/30/shadow-dom-and-the-proble...
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.
In a parallel discussion happening on Mastodon, someone says:
> People coming from React-land can have a hard time reasoning about the difference between a custom element and a template render function and when best to use each
> This abuse of the component system can indeed lead to a massive explosion in nodes on a page and the performance tanks because of that
I know I certainly have that hard time deciding when I need a custom element and when a render function.
[0] - https://front-end.social/@5t3ph/115135994774490769
> As soon as they try to build any kind of container element they hit big problems.
That's not true. Web components that render nothing will contain only their children as nodes, that's good enough for a good amount of container use cases.
So you can have something like:
It could be better, but this little annoyance is still better than React, Angular, and the other options.> It's wrong - both that it's general "current advice", and the advice itself when it does pop up.
Unless you actually care about the web and its users. Then it turns out it's a very wise advice.
https://w3c.github.io/webcomponents-cg/2022.html
Web Components Community Group: 2022. You are one of the authors:
--- start quote ---
It's worth noting that many of these pain points are directly related to Shadow DOM's encapsulation. While there are many benefits to some types of widely shared components to strong encapsulation, the friction of strong encapsulation has prevented most developers from adopting Shadow DOM, to the point of there being alternate proposals for style scoping that don't use Shadow DOM.
...
Selection does not work across or within shadow roots. This makes fully-featured rich-text editors impossible to implement with web components. Some of the web's most popular editors have issues that are blocked on this functionality
...
Shadow boundaries prevent content on either side of the boundary from referencing each other via ID references. ID references being the basis of the majority of the accessibility patters outlines by aria attributes, this causes a major issue in developing accessible content with shadow DOM.
--- end quote ---
Those are just the tip of the iceberg as these are very explicitly stated in the doc.
Then there's the issues of shifting the responsibility to both developers and consumers to handle Shadow DOM correctly.
Styling/themeing is still pain despite several different specs like shadow parts.
Don't use styles in your components too much, use Javascript to inject CSS into document and shadow trees or else there will be performance impact https://w3c.github.io/webcomponents-cg/2022.html#constructab...
Don't use too many shadow roots or there will be performance impact https://front-end.social/@5t3ph/115135994774490769 (linked in the sibling comment by @azangru)
You can't participate in forms until you write more JS for it, and still your submit buttons will be broken with no solution in sight.
etc. etc.
You don't have to take my word for it. Here's Nolan Lawson, emphasis mine:
--- start quote ---
https://nolanlawson.com/2022/11/28/shadow-dom-and-accessibil...
Shadow DOM is a kind of retcon for the web. As I’ve written in the past, shadow DOM upends a lot of developer expectations and invalidates many tried-and-true techniques that worked fine in the pre-shadow DOM world.
--- end quote ---
Did web components kill your dog or something? You have this truly bizarre fixation on the topic for multiple years now.
Perhaps I care about the direction in which the web is pushed by a very small number of people incapable of seeing beyond their solutions and incapable of admitting their own mistakes.
I'm 100% with you on that.
At no point have I ever gotten the impression that you are even remotely open to seeing other points of view so it’s a bit hard to take the moralistic tone of the brave defender of the web part seriously. I think you just want to yell at people.
Web Components have been in development for 14 years. If you think this is the first discussion of web components, you clearly haven't been paying attention.
All there is to say was said years ago. Today it should be enough to know that, for example, "form associated custom elements cannot be a submit button" issue was opened 6 years ago, in 2019: https://github.com/WICG/webcomponents/issues/814
In 2022 web component group report mentions it in passing: https://w3c.github.io/webcomponents-cg/2022.html#concerns-10
That issue is still open.
Or that web components breaking ARIA was known at least 2019: https://x.com/sarahmei/status/1198069119897047041 and this will not be fixed for another 4-5 years at least.
Imagine if any web framework had issues like that.
That doesn't even begin to cover things like "now every useful spec has to be acutely aware of Shadow DOM shenanigans" which delayed any number of specs like scoped CSS etc
It’s just like an LLM stuck on a loop. It’s just years and years of making the exact same comments, not responding to any counter arguments and then demanding that people take you seriously.
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.
I thankfully migrated or left all Aurelia projects, but every time someone mentions it, I remember new horror stories.
Its .html temples were shipped unmodified directly to the client (yes, including comments). Except they weren't actually html, and sometimes the browser would try to clean them up, breaking the template.
Reactivity was achieved through all kinds of weird mechanisms (eg monkey-patching arrays to watch for mutations). It would frequently resort to polling on every tick or break completely.
DI used TypeScripts experimental decorators, even long after it was clear that it would never become stable.
On the other hand, templates weren't type checked.
Never had issues with the HTML. Templates sometimes showed comments in dev mode, but in production builds they were stripped and everything minified. I never used Webpack or other bundlers, only the "dumber.js" from their CLI, so maybe was something related to that?
And yeah, probably they monkey-patched arrays and such, but that was just the way of the world before proxies and native signals. The cool part is Aurelia stuck to web standards, and those “weird mechanisms” were basically polyfills, so even old versions still run solid today, sometimes even faster by leveraging native features.
> Never had issues with the HTML
https://github.com/aurelia/binding/issues/108
> I never used Webpack
That has little to do with Aurelia, and Aurelia itself integrates with Webpack: https://github.com/aurelia/webpack-plugin
> The cool part is Aurelia stuck to web standards, and those “weird mechanisms” were basically polyfills
I could agree that Aurelia looks like you’re sticking to standards¹. If you don’t think about it, then everything kinda works 90% of the time.
But when you actually try to understand what goes on behind the scenes, like you can with React and Angular, there are just so many footguns, especially around composition and reactivity.
Even simple things like passing optional props² or detecting if a <slot> is occupied involved depressing amounts of reverse-engineering.
I’ve heard that Aurelia 2 supposedly fixes many of my issues, but I believe the core idea is beyond fixing. React, Solid and others have more powerful approaches that require fewer concepts to understand.
¹ Although there are still tons of custom concepts and syntax to learn.
² https://github.com/aurelia/templating-binding/issues/106
I thankfully migrated or left all Aurelia projects, but every time someone mentions it, I remember new horror stories.
Its .html temples were shipped unmodified directly to the client. Except they weren't actually html, and sometimes the browser would try to clean them up, breaking the template.
Reactivity was achieved through all kinds of weird mechanisms (eg monkey-patching arrays to watch for mutations). It would frequently resort to polling on every tick or break completely.
DI used TypeScripts experimental decorators, even long after it was clear that it would never become stable.
On the other hand, templates weren't type checked.
"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
React is 12 years old. That’s a significant chunk of anyone’s life.
Web components are 14 years old, and still have the most basic issues and problems that even a 6-month-year-old framework would ashamed to have.
I await your in depth critique on the front page.
You think that in 14 years many critiques from many authors didn't appear on the front page? It's not a big deal to reach the front page of HN.
No worries, web components themselves have a very nice critique in the form of their own community report https://w3c.github.io/webcomponents-cg/2022.html listing all the issues that many people had been taking about for literal years before this report.
There have been many that have hit the front page over the years. If you're not aware of a technology's shortcomings then you're a bad proponent of said technology. They're also almost the antithesis of what the HTMX crowd also preaches as "the one true way" and meanwhile, Wordpressers will continue developing the majority of the world's websites blissfully unaware that either technology even exists.
https://dev.to/ryansolid/web-components-are-not-the-future-4...
https://dev.to/richharris/why-i-don-t-use-web-components-2ci...
https://daverupert.com/2023/07/why-not-webcomponents/
https://paularmstrong.dev/blog/2023/03/11/why-we-do-not-writ...
https://nolanlawson.com/2024/09/28/web-components-are-okay/
https://www.zachleat.com/web/good-bad-web-components/
https://mayank.co/blog/web-components-considered-harmful/
https://adamsilver.io/blog/the-problem-with-web-components/
https://web-highlights.com/blog/are-web-components-dead/
along with some criticisms from very knowledgeable people:
https://x.com/youyuxi/status/1839833110164504691 (author of Vue) https://x.com/Rich_Harris/status/1839785839036887361 (author of Svelte)
Web Components solve a few problems and introduce a few others, use them when they make sense for your needs.
Hands down the most underrated front end library out there. It powers some major projects like ChromeOS, Chrome Devtools, I think most of Firefox’s UI, Photoshop for the web, MDN etc.
Also Reddit! Any other surprise sites?
I think lit is great but the reddit site is the perfect example of why the framework you chose is not the reason your site is slow.
I think lit should distance itself from that mess if possible
Site seems fine to me on mobile and desktop (only use the web app in Firefox). Their main issues are with data fetching, not rendering.
I just came across this resource the other day and found it super helpful, thought I would share it here for anyone who’s interested in working with Lit.
https://lit.dev/articles/lit-cheat-sheet/
I really like the standalone lit-html rendering library but never really saw a need for Lit. Honestly, I find it hard to see a need for more than <any client-side rendering lib> + Web Components when I want client-side rendering.
Working with a large Vue 3 project and wanting to share some of our components as re-usable web components for other sites to embed...
What would be the benefit of rebuilding these components in Lit over using Vue to build them?
https://vuejs.org/guide/extras/web-components#building-custo...
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.
Thanks for this. I think you're right -> "focus on shipping features instead of changing your tech stack"
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.
Vue can be used as an ordinary JS library without special build setup. You can even load the library from a CDN as a global variable like the old jQuery days.
Thought I'd add an example:
https://github.com/SaleCar/Quasar-UMD-Template
You can do sophisticated things as well eg. Stream half a million Kafka records into the browser- anything available from unpkg or other cdns.
A good cdn UI lib turns out to be https://quasar.dev/
Oh nice, I wasn't aware this was even possible.
Vue _does_ have some sort of build step, because components use special macros that aren't imported, and the compiler (vite) even complains when you actually import them saying it's not necessary. The build also rewrites your code to some other format that I assume is more optimized because it can do some sort of static analysis.
Are these the main reasons for Vue to use a compiler if it's not necessary? Injecting dependencies and rewriting some code to allow better performance while retaining the nice syntax?
It's a combination of things.
Adding polyfills for older browser targets.
Tree shaking, that is removing code that is not used.
Bundling several files into one to save on requests.
Transpiling, that is, if you want to write code in a different language to javascript eg. Typescript then vite will compile that to javascript.
Linting ie. Reformatting your code to standardise it across developers.
Vulnerability checking, are your dependencies out of date?
Execution of build tasks eg. Preparing static assets like images.
Packaging your app for deployment eg. Zipping
Including logging and hot reload triggers during development.
Bundling environment specific changes eg. Different backend urls if deploying to test envs.
Running unit tests on rebuild to avoid regressions.
Having said all that, the bundling for me is a disadvantage as my own code changes more than 3rd party libs and they are cached. I'm less fussed with types and a lot of the tests and env stuff can be done with a single-file express server for development.
The main advantage for me is that a buildless app will still work correctly in 6 months- permacomputing considerations.
IRRC Vue will compile your templates on the fly if you don't pre-compile them, so you will be punished twice -- in performance and in bundle size for skipping the build step.
If you can eat the cost to get something in return, it's a nice trade off.
Thanks for the in-depth response, much appreciated
>Working with a large Vue 3 project and wanting to share some of our components as re-usable web components for other sites to embed...
Make a fat bundle with a web component or even a mount() function exported and run whatever fits your devx inside, with the API surface as narrow as possible. As long as it's self contained and the size is reasonable, nobody on a consumer side cares how you cook, so optimize your own pipelines to build, test and publish it.
People will build adapters to fit it into their stuff anyway and will let you know.
Lit is fantastic lib as a way out from legacy web framework (since can be injected in any framework including Vue, Angular, React). I used it as a way out out of old Vue2 project
Lit is amazing, I'm a big fan of Astro for using it as static websites, blogs, etc., but Lit would've been the second choice if not Astro.
I used lit for a few small components on my blog, https://pdx.su, and have mostly ignored them since writing them two years ago. When I recently had to update them with a new feature, I was extremely pleased that the usual js experience of finding out that I was a million versions behind wasn't there.
I'm confused, there's been a new major version every two years for the past decade. (Polymer 1 in 2015, Polymer 2 in 2017, Lit 1 in 2019, Lit 2 in 2021, Lit 3 in 2023.)
Lit 2 to Lit 3 was really minimal: https://lit.dev/docs/releases/upgrade/
As I recall inside Google it was maybe one in a thousand elements that needed any changes at all. I updated the entire internal codebase of many tens of thousands of elements in a couple weeks of part time work.
But more importantly Lit 2 and Lit 3 are interoperable, so there's not the same pressure to update. When an element or library updates from Lit 2 to Lit 3, it can do that as a point release, because its public API is the same. This really reduces the amount of upgrade toil you have to deal with.
It's 2025
I love Lit! I have been using it to develop a in-app widget for product updates here: https://supanotice.com (the in app-widget opens up if you click on the bubble in the bottom right corner)
Really love the abstraction that makes web components easy to use.
Love Lit. I've pushed hard for Web Components at work for a while now with some success (the shine is definitely coming off of Angular for a lot of people there) and I've only used Lit to build my personal projects for a long time.
I love it when I visit one of my pages and use Lighthouse to check it out and have nearly straight across 100 scores. Also, I usually have really great performance on phones as well because the pages are so light and quick to render.
You can also use Web Components directly and manipulate them like regular HTML elements, no need to add a framework. Even using Shadow DOM isn't required.
Typescript can even add Intellisense to "customElements.get" by augmenting CustomElementRegistry: https://gist.github.com/cecilemuller/72fbb3bc3a77d82c8a969cd...
Does Lit have a good component library? Like, a complete web template (eg. Bootstrap/Ant), datepicker, color picker, virtual scroll, data tables, typeahead, tab, etc.
I shipped a project with Lit and I liked it, but I didn't like that I'd need to know the complete project scope up front that I could write everything from the ground up. I know I could use React component for some of the harder stuff but at that point might as well use React and avoid bundling two systems
Yes, take a look at https://webawesome.com/
In addition, to what is already posted, you also have:
- https://github.com/vaadin/web-components
- https://github.com/material-components/material-web (very, very sadly killed by google management)
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.
these are cool but are CSS only, there is no interactivity.
Also building a component library atop tailwind feels so disgustingly wrong
Great project but I can't stand syntax such as decorators.
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.
> Decorators are the only way to metaprogram over class fields in JS.
I can think about few other ways, such as using higher order functions/classes, using getOwnPropertyDescriptor or doing stuff at construction.
> As mentioned by skrebbel, decorators are optional
This is not a pro, it's a con. The more ways there are to achieve the same result the more inconsistent projects become IRL.
Also, do you really want to metaprogram at all? What's the huge benefit of that approach?
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:
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:
> Decorators are the only way to metaprogram over class fields in JS.
No, they are not. Decorators don't even exist in JavaScript. Stop assuming typescript is Javascript or even worse, that everybody is on board.
> There's a switch that will change everything on the site from JS to TS globally.
Lol.
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.
They are optional for what it’s worth. They are also landing in standard JS soon.
The proposal is stuck at stage 3. AFAIK, to proceed to stage 4, it needs two independent implementations, but Firefox [0] and Chromium [1] didn't see any progress in this area for about a year. Personally, after working with Angular for many years, that's not a language feature I am looking forward to.
[0] https://bugzilla.mozilla.org/show_bug.cgi?id=1781212
[1] https://issues.chromium.org/issues/42202709
I wouldn't hold my breath. Decorators landing in standard JS "soon" has been the claim for about a decade running.
Not seeing decorators in the JS version:
Why exactly?
I love lit. I've been using lit in production since 2020 and I have never looked back. There is so much to say about lit, but I think the biggest win is that it's built on a very stable foundation. Building apps on top of native web components coupled with all the modern QoL features with Lit allows me to without the fear of some new framework/update coming along to the ecosystem - which in the FE world means the last X years worth of code becomes outdated. Native web components are a stable feature in all browsers and I can just focus on building - more engineering teams need to give it a try
If you're curious about lit and like longer form content - I recommend watching the [0] http 203 video that talks about lit element and other tools like it
[0] - https://www.youtube.com/watch?v=uCHZJy2n8Qs
Lit is amazing, one of the most concise framework out there. For deepening my understanding of concepts around Lit, I once built LittleLit, a 37 lines of code framework around Lit-html that helps understand how simple and elegant the moving pieces of this tech can be.
https://benoitessiambre.com/vanilla.html
I’ve been using Lit to develop my Minecraft skin editor and it has been really nice to work with. Having initially tried working with vanilla web components, then creating my own wrapper class to make them easier to work with, I can say that Lit makes web components really nice to work with.
My editor: https://needcoolershoes.com
I’ve been incredibly lucky to spend about 6 years of the last decade NOT having to suffer through React, and I owe it all to Lit.
Using other frameworks to set up web view’s just don’t feel the same by comparison. I just want nested web components, and I just want Lit to help me define them. Tagged template literals for constructing HTML feels so much better than suffering through JSX.
I used lit for a project a couple years ago, and loved it. It had some warts, mostly around working with React components and the Shadow DOM. But it's barebones IIRC. One of the things I loved about it was that it was focused on implementing and using WebComponents via the standard, rather than re-inventing all their own thing.
Is the better DX using lit worth the price having to deal with another library? I thought webcomponents came to enable native components and now we need another library
I thought that the implementation of web components was purposefully low level and that a library on top was the way to go.
lit-html is enough, tbh
The evolution of lit is fascinating to watch because it's built and promoted by people with rather visible and public dislike of everything React. And yet, it's already turned into React-lite.
- Custom HTML-like syntax
- Custom Javascript rules - Custom rules for special functions. - Context https://lit.dev/docs/data/context/- Experimental compiler: https://github.com/lit/lit/tree/main/packages/labs/compiler#...
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.
Time to put the nail in that coffin! I use a static template to select and return components dynamically. It's a key aspect of my own internal "framework," made with Lit.
I love that I get to choose how everything works. I have custom systems for routing, styling, signals, API interactions. I control who gets passed what and when. It makes the app feel light, responsive, and -- most importantly, it fits in my head and I understand how it's put together because I chose it, not because I learned it from someone.
> You have a very large axe to grind against web components and Lit
Yes, yes I do. Because Web Components are almost 15 years now, and they still struggle with the most basic of things. How's that abandoned roadmap going? https://w3c.github.io/webcomponents-cg/2022.html
> No, there are no custom JavaScript rules. Templates have some rules.
That is "here are regular JS functions. However, you cannot use them as regular JS functions in these specific contexts". Reminds me of certain very specific rules about specific functions in specific contexts in some other framework. Can't put my finger on it.
> I'm not sure what makes that not a function.
I never said it doesn't make it a function.
> But to your main point: Lit is not like React because it's not a framework.
Yeah, React wasn't a framework either, but just a library. Everything about DOM elements that React produces, how you instantiate them, style them, where they work etc. is all defined by the HTML and DOM standards.
But then React grew in the number of features, and can no longer be called a library even though still the only thing it does is output some DOM nodes.
I guess you'll insist on Lit being "just a library" even after it adds a ton of other functionality all other frameworks already have or are moving towards.
> I'm not sure what the actual criticism is
The criticism is usual: Lit is rapidly absorbing all the features from all the other frameworks and becoming a framework itself while many of its developers and proponents can't stop shitting all over other frameworks.
As a third party I can't help but notice that the only one doing the "shitting" here, is you.
You don't have to take only my word for it https://news.ycombinator.com/item?id=45118434
I'm not sure how those links support your "lit proponents shit on other JavaScript libraries/frameworks", which was my complain about your post, or if that would even warrant as an excuse for you personally being an ass to the lit's maintainer directly.
Take this as some constructive feedback that you really come across as a miserable bastard to everyone reading your comments.
Web Components is a pretty niche technology and as such it really appeals to some people, and it doesn't appeal to others, and that's okay. You don't have to like it, it isn't meant to be a good fit for everyone. But for some people it might fit really well with their requirements, and they probably have legitimate reasons for that.
If I understand correctly, your criticism is that the people for whom Web Components is a good fit are publicly discussing the reasons why they prefer it over other solutions?
> pretty niche technology
The main problem is that for a "niche technology" it sure infects too many standards, requires an insane amount of new standards and makes supporting things needlessly complicated.
A few links here: https://news.ycombinator.com/item?id=45114450
There are some good parts in the ~30 standards they require, but instead of just the good parts you get the whole horse, and the cart it's attached to, and the cargo in the cart.
> your criticism is that the people for whom Web Components is a good fit are publicly discussing the reasons why they prefer it over other solutions?
It's not.
Ha this guy again, I recognize you too. I also don't understand your obsession with trolling on Lit and Web Components. You keep coming with the same arguments. And always very emotional. I get the feeling that it is something personal that you have against Lit / Web Components. And you're clearly a hater, and haters are gonna hate regardless of whatever happens.
I do wonder, why are you on this crusade? Are you afraid that people are at some point gonna be persuaded by Lit / Web Components, and that you need to be there to prevent that from happening?
By what I understood, I would expect him to use web components a lot even though he dislikes a few things, otherwise that would be really weird and a waste of life time.
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.
My 3d bin packer is written with lit and F#
https://3dpack.ing
I looked at lit but chose JSX.
Typescript has JSX built in so when "I made my own framework" I just used that.
The developers of data-star.dev are working on something interesting they call "Rocket", but it's currently a WiP and hidden behind a paywall so I can't really compare it to Lit. Lit is great though, used it myself a few times (e.g. github.com/romshark/demo-islands). But I still think there's a learning curve to Lit. Better than raw vanilla JS custom elements API, but still not as simple as it could be.
(Formerly lit-element)
“You got Lit up!”
thank you, I am not brining inheritance and decorators back to the web
I'm all for a lightweight approach to software development. But I don't understand the concept here.
Looking at the first example:
First I had to switch it from TS to JS. As I don't consider something that needs compilation before it runs to be lightweight.
Then, the first line is:
What is this? This is not a valid import. At least not in the browser. Is the example something that you have to compile on the server to make it run in the browser?And when I use the "download" button on the playground version of the first example, I get a "package.json" which defines dependencies. That is also certainly not something a browser can handle.
So do I assume correctly that I need to set up a webserver, a dependency manager, and a serverside runtime to use these "light weight" components?
Or am I missing something? What would be the minimal amount of steps to save the example and actually have it run in the browser?
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.
https://plnkr.co/edit/2y9JEOgSZLpO4bE7
I estimate the vast majority of "web projects" begin with npm installing something of some sort, yes. React is dominating the web development space (judging from the average "popular web stack 2025" search result), and it and a significant portion of the competing platforms start with installing some dependencies with npm (or yarn, or what have you). Especially projects that compete in the same space as Lit.
That isn't a criticism of projects that don't use npm, and it doesn't make them less valid, but it makes sense for the documentation to match the average developer's experience.
Obviously this wouldn't be suitable for (serious) production deployments, but it is a super accessible way to easily get started anywhere.
The browser supports module imports. But your script must be of type ”module”: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
Not with paths like 'lit' that is used here.
Import map:
https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
The example does not use an importmap attribute.
Overall, the example does not seem like something that is supposed to run directly in the browser without some kind of intermediate step.
That is why I asked what the minimal number of steps would be to download the example and have it work locally.
The maintainers and then the docs assume that everyone is using typescript