8 ms·
Lit 3.0
- teg4n_ 3y agoi really wish it didn’t rely on decorators so heavily.
- spankalee 3y agoWhy? We support a non-decorator API (the static properties block), but I don't think it's particularly ergonomic compared to decorators which allow us to declarative modify standard class fields. Decorators work better with type systems, which don't have to be taught about our bespoke property declaration convention, and they're coming natively to JS so they won't require compilers.
- teg4n_ 3y agoAdding decorators to JS is a mistake but thats just my opinion. I don’t like them because they make it more difficult for me to understand what is actually happening when you run the code that is decorated. I have to go and read the decorator source and then it’s some metaprogramming nonsense instead of something more straightforward. It’s very possible i’m just a curmudgeon but I still find it off putting and is one of the reasons i haven’t really experimented with lit more than vaguely paying attention to it.
- spankalee 3y agoMetaprogramming can be applied in ways that makes code hard to reason about, but that doesn't mean all metaprogramming is that way. Decorators, especially the newly standardized decorators, provide a structured for of metadata where the possible actions are limited. Decorators can basically only replace the decorated class member with another member of the same kind: replace an accessor, or a method. This should make things easier to reason about. The Lit @property() decorator for instance wraps the decorated setter with one that calls `this.requestUpdate()` - that's it. The alternative is writing all the boilerplat by hand, which most users don't want to do (but is possible) or the adhoc metaprogramming systems that are fairly popular now, and I think those are much harder to reason about.
- teg4n_ 3y agoI mean couldn’t lit have just exposed a method like this.setReactiveProperty that calls this.requestUpdate and sets the property? The need for decorators seems because the api was designed to use decorators not because they are particularly necessary for this sort of thing
- spankalee 3y agoThat wouldn't be interoperable. Lots of frameworks already have the ability to set properties on elements declaratively in templates. By using setters we work with their data binding system without hanging to teach them about Lit-specific APIs.
- teg4n_ 3y agook, that makes sense. thanks for the explanation
- zubairq 3y agoSo is Lit an attempt to simplify Web Components?
- tsp 3y agoI used Lit 2 in a complex client project once, which was tough to work on, not because of Lit, but because of Web Component composition. I would not choose Web Components for a new project with component composition again. The Shadow DOM makes many things harder than I was used to when building with a JavaScript library like React or Vue. For framework independent individual components (e.g. a video player component), Lit is excellent.
- hu3 3y agoedit: Their Launch Event is live now! https://www.youtube.com/watch?v=ri9FEl_hRTc https://www.youtube.com/watch?v=ri9FEl_hRTc Something that caught my attention is that, in their homepage (https://lit.dev https://lit.dev), the list of organizations using Lit actually specifies where it is being used in each organization and even provides some links. In other projects it's not rare to see just the organization logos.
- pier25 3y agoIn the live sream they mentioned Reddit is trying out lit with SSR. Would be awesome if they ditched their React monstrosity.
- blauditore 3y agoThey also have the Google logo there claiming it's used for "many projects" - but nothing linked. Google has several in-house-built web frameworks, so this is questionable.
- dchest 3y agoLit is made by Google.
- buttersbrian 3y agoNot directly right? LIT is based off of WIZ or something like that from google iirc? Maybe I'm wrong here.
- eyelidlessness 3y agoI haven’t used Lit, but I’ve had my eye on it for some time as a potential good fit for some project ideas. One of the things I like is that it seems to be strongly in the “use the platform” camp, while still adding clear value (and ecosystem, which IMO is a tough charge for anything in the space not named React). For a semver major release, this one seems compelling if mundane (that’s a good thing!). But that’s just my observation as a current spectator. Looking forward to reactions from actual Lit users.
- spankalee 3y agoMaintainer here. Mundane is a fine way to put it :) We intentionally tried to have no new features to the core, and will add them in 3.1, etc.
- Dudester230602 3y agoThis new version of the [x] looks great! x - hot JS library of the week, substitute with Angular/React/Vue/Shoelace/Vite/Lit/... depending on the year and month.
- spankalee 3y agoLit's been around, starting as lit-html and lit-element, since 2017. Chrome, Firefox, Photoshop, Reddit, and more are built with it, so it's definitely not a library of the week, it just has less hype than others.
- newlisp 3y agoIt's been around and never got traction cause the project keeps changing direction and how things are done.
- meiraleal 3y agoThat's the opposite of my impression using Lit for the past 6 months. A thriving community, well-maintained packages and libraries, old content most of the times works the same and it won't change after 3.0 release because the API didn't change. Besides that, the code keeps getting smaller so with a reduced interface it becomes easier to reason about. Now compare it to React, Angular and Vue: the 3 of them had a complete change of course at some point and lost a good amount of documentation and ecosystem while having to maintain both for some time. That never happened with Lit (although it seems to have being created by the same team that maintained Polymer).
- spankalee 3y agoLit has not really changed direction or how things are done. In the release presentation today the exact same code was shown that runs in lit-element, Lit 2 and Lit 3.
- ForkMeOnTinder 3y agoThis comment might have made sense 10 years ago. Nowadays JS frameworks are a tiny minority of release announcements on HN. https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=true&query=release&sort=byPopularity&type=story https://hn.algolia.com/?dateRange=pastMonth&page=0&prefix=tr...
- floxy 3y agoSome sort of web library, nothing to do with Lit Motors, the self-balancing motorcycle: https://hn.algolia.com/?q=lit+motors https://hn.algolia.com/?q=lit+motors https://www.litmotors.com/home https://www.litmotors.com/home
- pier25 3y agoA bit disappointed that Lit SSR is still considered experimental. Most frontend frameworks/libs are (understandbly) still in their boring client-side bubble but actual full stack solutions like Phoenix Liveviews or Laravel Livewire are so much more interesting IMO.
- spankalee 3y agoWe're working on it. It's a bigger challenge for us because part of the reason people use Lit is for interoperable components, so our SSR solution can't be a silo: it needs to integrate with other framework's SSR systems. That's why we're working on packages like @lit-labs/ssr-react and @lit-labs/nextjs. SSR is in Labs still because it's APIs may need to change to support those integrations.
- srameshc 3y agoIf you can give a solid SSR solution specifically built for Lit, it would still be good because many want a solution which is cloud provider agnostic and are willing to switch to whatever works anywhere.
- pier25 3y agoMakes sense. An alternative is using this solution but it doesn't inspire a lot of confidence for any serious project. https://github.com/popeindustries/lit https://github.com/popeindustries/lit
- Kerrick 3y agoI've been a front-end engineer for over a decade and I still struggle to understand the value of SSR as a feature of front-end frameworks. - Websites that care about SEO rarely need front-end frameworks. - Web apps that need front-end frameworks tend to be behind a login screen or used for creating documents rather than publishing them. - SSR strategies sometimes render loading states through `</html>` and then tack on additional JavaScript streamed at the end for fully-loaded state, removing any NoScript benefit you might hope to get.
- 3y ago
- satvikpendem 3y agoI'll preface with saying I'm not too familiar with the technology, but I don't really get web components, everything I've seen online says they're a bad API and abstraction. Does Lit fix those issues? Genuinely curious as I haven't used Lit or WC before, I've been mainly working with React. The Failed Promise of Web Components: https://news.ycombinator.com/item?id=24640151 https://news.ycombinator.com/item?id=24640151 Why I don't use web components: https://news.ycombinator.com/item?id=20232628 https://news.ycombinator.com/item?id=20232628
- mock-possum 3y agoWeb components are just custom html elements, with the option of an added shadowDOM. Oh, and slots. But that’s it. If you’ve got an interface component that you find yourself using over and over - like say a complicated multi select drop down type thing - maybe you just make it a custom element, define a custom class that controls it, and drop instances of it throughout your site, the same as you’d drop default <select>s.
- deleted 3y ago[deleted]
- yellow_lead 3y agoThe first link complains about databinding a bit. Not a lit expert, but this seems to help with that: > Lit’s expressive, declarative templates (utilizing JavaScript tagged template literals) make it easy to describe how a component should be rendered. > Reactive properties represent a component’s public API and/or internal state; your component automatically re-renders whenever a reactive property changes. Also, good question, I would like to see more discussion here vs. downvote without comment.
- deleted 3y ago[deleted]
- lbotos 3y agoAnyone have a "translate from vue to lit" guide? I admittedly haven't done any searching yet, but figured someone may have written one or have experiences switching.
- hu3 3y agoThis might help (select Lit and Vue): https://component-party.dev https://component-party.dev
- roblh 3y agoI like the idea of Lit a lot, but every time I’ve tried to use it, it feels kind of unclear what the intended way of using it actually is. Like, what an actual code base that uses it heavily would look like. All of their example code seems to have no context around it at all, so it’s really difficult to infer from that how to actually make anything useful, or even how to get started. I hope they sort that out at some point.
- mock-possum 3y agoHonestly you can organize it however you like, it’s just an easier way to define native web components. Picture angular, or vue, or react - only with native web components and the shadow dom, instead of a vdom. You can use whatever routing you like, use whataver state management you like. Lit just helps you make web components.
- antifa 3y ago"Do whatever you want" isn't a useful answer to "I don't know what to do with this."
- kaycebasques 3y agoWould a beefy sample app fill the gap? Something that demonstrates a complex real-world use case.
- spankalee 3y agoThere are lots of open-source design systems built with Lit. Shoelace is a popular component set that you might check out: https://github.com/shoelace-style/shoelace https://github.com/shoelace-style/shoelace There are many others... Would it help if we listed more open source projects on our site? Because of our focus on components and the fact that you really can use just about any libraries and scaffolding for apps, we don't really have an app starter kit, but it's something we've talked about.
- selectnull 3y agoFew years ago I started working on a project and didn't want any heavy framework. I used customElements and liked it. When the project grew enough, I found out about Lit and it was a clear winner for me. I've ported my custom elements to Lit with ease, it's a pleasure to work with. Well done Lit team.
- fabiospampinato 3y agoInteresting how they say that compiled templates are ~21% faster to update, I wonder why. In theory pretty much anything that they could be doing at compile time could just be done at runtime, since they are building on top of tagged template literals, which enable this, so I guess there were some optimizations missing for that in v2? I'd be interesting if anybody knows what was missing.
- spyr1014 3y agoI ran that benchmark and can let you know what's going on. The benchmark switches templates using conditionals. So what is happening is: 1. On the first render, every template that is rendered gets prepared. And there is that 46% improvement. 2. On the second render, some code paths change and some new templates that haven't yet been rendered get rendered. This results in a smaller improvement. Then over time, as different code paths are exercised, the improvements of compilation reduce as every template has been seen at least once.
- tarkin2 3y agoLit seems very lightweight before. Has it got a bit more 'frameworky'?
- mdhb 3y agoIt actually got smaller in code size as it was able to use more native platform stuff as that support has evolved over time.
- StevePerkins 3y agoI'm a backend developer, so pardon my ignorance. I'm reading here that this basically a thin wrapper on top of the Web Components standards, which I've been reading about for nearly 15 years now. So this makes me wonder... why does basically no one ever write directly to the Web Components standard? There are really only two major web browser engines left in existence (three if you are extremely generous and still include Firefox). Are there really enough differences in Chrome and Safari's implementation of Web Components to still require a polyfill after all these years? The original polyfill was Polymer, and I believe that both it and this Lit library are both Google projects. If so, then what is the delta between the two? It looks like Polymer is now in maintenance mode, so clearly Lit is the successor. But are there fundamental changes beyond a branding refresh?
- azangru 3y ago> why does basically no one ever write directly to the Web Components standard? Web components provide a life cycle (mounted, unmounted, attribute changed) and an encapsulation mechanism; but they aren't reactive. They don't rerender when you change an attribute or a property. They don't have a concept of local state, whose changes would result in a rerender. Html templates don't have a convenient syntax for binding properties or events. Lit adds all this convenience, with very little code. The result is that the web components that it produces remain standard and interoperable, but are also much more pleasant to author than plain components.
- colordrops 3y agoProbably just due the network effect of React coming to the scene first, and the cost of change. I've used Web Components nearly exclusively at multiple jobs for 7 years now, so my experience is that they are out there and in use. Had to start using React recently for a job and it feels like a mess in comparison. Too many ways to do things, big black box components that are hard to introspect, compilation is not optional, and poor documentation on some aspects due to not using standards. I'm still struggling to understand "stale closures" and the react component life cycle. It seems to have a lot of baggage.
- dchest 3y agoLit is not a polyfill, it's an easier way to write Web Components without writing DOM manipulations manually. Building on top of the Web Components standards, Lit adds just what you need to be happy and productive: reactivity, declarative templates and a handful of thoughtful features to reduce boilerplate and make your job easier.
- morbicer 3y agoThere's one thing that I haven't figured out about custom web components which make them completely broken for me: using them as form elements with good DX and UX. For example custom button that should behave like native html button - submit form on click, submit form on enter if I am in one of the text inputs, correctly handling "form" attribute when the button is outside of the form itself etc. I know about "formAssociated" and "ElementInternals" but they don't solve the problem completely. Imho this isn't solved anywhere and makes the web components no-go for design systems. https://github.com/WICG/webcomponents/issues/814 https://github.com/WICG/webcomponents/issues/814 I also find baffling that there is _zero_ information about forms in the Lit3.0 documentation. If someone figured this out please enlighten me. Example: https://lit.dev/playground/#project=W3sibmFtZSI6InNpbXBsZS1ncmVldGluZy50cyIsImNvbnRlbnQiOiJpbXBvcnQge2h0bWwsIGNzcywgTGl0RWxlbWVudH0gZnJvbSAnbGl0JztcbmltcG9ydCB7Y3VzdG9tRWxlbWVudCwgcHJvcGVydHl9IGZyb20gJ2xpdC9kZWNvcmF0b3JzLmpzJztcblxuQGN1c3RvbUVsZW1lbnQoJ2xpdC1idXR0b24nKVxuZXhwb3J0IGNsYXNzIFNpbXBsZUJ1dHRvbiBleHRlbmRzIExpdEVsZW1lbnQge1xuICBzdGF0aWMgc3R5bGVzID0gY3NzYGJ1dHRvbiB7IGJhY2tncm91bmQ6IGxpbWUgfWA7XG4gIHN0YXRpYyBnZXQgZm9ybUFzc29jaWF0ZWQoKSB7XG4gICAgcmV0dXJuIHRydWU7XG4gIH1cbiAgXG4gIHByaXZhdGUgaW50ZXJuYWxzOiBFbGVtZW50SW50ZXJuYWxzO1xuXG4gIEBwcm9wZXJ0eSgpXG4gIG5hbWUgPSAnU29tZWJvZHknO1xuICBcbiAgY29uc3RydWN0b3IoKSB7XG4gICAgc3VwZXIoKTtcbiAgICB0aGlzLmludGVybmFscyA9IHRoaXMuYXR0YWNoSW50ZXJuYWxzKCk7XG4gIH1cblxuICByZW5kZXIoKSB7XG4gICAgcmV0dXJuIGh0bWxgPGJ1dHRvbiB0eXBlPVwic3VibWl0XCI-JHt0aGlzLm5hbWV9ITwvYnV0dG9uPmA7XG4gIH1cbn1cbiJ9LHsibmFtZSI6ImluZGV4Lmh0bWwiLCJjb250ZW50IjoiPCFET0NUWVBFIGh0bWw-XG48aGVhZD5cbiAgPHNjcmlwdCB0eXBlPVwibW9kdWxlXCIgc3JjPVwiLi9zaW1wbGUtZ3JlZXRpbmcuanNcIj48L3NjcmlwdD5cbiAgPHNjcmlwdD5cbiAgICAgICAgZnVuY3Rpb24gb25TdWJtaXQoZXZlbnQpIHtcbiAgICAgICAgICAgIGV2ZW50LnByZXZlbnREZWZhdWx0KCk7IC8vIFByZXZlbnQgdGhlIGRlZmF1bHQgZm9ybSBzdWJtaXNzaW9uXG4gICAgICAgICAgICBhbGVydCgnRm9ybSBzdWJtaXR0ZWQhJyk7XG4gICAgICAgIH1cbiAgICA8L3NjcmlwdD5cbjwvaGVhZD5cbjxib2R5PlxuICA8Zm9ybSBvbnN1Ym1pdD1cIm9uU3VibWl0KGV2ZW50KTtcIj5cbiAgICA8aW5wdXQ-XG4gIDxsaXQtYnV0dG9uIG5hbWU9XCJUaGlzIGRvZXNuJ3Qgc3VibWl0XCIgdHlwZT1cInN1Ym1pdFwiPjwvbGl0LWJ1dHRvbj5cbiAgICBcbiAgPGJ1dHRvbiB0eXBlPVwic3VibWl0XCI-VGhpcyB3b3JrczwvYnV0dG9uPiAgXG4gICAgXG4gIDwvZm9ybT5cbjwvYm9keT5cbiJ9LHsibmFtZSI6InBhY2thZ2UuanNvbiIsImNvbnRlbnQiOiJ7XG4gIFwiZGVwZW5kZW5jaWVzXCI6IHtcbiAgICBcImxpdFwiOiBcIl4zLjAuMC1wcmUuMVwiLFxuICAgIFwiQGxpdC9yZWFjdGl2ZS1lbGVtZW50XCI6IFwiXjIuMC4wLXByZS4xXCIsXG4gICAgXCJsaXQtZWxlbWVudFwiOiBcIl40LjAuMC1wcmUuMVwiLFxuICAgIFwibGl0LWh0bWxcIjogXCJeMy4wLjAtcHJlLjFcIlxuICB9XG59IiwiaGlkZGVuIjp0cnVlfV0 https://lit.dev/playground/#project=W3sibmFtZSI6InNpbXBsZS1n...
- 3y ago
- dang 3y agoRecent and related: Lit: Simple, fast web components - https://news.ycombinator.com/item?id=36806747 https://news.ycombinator.com/item?id=36806747 - July 2023 (141 comments) Also related: Lit 3.0 Pre-Releases - https://news.ycombinator.com/item?id=36097790 https://news.ycombinator.com/item?id=36097790 - May 2023 (2 comments) Offical Lit team’s guide to building your first Lit Web Component - https://news.ycombinator.com/item?id=31169173 https://news.ycombinator.com/item?id=31169173 - April 2022 (1 comment) Lit is a simple library for building fast, lightweight web components - https://news.ycombinator.com/item?id=27980807 https://news.ycombinator.com/item?id=27980807 - July 2021 (1 comment) Lit – Simple. Fast. Web Components - https://news.ycombinator.com/item?id=26891866 https://news.ycombinator.com/item?id=26891866 - April 2021 (2 comments) WebComponent libraries lit-HTML and litElement released - https://news.ycombinator.com/item?id=19089360 https://news.ycombinator.com/item?id=19089360 - Feb 2019 (18 comments)
- russellbeattie 3y agoI think it's interesting how JavaScript has gone full circle on classes. At one point a decade or so ago, classes became vilified as substandard syntactic sugar on functions. That combined with a surging interest in pure functional programming lead to devs using functions for everything and libraries like underscore to assist. Just five years ago, React added hooks as a way to avoid classes all together. Now classes have been super-charged in the latest JavaScript proposed standards, with the addition of syntax for private and static variables, getters and setters, accessors, decorators and more. All of which are either in engines already, soon will be, or adopted by TypeScript or other precompilers. I think it's interesting because TC39 decorators which Lit is now using aren't usable with functions yet, only classes and class methods. The standards groups seem to be at odds with the general JavaScript community consensus on dev patterns. But with classes becoming so much more central to how JS is structured, I guess we're going to see a lot more class-centric JavaScript. Which is OK, I guess. I just hope it doesn't turn into Java.
- claytongulick 3y agoI like a lot of the concepts of FP, but once you get past the "new shiny" aspect of it and start writing applications, the warts start to show. It's really like anything - extreme/purist FP can have terrible application performance with limited benefit. Same with extreme/purist OOP. JS classes hit a sweet spot for me. They are minimalist, composable, easy to duck-type, and are basically just a convenient unit of code organization more than anything. I never really jumped on the "pure fp" bandwagon. It gave birth to monstrosities like RxJs - which some people actually use, and I don't understand how or why. Same for me with React - class based components are a lot less magical than all the useEffect and use* stuff. They're easy to reason about, and self-contained. I never really understood the drive for "pure functional components". There's so much cruft and artifacts that arise from that, it interferes with application feature deliver and performance. You end up spending your days doing crazy Redux or RxJs like things, increase complexity by an order of magnitude, all for very limited actual benefit (like theoretical time rewinding during debugging - which I have never actually had a need for).
- sbjs 3y agoOverall I'm not super happy with web components to solve the issues of reusability, conciseness, and self-containment. The most direct problem is styling issues. Cross-component CSS in either direction has some serious limitations. I've written a little bit about it[1] in my blog but the short version is that there are some things that simply become absolutely impossible when using web components. My main other gripe with them is the need for a build phase. The nature of WC almost begs for them to eventually become zero-build-time, but right now this just isn't practical. It requires too much boilerplate in every .html file (utf8 is broken on my site), the syntax isn't natively there even with tagged template literals, and there's no concept of data-list-fetching or data-based file generation. There's a branch on my personal website[2] where I tried to start using web components, and it was so problematic that I long abandoned it. Overall, I abandoned web components entirely in favor of making my own customized JSX-based SSG from scratch[3] which solves the same problems Lit, Next.js, et al. are intended to solve, but in a completely different way: using components for convenience, conciseness, and reusability, but only at the build-phase time. So far it's a well kept secret, which is probably good since it's been evolving so quickly that I wouldn't have been happy with any iteration being widely adopted so far. (Though I think this morning I finished off most of what I was unhappy with.) [1]: https://sdegutis.github.io/articles/2023-08-07-modern-90s-web-dev.html https://sdegutis.github.io/articles/2023-08-07-modern-90s-we... [2]: https://github.com/sdegutis/immaculatalibrary.com/tree/reset/new https://github.com/sdegutis/immaculatalibrary.com/tree/reset... [3]: https://github.com/sdegutis/immaculatalibrary.com https://github.com/sdegutis/immaculatalibrary.com
- claytongulick 3y agoI'm curious about this - are you using shadow DOM? If so, I completely understand your frustration. IMHO shadow dom isn't really useful for application authoring, it's beneficial for library authors and such. Web Components become a lot easier if you just stick with the light dom.
- spankalee 3y agoShadow DOM is what enables interoperable composition. Without it you don't get <slot>s and without that you can't put children into a component without some very ad-hoc hacks.
- anonygler 3y agoIf only Google were as committed to its products as they are to the insanely over engineered proposals that fail to solve any legitimately useful use cases. Half of why these projects exist is for internal gate keepers at Google to make excuses for why they're not allowing productive engineers to adopt React/Vue, etc. These weird quasi-frameworks exist in large part due to production use of NodeJS being banned at Google. What you get with Google OSS is a weird backwash, digesting external technical direction in a way that caters to internal consumers. They then flop it onto the ground on Hacker News. Why would I use this? There's a million reasons not to, and then there's having a safe cushy jobs and priorities that have nothing to do with the core business. Bleh.
- rictic 3y agoThis is, uh, a pretty confused set of things to say. Shadow DOM is implemented in every browser. Now that we've dropped IE11, Lit doesn't need any polyfills in any of our supported browsers. Lit is javascript, and would greatly benefit from Google's internal stack having better support for NodeJS.
- anonygler 3y agoFair, removed that part -- I remember something about Shadow DOM got delayed or had a lot of push back, back in the day -- and I thought it was dead in the water when I started seeing Shady DOM stuff internally. But regardless, I've never had a single use for it working on SaaS products.
- deleted 3y ago[deleted]
- claytongulick 3y agoPretty 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.
- psygn89 3y agoAs an alternative, check out Stencil.js. If you are componentizing within a controlled environment, then the shadow DOM feels like an unnecessary complexity. If the style collisions are a concern, you can turn on Stencil's scoped styling which dynamically creates unique css classes. It also has popular framework bindings so that you can output your components to work with different frameworks along with native web components. However, if you are wanting to share your components with the world, starting with fresher code, and/or have the resources to tackle the shadow DOM gotchas then I would consider Lit over Stencil. Just dropping this out here for those in the research phase as it wasn't super clear to me at first which way to go. Both are really good options but better for certain situations.