Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Lit: a library for building fast, lightweight web components

lit.dev

Post reply on HN
Print view View original

71–80 of 180 posts

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

#71

Post by gitaarik »

I made a state management lib for Lit, that's just as lightweight (258 lines) and intuitive:

https://github.com/gitaarik/lit-state

I've used it extensively myself, for creating complex web apps with many (nested) components interacting with each other.

I don't understand why Lit hasn't gained more popularity, because for me it is basically React, but then more browser-native, much less boiler plate, and much faster rendering. There are some things you have to get used to, but when you do it doesn't limit you in any way.

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

#73

Post by brazukadev »

jfagnani wrote: post #11
epolanski wrote: post #3

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

Decorators are the only way to metaprogram over class fields in JS. Otherwise they're not even detectable on the prototype. We use them to make fields reactive mostly, and I love how declarative they are. But we use them sparingly. I personally don't love how some libraries try to put a lot of things into decorators that could have been standard class features, like a static field or a method. edit: As mentioned by s…

> Decorators are the only way to metaprogram over class fields in JS.

No, they are not. Decorators don't even exist in JavaScript. Stop assuming typescript is Javascript or even worse, that everybody is on board.

> There's a switch that will change everything on the site from JS to TS globally.

Lol.

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

#74

Post by troupo »

jfagnani wrote: post #25
preommr wrote: post #18

Earlier quoted context omitted.

Any whispers of something like lit being made part of the webcomponents standard? Web components are nice because they're browser-native, but they don't support reactivity, which in hindisight, is a massive oversight, issue, whatever you want to call it - it's hindered adoption. Lit is nice because there's a very straightforward progression from web components.

Lit has always been designed partially as a prototype for where web component standards could go in the future. That's a big reason Lit is fairly conservative and un-opinionated. It doesn't try to undo or paper-over any of the DOM APIs, but add to them instead. There is a proposal in TC39 for native signals, which I think would make a huge dent towards library-less reactivity. I'm also working on a proposal for 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, Bubble, Ember, FAST, MobX, Preact, Qwik, RxJS, Solid, Starbeam, Svelte, Vue, Wiz, and more…

-- end quote ---

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

#75

Post by troupo »

akmittal wrote: post #16
jfagnani wrote: post #14

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 :)

Curious which web platform features are missing that are preventing Web components to complete with React(for application development not widgets)?

You can start with the Web Components Community Report: https://w3c.github.io/webcomponents-cg/2022.html

Or with opinions like this: https://dev.to/ryansolid/web-components-are-not-the-future-4...

O if you want to go down the technical rabbit hole, you can search for all the issues people have with them, e.g.: https://x.com/Rich_Harris/status/1841467510194843982

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

#76

Post by rs186 »

Ruphin wrote: post #55
mulhoon wrote: 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…

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.

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

#77

Post by gitaarik »

troupo wrote: post #19
jfagnani wrote: post #13

Earlier quoted context omitted.

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

> 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 afraid that people are at some point gonna be persuaded by Lit / Web Components, and that you need to be there to prevent that from happening?

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

#78

Post by troupo »

kubb wrote: post #35
pmg101 wrote: post #29

Earlier quoted context omitted.

Which old browser capabilities are you referring to? Could you say more, or link to more details?

No shadow DOM, no web components, no template strings, etc.

> No shadow DOM

Funny you should say that when the current advise for web components is to avoid Shadow DOM (almost like the plague)

> no web components

As in?

> no template strings

Why would React need template strings? React is not the only framework that doesn't use template strings for anything (Vue, Solid, Svelte come immediately to mind). And it's hard to accuse those of being behind the times when Solid is literally the reason for the upcoming native signals proposal

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

#79

Post by troupo »

kubb wrote: post #68
iamsaitam wrote: post #48

Earlier quoted context omitted.

"React is designed for the old browser capabilities and is now staying around by inertia, not by inherent quality." this makes me feel old and I guess React is famous for supporting Internet Explorer /s

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

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

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

#80

Post by rs186 »

mulhoon wrote: 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 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.

Post reply on HN