Live data from Hacker News

Lit: a library for building fast, lightweight web components

lit.dev

51–60 of 180 posts

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

#51
post #19

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…

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 is a good fit are publicly discussing the reasons why they prefer it over other solutions?

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

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

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

#54
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.

My editor: https://needcoolershoes.com

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

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

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

#56
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…

The browser supports module imports. But your script must be of type ”module”: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

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

#57
post #56
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…

The browser supports module imports. But your script must be of type ”module”: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Not with paths like 'lit' that is used here.

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

#58
post #57
post #56

Earlier quoted context omitted.

The browser supports module imports. But your script must be of type ”module”: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Not with paths like 'lit' that is used here.

Import map:

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

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

#59
post #58
post #57

Earlier quoted context omitted.

Not with paths like 'lit' that is used here.

Import map: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...

The example does not use an importmap attribute.

Overall, the example does not seem like something that is supposed to run directly in the browser without some kind of intermediate step.

That is why I asked what the minimal number of steps would be to download the example and have it work locally.

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

#60
post #36
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…

I thankfully migrated or left all Aurelia projects, but every time someone mentions it, I remember new horror stories.

Its .html temples were shipped unmodified directly to the client. Except they weren't actually html, and sometimes the browser would try to clean them up, breaking the template.

Reactivity was achieved through all kinds of weird mechanisms (eg monkey-patching arrays to watch for mutations). It would frequently resort to polling on every tick or break completely.

DI used TypeScripts experimental decorators, even long after it was clear that it would never become stable.

On the other hand, templates weren't type checked.

Post reply on HN