Hacker News Reader

Comment by skrebbel | Hacker News Reader

Sure but this page is about not using a framework. Once you're on board with using a framework like Lit, you might as well use Preact or Svelte or a similarly lightweight framework. The "web component" angle adds no value if it's all internal to your app.

Lit is amazing though. It's fast, lean, and easy to learn. In fact, to my experience, the only things about it that are un-ergonomic, are due to the fact that it's built around web components. Lit without web components would be so much better (again, except if you're building something to be distributed to other programmers on any framework). It wouldn't have a single global registry of components, it wouldn't have that attribute mess, and I bet it'd not need a compiler at all (it doesn't need it now either, but is easier/nicer with it).

View on HN

The irony is: I wrote a bunch of small custom elements [0][1] that do one thing and I don't use Lit for that, because Lit is still overhead. The litte bit of boilerplate overhead of Web Components, I simply wrote by hand.

[0]: Table of contents element: https://github.com/cmaas/table-of-contents-element

[1]: SVG avatars (React-free fork of Boring Avatars): https://github.com/cmaas/playful-avatars

> Sure but this page is about not using a framework.

Fair enough, but the way I read TFA, it doesn't dissuade developers from using tiny convenience libraries that leverage native browser capabilities. Based on your pushback, it sounds like my perception that Lit is mostly a convenient base class for Web Components is very incorrect. I'll dig into that more, thanks!

> it sounds like my perception that Lit is mostly a convenient base class for Web Components is very incorrect.

It has custom syntax, custom directives that look like regular JS functions but cannot be used like regular functions, a custom compiler in the works etc. etc.

They will keep telling you it just a small library and very vanilla though.

And they're right! IMO Lit is a marvel of engineering. I think the goal they set themselves (make it easier to build an entire app out of web components) is silly, but given that goal, they hit a total homerun. It's fast, the compiler is very optional (not using it just means a bit more boilerplate around attributes etc - it's not like using React without a JSX compiler or something), lit-html is a genius alternative to virtual DOMs, etc. The custom html syntax, IMO, is super useful too (eg it lets you workaround The Attribute Mess by passing data straight to properties, as you would in any sane non-web-component framework). And it's a lot closer to regular HTML than eg React's custom HTML syntax (JSX).

> lit-html is a genius alternative to virtual DOMs, etc

It's a haphazard solution that they now fight against with "directives" and even a custom compiler "for when initial render needs to be fast". It's not bad, but it's far from genius. And honestly, the only reason it works is that browsers have spent ungodly amounts of time optimizing working with strings and making innerHtml fast.

Additionally, it's weird to ask for "close to html" in a 100% Javascript-driven library/framework.

As for "etc.", I don't even know what etc. stands for. lit is busy re-implementing all the things all other frameworks have had for years. Including signals, SSR etc.

Can you explain more about how they're "fighting against lit-html" with the directives? I'm curious what's the struggle here.

> Additionally, it's weird to ask for "close to html" in a 100% Javascript-driven library/framework.

Fair point. I don't personally really care about that either. I guess I just meant to be say that it's not all too custom :-)

It's not really a struggle, but when all you have is a string, how do you enforce certain rules and requirements?

E.g. classMap https://lit.dev/docs/templates/directives/#classmap

--- start quote ---

The classMap must be the only expression in the class attribute, but it can be combined with static values

--- end quote ---

So now you have to figure out which attribute this is called from, whether this particular call is allowed in this attribute etc.

So what they do is they parse (with regexes) their "close to HTML" code into a structure not dissimilar to React's, figure all this stuff out, reassemble actual HTML and dump it to the DOM

I do know what you specifically mean when you say that, but… _all_ libraries are leveraging native browser capabilities, even ones which implement a better component model than Web Components.

Reply on news.ycombinator.com