Live data from Hacker News

Lit: a library for building fast, lightweight web components

lit.dev

81–90 of 180 posts

Re: Lit: a library for building fast, lightweight web components

#81
post #30

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.

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 all over your code plus the plumbing to add it to the DOM.

Yeah, it does require some more boilerplate. I abstract some of it JSX, and with LLMs writing boilerplate code isn't that annoying anymore.

Re: Lit: a library for building fast, lightweight web components

#82
post #5

Hands down the most underrated front end library out there. It powers some major projects like ChromeOS, Chrome Devtools, I think most of Firefox’s UI, Photoshop for the web, MDN etc.

Also Reddit! Any other surprise sites?

I think lit is great but the reddit site is the perfect example of why the framework you chose is not the reason your site is slow.

I think lit should distance itself from that mess if possible

Re: Lit: a library for building fast, lightweight web components

#83
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

Re: Lit: a library for building fast, lightweight web components

#84
post #51
post #19

Earlier 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…

Web Components is a pretty niche technology and as such it really appeals to some people, and it doesn't appeal to others, and that's okay. You don't have to like it, it isn't meant to be a good fit for everyone. But for some people it might fit really well with their requirements, and they probably have legitimate reasons for that. If I understand correctly, your criticism is that the people for whom Web Components…

> pretty niche technology

The main problem is that for a "niche technology" it sure infects too many standards, requires an insane amount of new standards and makes supporting things needlessly complicated.

A few links here: https://news.ycombinator.com/item?id=45114450

There are some good parts in the ~30 standards they require, but instead of just the good parts you get the whole horse, and the cart it's attached to, and the cargo in the cart.

> your criticism is that the people for whom Web Components is a good fit are publicly discussing the reasons why they prefer it over other solutions?

It's not.

Re: Lit: a library for building fast, lightweight web components

#85
post #63
post #53

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 somethin…

I guess for most people the standard is to install things from NPM which explains the format of the documentation. If you want to do something completely raw, you can replace 'lit' with something like this: https://unpkg.com/lit@3.3.1/index.js?module You can even dynamically import that in the a running browser console and use it directly on any webpage.

    I guess for most people the standard is to install things from NPM
"things" that run in the browser?

    replace 'lit' with something like this:
    https://unpkg.com/lit@3.3.1/index.js?module
Thanks, that works:

https://plnkr.co/edit/2y9JEOgSZLpO4bE7

Re: Lit: a library for building fast, lightweight web components

#86
post #55
post #47

Working with a large Vue 3 project and wanting to share some of our components as re-usable web components for other sites to embed... What would be the benefit of rebuilding these components in Lit over using Vue to build them? https://vuejs.org/guide/extras/web-components#building-custo...

I 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 lea…

Thanks for the in-depth response, much appreciated

Re: Lit: a library for building fast, lightweight web components

#87
post #80
post #47

Working with a large Vue 3 project and wanting to share some of our components as re-usable web components for other sites to embed... What would be the benefit of rebuilding these components in Lit over using Vue to build them? https://vuejs.org/guide/extras/web-components#building-custo...

I have used both. Personally I prefer Vue a bit more. * Built-in state management especially as in v3 (ref/reactive) is super powerful, and you can test the setup function logic by itself without any dependency on DOM which is convenient. By comparison, reactivity in Lit is basic (by design), and mostly work on the widget level -- if something changes, you need to trigger the update process of the widget. * The lifec…

Thanks for this. I think you're right -> "focus on shipping features instead of changing your tech stack"

Re: Lit: a library for building fast, lightweight web components

#88
post #79
post #68

Earlier quoted context omitted.

React is 12 years old. That’s a significant chunk of anyone’s life.

Web components are 14 years old, and still have the most basic issues and problems that even a 6-month-year-old framework would ashamed to have.

I await your in depth critique on the front page.

Re: Lit: a library for building fast, lightweight web components

#89
post #41

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 f…

Shadow DOM is optional in Lit - you can just disable it on a per-component basis.

Re: Lit: a library for building fast, lightweight web components

#90
post #74

Earlier quoted context omitted.

Lit has always been designed partially as a prototype for where web component standards could go in the future. That's a big reason Lit is fairly conservative and un-opinionated. It doesn't try to undo or paper-over any of the DOM APIs, but add to them instead. There is a proposal in TC39 for native signals, which I think would make a huge dent towards library-less reactivity. I'm also working on a proposal for nativ…

> Lit has always been designed partially as a prototype for where web component standards could go in the future. > There is a proposal in TC39 for native signals, Which originated (or the modern versions of signals originated) in Solid, not in Lit. Let me quote the readme: https://github.com/tc39/proposal-signals --- start quote --- The current draft is based on design input from the authors/maintainers of Angular,…

They never claimed that signals originated in lit. They were just responding to the comment that there's no native reactivity in web components...
Post reply on HN