7 ms·
Pretty much 100% of my greenfield frontend development is using lit-html, and has been since they originally launched it. Note: I don't use Lit/LitElement, I j
by claytongulick 3y ago
Pretty much 100% of my greenfield frontend development is using lit-html, and has been since they originally launched it.
Note: I don't use Lit/LitElement, I just use lit-html with vanilla web components.
I don't find a lot of value in the more complex "component" model/wrapper around native web components, though YMMV.
My components are very simple native light-dom web components that have a render() method that calls lit-html render. For reactivity, I just use class properties. On a setter that needs to mutate the dom, I just call render manually.
It's not really any extra lines of code at the end of the day, and it gives me full control over the lifecycle and render cycle of my components. It's also super easy to debug.
I've used different routers over the years, currently I'm using Vaadin, but I've used Ionic's and others. I may try out the new router that's in Lit/labs.
I'm very satisfied with it. No framework churn, no complex builds, easy debugging, lighting fast performance, minuscule js downloads, easy authoring and vscode has magical tooling support.
lit-html is one of my all time favorite pieces of tech.
- niedzielski 3y agoThat's interesting. I guess you miss out on batched rendering--if all your setters re-render, you might trigger multiple renders for a single logical update. If you're using signals, maybe you don't care as much about batched rendering. I would probably miss CSS selectors too.
- claytongulick 3y agoLit-html is so fast and cheap, batched rendering isn't really useful. I will sometimes do a little trickery in my setters to prevent pointless server round-trips though. The general rule of thumb with lit-html is "meh, just render. It's just a template clone, and pretty much free". There's no need to miss css selectors, they work just fine. That's the advantage of avoiding shadow dom.