3 ms·
> 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
by CharlesW 1y ago
> 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!
- troupo 1y ago> 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.
- skrebbel 1y agoAnd 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).
- troupo 1y ago> 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.
- skrebbel 1y agoCan 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 :-)
- troupo 1y agoIt'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 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
- insin 1y agoI 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.