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
lit-html is enough, tbh
Lit: a library for building fast, lightweight web components
171–180 of 180 posts
Re: Lit: a library for building fast, lightweight web components
#172Earlier quoted context omitted.
> You have a very large axe to grind against web components and Lit Yes, yes I do. Because Web Components are almost 15 years now, and they still struggle with the most basic of things. How's that abandoned roadmap going? https://w3c.github.io/webcomponents-cg/2022.html > No, there are no custom JavaScript rules. Templates have some rules. That is "here are regular JS functions. However, you cannot use them as regula…
Ha this guy again, I recognize you too. I also don't understand your obsession with trolling on Lit and Web Components. You keep coming with the same arguments. And always very emotional. I get the feeling that it is something personal that you have against Lit / Web Components. And you're clearly a hater, and haters are gonna hate regardless of whatever happens. I do wonder, why are you on this crusade? Are you afra…
By what I understood, I would expect him to use web components a lot even though he dislikes a few things, otherwise that would be really weird and a waste of life time.
Re: Lit: a library for building fast, lightweight web components
#173I'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 somethin…
The maintainers and then the docs assume that everyone is using typescript
Re: Lit: a library for building fast, lightweight web components
#174Earlier quoted context omitted.
Perhaps I care about the direction in which the web is pushed by a very small number of people incapable of seeing beyond their solutions and incapable of admitting their own mistakes.
At no point have I ever gotten the impression that you are even remotely open to seeing other points of view so it’s a bit hard to take the moralistic tone of the brave defender of the web part seriously. I think you just want to yell at people.
Web Components have been in development for 14 years. If you think this is the first discussion of web components, you clearly haven't been paying attention.
All there is to say was said years ago. Today it should be enough to know that, for example, "form associated custom elements cannot be a submit button" issue was opened 6 years ago, in 2019: https://github.com/WICG/webcomponents/issues/814
In 2022 web component group report mentions it in passing: https://w3c.github.io/webcomponents-cg/2022.html#concerns-10
That issue is still open.
Or that web components breaking ARIA was known at least 2019: https://x.com/sarahmei/status/1198069119897047041 and this will not be fixed for another 4-5 years at least.
Imagine if any web framework had issues like that.
That doesn't even begin to cover things like "now every useful spec has to be acutely aware of Shadow DOM shenanigans" which delayed any number of specs like scoped CSS etc
Re: Lit: a library for building fast, lightweight web components
#175Earlier quoted context omitted.
At no point have I ever gotten the impression that you are even remotely open to seeing other points of view so it’s a bit hard to take the moralistic tone of the brave defender of the web part seriously. I think you just want to yell at people.
Web Components have been in development for 14 years. If you think this is the first discussion of web components, you clearly haven't been paying attention. All there is to say was said years ago. Today it should be enough to know that, for example, "form associated custom elements cannot be a submit button" issue was opened 6 years ago, in 2019: https://github.com/WICG/webcomponents/issues/814 In 2022 web component…
It’s just like an LLM stuck on a loop. It’s just years and years of making the exact same comments, not responding to any counter arguments and then demanding that people take you seriously.
Re: Lit: a library for building fast, lightweight web components
#176I 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
Re: Lit: a library for building fast, lightweight web components
#177I 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.)
It's 2025
Re: Lit: a library for building fast, lightweight web components
#178My 3d bin packer is written with lit and F#
Re: Lit: a library for building fast, lightweight web components
#179I 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 f…
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.
Re: Lit: a library for building fast, lightweight web components
#180So 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.