27 ms·

Lit: a library for building fast, lightweight web components

280 points by merqurio 1y ago

drudolph914 1y ago
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 https://www.youtube.com/watch?v=uCHZJy2n8Qs
reverseblade2 1y ago
My 3d bin packer is written with lit and F# https://3dpack.ing https://3dpack.ing
gxonatano 1y ago
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.
zacian 1y ago
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.
- deleted 1y ago
  [deleted]
epolanski 1y ago
Great project but I can't stand syntax such as decorators.
- mdhb 1y ago
  They are optional for what it’s worth. They are also landing in standard JS soon.
  - Klaster_1 1y ago
    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 https://bugzilla.mozilla.org/show_bug.cgi?id=1781212 [1] https://issues.chromium.org/issues/42202709 https://issues.chromium.org/issues/42202709
  - evilduck 1y ago
    I wouldn't hold my breath. Decorators landing in standard JS "soon" has been the claim for about a decade running.
- skrebbel 1y ago
  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.
- jfagnani 1y ago
  Decorators are the only way to metaprogram over class fields in JS. Otherwise they're not even detectable on the prototype. We use them to make fields reactive mostly, and I love how declarative they are. But we use them sparingly. I 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-properties-in-a-static-properties-class-field 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.
mdhb 1y ago
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.
- CharlieDigital 1y ago
  Also Reddit! Any other surprise sites?
  - shoeb00m 1y ago
    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
    - CharlieDigital 1y ago
      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.
mdhb 1y ago
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/ https://lit.dev/articles/lit-cheat-sheet/
kavaruka 1y ago
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.
- selectnull 1y ago
  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.
  - brazukadev 1y ago
    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.
    - selectnull 1y ago
      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.
troupo 1y ago
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 <button @click="" .disabled="" /> - Custom Javascript rules // valid JS, invalid lit const tagName= "a"; `<${tagName} href="">Some link</${tagName}>` - Custom rules for special functions. // 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> - Context https://lit.dev/docs/data/context/ https://lit.dev/docs/data/context/ - Experimental compiler: https://github.com/lit/lit/tree/main/packages/labs/compiler#readme https://github.com/lit/lit/tree/main/packages/labs/compiler#...
- jfagnani 1y ago
  You have a very large axe to grind against web components and Lit, and you show up just about everywhere to make the same comments, but I'll play along anyway: Yes, Lit templates give some special meaning to attribute names with a few 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.
  - troupo 1y ago
    > 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 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.
jfagnani 1y ago
Lit maintainer here. I should be going to bed, but I'll answer any questions if people have any! Not sure why Lit showed up on the front page tonight :)
- akmittal 1y ago
  Curious which web platform features are missing that are preventing Web components to complete with React(for application development not widgets)?
  - jfagnani 1y ago
    I think web components already compete extremely well for application development, and you see very complex apps built with Lit out there: Photoshop, Firefox, Chrome OS, Chrome DevTools. Apps are well served because they have more control 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
    - nisbet 1y ago
      About CSS Modules – Are you referring to this? https://caniuse.com/mdn-javascript_statements_import_import_assertions_type_css https://caniuse.com/mdn-javascript_statements_import_import_... Seems like this feature was removed from Chrome.
      - jfagnani 1y ago
        Import assertions were replaced with import attributes (`assert` replaced by `with`). See https://caniuse.com/mdn-javascript_statements_import_import_attributes_type_css https://caniuse.com/mdn-javascript_statements_import_import_...
kubb 1y ago
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.
- pmg101 1y ago
  Which old browser capabilities are you referring to? Could you say more, or link to more details?
  - kubb 1y ago
    No shadow DOM, no web components, no template strings, etc.
    - troupo 1y ago
      > 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
      - azangru 1y ago
        > the current advise for web components is to avoid Shadow DOM (almost like the plague) Could you provide the source for this advice?
        jfagnani 1y ago
        It's wrong - both that it's general "current advice", and the advice itself when it does pop up. Yes, there are some people who say to build web components without shadow DOM, but I'm convinced they're only 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.
tkubacki 1y ago
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
ricny046 1y ago
I love Lit! I have been using it to develop a in-app widget for product updates here: https://supanotice.com 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.
o_m 1y ago
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.
- mariusor 1y ago
  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.
  - o_m 1y ago
    Yeah, it does require some more boilerplate. I abstract some of it JSX, and with LLMs writing boilerplate code isn't that annoying anymore.
- jfagnani 1y ago
  The great thing about web components is that you can build them however works best for you. Native web component APIs don't have the DX that many people expect though, because they are so low-level. Lit provides just that declarative reactivity on top.
- rs186 1y ago
  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.
  - fkyoureadthedoc 1y ago
    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.
Muromec 1y ago
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.
- soupy-soup 1y ago
  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.
- kubb 1y ago
  Shadow DOM is optional in Lit - you can just disable it on a per-component basis.
  - sauercrowd 1y ago
    causes a bunch of things to no longer work though - slots, style encapsulation, ...
    - kubb 1y ago
      If you need style encapsulation, use the Shadow DOM. Slots still work IIRC.
      - jfagnani 1y ago
        Slots definitely don't work without shadow DOM and there's really no way to make them work. It's the biggest problem with turning shadow DOM off.
mulhoon 1y ago
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-custom-elements-with-vue https://vuejs.org/guide/extras/web-components#building-custo...
- Ruphin 1y ago
  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.
  - rs186 1y ago
    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.
defraudbah 1y ago
thank you, I am not brining inheritance and decorators back to the web
andrewstuart 1y ago
I looked at lit but chose JSX. Typescript has JSX built in so when "I made my own framework" I just used that.
hk1337 1y ago
“You got Lit up!”
TekMol 1y ago
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?
- fmbb 1y ago
  The browser supports module imports. But your script must be of type ”module”: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
  - TekMol 1y ago
    Not with paths like 'lit' that is used here.
    - uallo 1y ago
      Import map: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script/type/importmap https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
      - TekMol 1y ago
        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.
moxvallix 1y ago
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 https://needcoolershoes.com
sibit 1y ago
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.
gitaarik 1y ago
I made a state management lib for Lit, that's just as lightweight (258 lines) and intuitive: https://github.com/gitaarik/lit-state 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.
- Ruphin 1y ago
  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 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.
whs 1y ago
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
- jonjlee 1y ago
  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.
  - agos 1y ago
    these are cool but are CSS only, there is no interactivity.
    - paradox460 1y ago
      Also building a component library atop tailwind feels so disgustingly wrong
- megaman821 1y ago
  Yes, take a look at https://webawesome.com/ https://webawesome.com/
- krikou 1y ago
  In addition, to what is already posted, you also have: - https://github.com/vaadin/web-components https://github.com/vaadin/web-components - https://github.com/material-components/material-web https://github.com/material-components/material-web (very, very sadly killed by google management)
Arubis 1y ago
(Formerly lit-element)
BenoitEssiambre 1y ago
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 https://benoitessiambre.com/vanilla.html
romshark 1y ago
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.
jcbrand 1y ago
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 https://github.com/conversejs/converse.js And you can demo it here: https://chat.conversejs.org/ https://chat.conversejs.org/ You'll need an XMPP account (see https://providers.xmpp.net/ https://providers.xmpp.net/ for possible providers).
paradox460 1y ago
I used lit for a few small components on my blog, https://pdx.su 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.
- ameliaquining 1y ago
  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.)
  - paradox460 1y ago
    It's 2025
  - rictic 1y ago
    Lit 2 to Lit 3 was really minimal: https://lit.dev/docs/releases/upgrade/ 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.
mock-possum 1y ago
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.
wildpeaks 1y ago
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/72fbb3bc3a77d82c8a969cdfaa06508c https://gist.github.com/cecilemuller/72fbb3bc3a77d82c8a969cd...
ulrischa 1y ago
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
- hussi 1y ago
  I thought that the implementation of web components was purposefully low level and that a library on top was the way to go.
- brazukadev 1y ago
  lit-html is enough, tbh
JohnMunsch 1y ago
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.
Communitivity 1y ago
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.

280 points by merqurio 1y ago

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 https://www.youtube.com/watch?v=uCHZJy2n8Qs

reverseblade2 1y ago

My 3d bin packer is written with lit and F# https://3dpack.ing https://3dpack.ing

gxonatano 1y ago

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.

zacian 1y ago

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.

deleted 1y ago
[deleted]

epolanski 1y ago

Great project but I can't stand syntax such as decorators.

mdhb 1y ago
They are optional for what it’s worth. They are also landing in standard JS soon.
- Klaster_1 1y ago
  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 https://bugzilla.mozilla.org/show_bug.cgi?id=1781212 [1] https://issues.chromium.org/issues/42202709 https://issues.chromium.org/issues/42202709
- evilduck 1y ago
  I wouldn't hold my breath. Decorators landing in standard JS "soon" has been the claim for about a decade running.
skrebbel 1y ago
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.
jfagnani 1y ago
Decorators are the only way to metaprogram over class fields in JS. Otherwise they're not even detectable on the prototype. We use them to make fields reactive mostly, and I love how declarative they are. But we use them sparingly. I 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-properties-in-a-static-properties-class-field 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.

mdhb 1y ago

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.

CharlieDigital 1y ago
Also Reddit! Any other surprise sites?
- shoeb00m 1y ago
  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
  - CharlieDigital 1y ago
    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.

mdhb 1y ago

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/ https://lit.dev/articles/lit-cheat-sheet/

kavaruka 1y ago

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.

selectnull 1y ago
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.
- brazukadev 1y ago
  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.
  - selectnull 1y ago
    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.

troupo 1y ago

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 <button @click="" .disabled="" /> - Custom Javascript rules // valid JS, invalid lit const tagName= "a"; `<${tagName} href="">Some link</${tagName}>` - Custom rules for special functions. // 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> - Context https://lit.dev/docs/data/context/ https://lit.dev/docs/data/context/ - Experimental compiler: https://github.com/lit/lit/tree/main/packages/labs/compiler#readme https://github.com/lit/lit/tree/main/packages/labs/compiler#...

jfagnani 1y ago
You have a very large axe to grind against web components and Lit, and you show up just about everywhere to make the same comments, but I'll play along anyway: Yes, Lit templates give some special meaning to attribute names with a few 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.
- troupo 1y ago
  > 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 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.

jfagnani 1y ago

Lit maintainer here. I should be going to bed, but I'll answer any questions if people have any! Not sure why Lit showed up on the front page tonight :)

akmittal 1y ago
Curious which web platform features are missing that are preventing Web components to complete with React(for application development not widgets)?
- jfagnani 1y ago
  I think web components already compete extremely well for application development, and you see very complex apps built with Lit out there: Photoshop, Firefox, Chrome OS, Chrome DevTools. Apps are well served because they have more control 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
  - nisbet 1y ago
    About CSS Modules – Are you referring to this? https://caniuse.com/mdn-javascript_statements_import_import_assertions_type_css https://caniuse.com/mdn-javascript_statements_import_import_... Seems like this feature was removed from Chrome.
    - jfagnani 1y ago
      Import assertions were replaced with import attributes (`assert` replaced by `with`). See https://caniuse.com/mdn-javascript_statements_import_import_attributes_type_css https://caniuse.com/mdn-javascript_statements_import_import_...

kubb 1y ago

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.

pmg101 1y ago
Which old browser capabilities are you referring to? Could you say more, or link to more details?
- kubb 1y ago
  No shadow DOM, no web components, no template strings, etc.
  - troupo 1y ago
    > 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
    - azangru 1y ago
      > the current advise for web components is to avoid Shadow DOM (almost like the plague) Could you provide the source for this advice?
      - jfagnani 1y ago
        It's wrong - both that it's general "current advice", and the advice itself when it does pop up. Yes, there are some people who say to build web components without shadow DOM, but I'm convinced they're only 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.

tkubacki 1y ago

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

ricny046 1y ago

I love Lit! I have been using it to develop a in-app widget for product updates here: https://supanotice.com 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.

o_m 1y ago

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.

mariusor 1y ago
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.
- o_m 1y ago
  Yeah, it does require some more boilerplate. I abstract some of it JSX, and with LLMs writing boilerplate code isn't that annoying anymore.
jfagnani 1y ago
The great thing about web components is that you can build them however works best for you. Native web component APIs don't have the DX that many people expect though, because they are so low-level. Lit provides just that declarative reactivity on top.
rs186 1y ago
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.
- fkyoureadthedoc 1y ago
  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.

Muromec 1y ago

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.

soupy-soup 1y ago
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.
kubb 1y ago
Shadow DOM is optional in Lit - you can just disable it on a per-component basis.
- sauercrowd 1y ago
  causes a bunch of things to no longer work though - slots, style encapsulation, ...
  - kubb 1y ago
    If you need style encapsulation, use the Shadow DOM. Slots still work IIRC.
    - jfagnani 1y ago
      Slots definitely don't work without shadow DOM and there's really no way to make them work. It's the biggest problem with turning shadow DOM off.

mulhoon 1y ago

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-custom-elements-with-vue https://vuejs.org/guide/extras/web-components#building-custo...

Ruphin 1y ago
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.
- rs186 1y ago
  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.

defraudbah 1y ago

thank you, I am not brining inheritance and decorators back to the web

andrewstuart 1y ago

I looked at lit but chose JSX. Typescript has JSX built in so when "I made my own framework" I just used that.

hk1337 1y ago

“You got Lit up!”

TekMol 1y ago

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?

fmbb 1y ago
The browser supports module imports. But your script must be of type ”module”: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/import https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...
- TekMol 1y ago
  Not with paths like 'lit' that is used here.
  - uallo 1y ago
    Import map: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/script/type/importmap https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
    - TekMol 1y ago
      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.

moxvallix 1y ago

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 https://needcoolershoes.com

sibit 1y ago

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.

gitaarik 1y ago

I made a state management lib for Lit, that's just as lightweight (258 lines) and intuitive: https://github.com/gitaarik/lit-state 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.

Ruphin 1y ago
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 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.

whs 1y ago

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

jonjlee 1y ago
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.
- agos 1y ago
  these are cool but are CSS only, there is no interactivity.
  - paradox460 1y ago
    Also building a component library atop tailwind feels so disgustingly wrong
megaman821 1y ago
Yes, take a look at https://webawesome.com/ https://webawesome.com/
krikou 1y ago
In addition, to what is already posted, you also have: - https://github.com/vaadin/web-components https://github.com/vaadin/web-components - https://github.com/material-components/material-web https://github.com/material-components/material-web (very, very sadly killed by google management)

Arubis 1y ago

(Formerly lit-element)

BenoitEssiambre 1y ago

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 https://benoitessiambre.com/vanilla.html

romshark 1y ago

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.

jcbrand 1y ago

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 https://github.com/conversejs/converse.js And you can demo it here: https://chat.conversejs.org/ https://chat.conversejs.org/ You'll need an XMPP account (see https://providers.xmpp.net/ https://providers.xmpp.net/ for possible providers).

paradox460 1y ago

I used lit for a few small components on my blog, https://pdx.su 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.

ameliaquining 1y ago
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.)
- paradox460 1y ago
  It's 2025
- rictic 1y ago
  Lit 2 to Lit 3 was really minimal: https://lit.dev/docs/releases/upgrade/ 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.

mock-possum 1y ago

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.

wildpeaks 1y ago

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/72fbb3bc3a77d82c8a969cdfaa06508c https://gist.github.com/cecilemuller/72fbb3bc3a77d82c8a969cd...

ulrischa 1y ago

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

hussi 1y ago
I thought that the implementation of web components was purposefully low level and that a library on top was the way to go.
brazukadev 1y ago
lit-html is enough, tbh

JohnMunsch 1y ago

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.

Communitivity 1y ago

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.