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
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.
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)?
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 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.
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.
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.
"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
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.
>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.)
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.
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.
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.
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.
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.
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 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
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.
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:
Muromec|6 months ago
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.
compacct27|6 months ago
kubb|6 months ago
soupy-soup|5 months ago
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.
andrewingram|5 months ago
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.
gitaarik|6 months ago
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|6 months ago
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.
jfagnani|6 months ago
Not sure why Lit showed up on the front page tonight :)
polyrand|6 months ago
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.
jfagnani|6 months ago
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
dtagames|6 months ago
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...
krikou|6 months ago
Sometimes, I am wondering why it is not more widely used ...
preommr|6 months ago
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.
akmittal|6 months ago
dan353hehe|6 months ago
https://news.ycombinator.com/item?id=45107388
I assume someone else looked it up and liked it enough to submit it.
iammrpayments|6 months ago
Can I reassign name in the example by using document.querySelector?
gitaarik|6 months ago
mkleczek|6 months ago
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)?
edweis|6 months ago
jcbrand|6 months ago
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).
o_m|6 months ago
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.
jfagnani|6 months ago
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.
mariusor|6 months ago
rs186|6 months ago
kavaruka|6 months ago
selectnull|6 months ago
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.
kubb|6 months ago
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|6 months ago
pmanu|6 months ago
iamsaitam|6 months ago
mdhb|6 months ago
CharlieDigital|6 months ago
mdhb|6 months ago
https://lit.dev/articles/lit-cheat-sheet/
sibit|6 months ago
mulhoon|6 months ago
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...
rs186|6 months ago
* 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.
Ruphin|6 months ago
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.
Muromec|6 months ago
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.
tkubacki|6 months ago
zacian|6 months ago
unknown|6 months ago
[deleted]
paradox460|6 months ago
ameliaquining|6 months ago
ricny046|6 months ago
Really love the abstraction that makes web components easy to use.
gxonatano|5 months ago
whs|6 months ago
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
megaman821|6 months ago
krikou|6 months ago
- https://github.com/vaadin/web-components
- https://github.com/material-components/material-web (very, very sadly killed by google management)
jonjlee|6 months ago
JohnMunsch|5 months ago
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.
wildpeaks|6 months ago
Typescript can even add Intellisense to "customElements.get" by augmenting CustomElementRegistry: https://gist.github.com/cecilemuller/72fbb3bc3a77d82c8a969cd...
epolanski|6 months ago
jfagnani|6 months ago
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.
skrebbel|6 months ago
The Lit authors tried hard to use vanilla JS everywhere they could, and it shows.
mdhb|6 months ago
hliyan|6 months ago
gitaarik|6 months ago
BenoitEssiambre|6 months ago
https://benoitessiambre.com/vanilla.html
moxvallix|6 months ago
My editor: https://needcoolershoes.com
drudolph914|5 months ago
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
mock-possum|6 months ago
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.
Communitivity|5 months ago
ulrischa|6 months ago
hussi|5 months ago
brazukadev|5 months ago
troupo|6 months ago
- 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#...
jfagnani|6 months ago
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.
afavour|6 months ago
reverseblade2|5 months ago
https://3dpack.ing
andrewstuart|6 months ago
Typescript has JSX built in so when "I made my own framework" I just used that.
romshark|6 months ago
Arubis|6 months ago
hk1337|6 months ago
defraudbah|6 months ago
TekMol|6 months ago
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?
Ruphin|6 months ago
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.
fmbb|6 months ago
brazukadev|5 months ago