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

31–40 of 180 posts

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

#31

Post by epolanski »

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.

I can think about few other ways, such as using higher order functions/classes, using getOwnPropertyDescriptor or doing stuff at construction.

> As mentioned by skrebbel, decorators are optional

This is not a pro, it's a con. The more ways there are to achieve the same result the more inconsistent projects become IRL.

Also, do you really want to metaprogram at all? What's the huge benefit of that approach?

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

#32

Post by mariusor »

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

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

#33

Post by nisbet »

jfagnani wrote: post #22
akmittal wrote: post #16

Earlier quoted context omitted.

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

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

About CSS Modules – Are you referring to this? https://caniuse.com/mdn-javascript_statements_import_import_...

Seems like this feature was removed from Chrome.

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

#34

Post by mariusor »

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…

As a third party I can't help but notice that the only one doing the "shitting" here, is you.

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

#35

Post by kubb »

pmg101 wrote: post #29
kubb wrote: post #15

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.

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.

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

#36

Post by pmanu »

kubb wrote: post #15

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.

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

#37

Post by jfagnani »

epolanski wrote: post #31
jfagnani wrote: post #11

Earlier quoted context omitted.

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. I can think about few other ways, such as using higher order functions/classes, using getOwnPropertyDescriptor or doing stuff at construction. > As mentioned by skrebbel, decorators are optional This is not a pro, it's a con. The more ways there are to achieve the same result the more inconsistent projects become IRL. Also, do you really want to me…

There really is no way to metaprogram against class fields except with decorators.

Class fields aren't on the prototype. They're essentially Object.defineProperty() calls that occur right after the super() call of a constructor. You can't get at them at all from the class declaration.

I know more than one way to do something is sometimes a downside, but we have a large audience an a huge portion of it wants to use TypeScript and declarators, and another huge portion of it wants to use vanilla JavaScript. We factored things to give the best DX we could to each group with relatively little cost to us.

As for why metaprogramming, we want a component to update when it's state is changed. Like plain web components, Lit uses classes.

So here, we want setting `el.name` to cause the component to re-render:

    class MyElement extends LitElement {

      name = 'World';

      render() {
        return html`Hello ${this.name}`
      }
    }
We do that by replacing `name` with a getter/setter pair where the setter schedules an update of the instance. Without decorators, there's no way to see that `name` even exists, much less replace it.

Decorators actually do the replacement for us, we just have to build the thing to replace it with:

    class MyElement extends LitElement {

      @property() accessor name = 'World';

      render() {
        return html`Hello ${this.name}`
      }
    }

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

#38

Post by jfagnani »

nisbet wrote: post #33
jfagnani wrote: post #22

Earlier quoted context omitted.

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

About CSS Modules – Are you referring to this? https://caniuse.com/mdn-javascript_statements_import_import_... Seems like this feature was removed from Chrome.

Import assertions were replaced with import attributes (`assert` replaced by `with`).

See https://caniuse.com/mdn-javascript_statements_import_import_...

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

#39

Post by iammrpayments »

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

Are properties reactive?

Can I reassign name in the example by using document.querySelector?

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

#40

Post by mkleczek »

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

Thanks for your great work.

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

Post reply on HN