8 ms·
Lit: Simple, fast web components
- formerly_proven 3y ago> Tiny footprint, instant updates I can see that, the website re-renders only three times on load (text - image - fonts).
- samwillis 3y agoLit looks really good, I keep trying to find an opportunity to try it out. I feel like web components and the tooling around them has finally got there. Major front end frameworks like React, Vue and Svelt finally also have good support for them. What I really want is a good set of unstyled web components implementing many of the common UI controls that we all end up either building ourselves or finding an implementation of in our framework of choice. Things like drop down menus, select boxes, and tool bars. They could then be used with any of the common front end toolkits.
- psygn89 3y agoAgreed. I get excited to see "headless components" until I read the fine print that it's locked into framework x (usually React). I wish there was a robust headless AND framework-agnostic component library (preferably relying on Lit or Stencil).
- samwillis 3y agoThink thing is that Ionic have proven this can work with the massively underrated Ionic Framework (built with Stencil, which they also built). I just wish they expanded a little further into desktop UI components and provided an no/low styled variant - I dislike Material as a base style, it's too opinionated. They are 50% of the way to building a universal mobile+ desktop ui toolkit. Do the same with Ionic Capacitor, make a desktop version, and that would be an incredible improvement over Electron - it uses the OS supplied web view.
- commanderkeen08 3y agoNobody wants Shadow DOM though. Using ::part is always clunky and we’re all lying to ourselves when we say “oh no that’s the feature”. The whole shadcn/tailwind philosophy of having you own your components is the future.
- jakelazaroff 3y agoWait, but that is the feature. My issue with Shadow DOM is that "base" styles (like fonts and colors applied to tag selectors) don't come through, not that I can't override any given style from outside. I'm not really sure what you mean by "own your own components"?
- johne20 3y agoYou don't need to use Shadow DOM though?
- sublinear 3y agoAt my workplace we only ever used it once to build a skinnable white label customer support widget for about a dozen of our client's websites. It's a webcomponent that gracefully degrades to es5 + polyfills for IE (this was years ago). Getting the rollup build to work correctly was a bitch and a half, but it turned out nice and it's still in use today.
- e111077 3y agounstyled web components: look into ING Lion Web Components (Lit-based) or @generic-components/components (vanilla)
- claviska 3y agoCreator of Shoelace [0] here. As someone who’s built multiple design systems and component libraries, I assure you that unstyled (or “headless”) components are often much more time consuming and painful to adopt than those with good default styles. That said, I commonly find that most folks don’t want unstyled components because it’s quite a bit of work to style every single state of every single component. Most people just won’t do it or, if they try, they don’t do it right and they don’t do it completely. What many folks do want are components that have simple, generic styles you can quickly tweak to match your site/app using a skill you already know: CSS. (This is something you can do with Shoelace’s 50+ web components already, but we’re working to make it even easier with additional CSS custom properties.) [0] https://shoelace.style/ https://shoelace.style/
- dleeftink 3y agoThanks so much for your work, the components look great and straightforward to use. Next time I'm building something will definitely try to give Shoelace a spin. Can I ask, are ARIA attributes handled by default?
- brylie 3y agoPerhaps this isn't as specific of an answer as you're looking for, as I'm not too familiar with the Shoelace library, but perhaps we gain some insight from the Shoelace Accessibility Commitment. > My commitment to Shoelace users is this: Everything I develop will be built with accessibility in mind. I will test and improve every component to the best of my ability and knowledge. I will work around upstream issues, such as browser bugs and limitations, to the best of my ability and within reason. https://shoelace.style/resources/accessibility/index.html https://shoelace.style/resources/accessibility/index.html
- claviska 3y agoThe goal is to handle as much accessibility as possible with smart defaults and by making it easy for users to get right. Currently, all aria stuff is handled internally the components. For example, look at <sl-input> and you’ll see that the input, label, and help text are automatically linked in the shadow root. The minimum the user needs to provide is a label and assistive devices work as expected.
- maxkless 3y agocheck out @microsoft/fast-foundation. It’s UI primitive web components and works really well with lit.
- dgb23 3y agoI haven't used Lit yet, but have used lit-html standalone professionally for some projects. (lit-html is a very small, very performant library and the templating solution for Lit). I'm very happy with it. I don't have a use-case for web components (so far) and am happy to just wire up dom events to state changes to lit-html. It requires _very_ minimal plumbing and is very easy to reason about.
- no_wizard 3y agoI've used Lit. For what it is, its pretty decent. One of my complaints with Lit and others[0] is they're most definitely becoming something of an "Angular Lite". Heavy on decorators if you want developer ergonomics, but yet they embrace none of the advanced toolchain things you get with angular-cli. Due to this, it can feel very clunky to build apps using web component frameworks like this. The community as a whole seems very anti-tooling and I think its to the long term detriment of the ecosystem. The only exception is Stencil[1] that I can find. They're also missing first class concerns you get handled with other frameworks, like SSR, compiled templates etc. There's no web component equivalent to Next.js that I am aware of. I don't like using them for design systems. You bail on your framework of choice rendering model, and that's problematic to me. [0]: https://www.fast.design/ https://www.fast.design/ [1]: https://stenciljs.com/ https://stenciljs.com/
- spankalee 3y agoLit doesn't require decorators, and if you do use them they only require a pretty standard TypeScript or Babel compile. Are decorators the only thing making Lit like Angular? Angular is not the only project that uses decorators, and decorators are standardized in JS now. Stencil is good, but requires a compiler where Lit doesn't. What tooling are you looking for? We have template type checkers and eslint plugins. Starter kits. Prettier works for formatting... https://lit.dev/docs/tools/development/ https://lit.dev/docs/tools/development/
- no_wizard 3y agoI am aware you don't need decorators, this isn't what I was saying. I said its the only way to use Lit with any measure of good developer experience. Decorators are not the only thing that make it like Angular. The way templates work, template helpers (directives), controllers are all very Angular like in practice. Tooling is much more than linters, eslint plugins and starter kits. Unit & e2e testing helpers, build tools, HMR / dev server support. These all matter too and its important that they keep up to date with expectations of developers in what they expect out of these experiences. Even better when it is all rolled up in a nice CLI interface. Not to mention it would be nice to have optimized convenience features, like Vue style SFCs for authoring components and templates. Stencil requiring a compiler is not a negative. It makes it an end to end solution and thats very popular for a reason (Next.js, Nuxt, Sveltekit are all very popular for a reason). I believe strongly that projects need to provide these things as 1 party concerns. I think the Vue community is proof positive of how strong this can be for the ecosystem. I'm certain between Google, Microsoft, Ionic, and many others there could be real solutions for all this. After all, the biggest advantage of using web components is they are a shared interface
- andrewstuart 3y agoI took an interest in Lit at one point and I gave up when I discovered that its core functionality is ungoogleable. At the heart of Lit are components named "html" and "css". Confusion reigns, search engines cower, beginners try to grasp the conceptual different between html and actual html and css and actual css. You'd think the authors would have gone to the trouble of naming those critical components something like lithtml and litcss to give them a little searchability and to deconfuse them, but it seems not.
- bobmaxup 3y agohttps://github.com/lit/lit/tree/main/packages/lit-html https://github.com/lit/lit/tree/main/packages/lit-html
- colordrops 3y agoLit doesn't use any special dialect of HTML or CSS. It's just HTML and CSS.
- ssss11 3y agoI think they’re referring to Lit naming components ‘html’ and ‘css’ - if you go to the tech docs here the very first example imports ‘html’ and ‘css’. https://lit.dev/docs/components/overview/ https://lit.dev/docs/components/overview/ I agree that those are odd choices and the arguments provided seem reasonable I.e. they’re likely ungoogleable, and beginners would be confused.
- spankalee 3y agoIn Lit `html` and `css` are template tags, not components. Those names are well supported by editors and enable syntax highlighting. If we named them anything else it wouldn't work without extras tools.
- andrewstuart 3y agoThe fact that you are explaining this to me reinforces my point. One of my primary criteria in choosing a technology to work with its how accessible is community support, documentation, third party articles and writing. It had better be a compelling technology that names its main things exactly the same as the biggest concepts in web development, thereby making it a battle to resolve questions and issues and adding unnecessary confusion. I do use a nodejs library called "Postgres" which provides a Postgres SQL driver but I really hate the fact that searching for documentation/issues is essentially impossible. I use it because I feel I had no choice, it's the best possible technical solution. Names matter. Searchability matters a huge amount.
- downvotetruth 3y agoDefaulting to v2 instead of v3 for the documentation selector in the upper right seems odd, especially considering the extent of the changes.
- aranw 3y agov3 appears to be pre-release version? Surely that makes sense to not default to pre-release code for the docs?
- downvotetruth 3y agoThe upgrade is claimed to be seamless when running Lit 2.x with no deprecation warnings; defaulting to deprecated API documentation is a bit counterproductive.
- spankalee 3y agov2 documentation is not deprecated. v3 isn't released yet.
- downvotetruth 3y agoIf v3 is "not released" then having it accessible with the other 2 releases is contradictory - this "prerelease" is still a form of release; no claim was made that the entirety of the v2 documentation was deprecated.
- spankalee 3y agoWe'll switch the default over to v3 once v3 is out of prerelease.
- lcnPylGDnU4H9OF 3y ago> no claim was made that the entirety of the v2 documentation was deprecated > defaulting to deprecated API documentation I am not sure what point is being made here. This seems to be splitting hairs. Regardless, it makes sense to default to the docs for the version which is considered to be officially released. That version is probably most likely to be used in a production application, which is usually what the docs are intended to support.
- UnixSchizoid 3y agoSounds pretty lit, Edit:Dang you guys really hated that
- lcnPylGDnU4H9OF 3y agoYeah, jokes are touchy. People commonly feel that it detracts from interesting conversation. In practice, there are sometimes “allowed” jokes; otherwise timing it later after the post at least garners fewer downvotes.
- UnixSchizoid 3y agoThe best part is I made that comment an hour after the post and was the second overall lol
- lcnPylGDnU4H9OF 3y agoThat’s a good point. Perhaps “after the conversation” is more accurate, though harder to define. Still, it got a chuckle out of me.
- UnixSchizoid 3y agoI agree with the after the conversation point. And as long as one person chuckled the downvotes are worth it.
- benno128 3y agoI’ve been using lit in side projects (e.g. runno.dev) and really enjoyed it. Just like any framework it can be a bit confusing learning the primitives but I’ve found it as productive as React, Vue or Svelte. The thing I like most about lit is that it embraces web standards. Sometimes that means the ergonomics are a bit strange. But it also means it gets performance benefits, and interoperability bonuses. Plus it feels like you’re learning something about the underlying platform while you’re using it. The best example is that it uses reactive data binding via attributes for passing data down the tree, and native DOM events for passing data up the tree. That allows you all the same safety that a framework like React offers, but also means your component can be used by any other framework, or by vanilla JS (because they all support the DOM).
- djbusby 3y agoI was looking for comparison and found this post https://webcomponents.dev/blog/all-the-ways-to-make-a-web-component/ https://webcomponents.dev/blog/all-the-ways-to-make-a-web-co... Which puts 61 of web-component libraries side-by-side. Sadly my favorite, RiotJS, is not on the list.
- dsissitka 3y ago> Sadly my favorite, RiotJS, is not on the list. Looks like it might be in the "Wrapped into a custom-element" category.
- superchris 3y agoBeen using Lit for a few years now, it just keeps getting better. It does what it does, and stays out the way. Please don't call it a framework though, the best part of Lit is that is basically some (very lovely!) sugar over standards built into your browser. And as browsers keep improving (at an amazing pace IMO) Lit keeps getting smaller, which might be my favorite thing about it.
- hbcondo714 3y agoOne scenario for using Lit is with a PWA; it comes pre-built with Microsoft-founded PWABuilder's starter kit: https://docs.pwabuilder.com/#/starter/adding-content?id=adding-new-pages-and-routing https://docs.pwabuilder.com/#/starter/adding-content?id=addi...
- atarian 3y agoI think web components were almost a good "built-in" way of doing React/Vue. Where it lost me was the Shadow DOM. I get that it's supposed to encapsulate the contents of a component and restrict JS/CSS to itself, but it's overkill IMO. It's basically like having a bunch of iframes and makes it much harder to query things, which is very much unlike the rest of the DOM. I don't need guard rails to tell me how to do encapsulation.
- acedTrex 3y agopoorly designed web components are so painful because of that
- e111077 3y agoYeah, this is not an issue for very well-designed WCs like https://shoelace.style https://shoelace.style or in cases where it's not necessary like https://modelviewer.dev/ https://modelviewer.dev/
- spankalee 3y agoEncapsulation might be overkill for a single developer, but it very much matters for teams and using third-party components. If you want to drop in a calendar component into your page from npm, it helps if that component's styles don't leak into the page, and if page scripts don't accidentally mess with component internals.
- lcnPylGDnU4H9OF 3y ago> makes it much harder to query things This seems overstated. It’s different but not really harder. document.querySelector('my-lit-element').elementIWant; class MyLitElement extends Lit { get elementIWant() { return this.renderRoot.querySelector(...); } } Though, maybe one doesn’t like querying twice. I’m not sure of performance implications there, to be honest, but I’d expect it to be negligible in most cases.
- benno128 3y agoI think framing it this way can lead to real gripes with the interface. Web Components are a great way to build individual components that can be reused across an app, website, or shared as part of a library. They are like helper functions for HTML. They don't work as well for building apps, sure you can do it, but tools like React/Vue/Svelte are much better at building a whole app experience. Particularly when you consider meta-frameworks and the ecosystem around them.
- donmcronald 3y agoDoes anyone know if the social icons on that site are from a set somewhere?
- e111077 3y agoI worked on adding some of these. We pull them from each of the company's respective brand identity page + some manual SVG cruft elimination to decrease code size.
- _xivi 3y agoSeems like it lacks support for SSR? I'm wondering if it's ready or make sense to replace web framworks or what is its optimal use case
- spankalee 3y agohttps://lit.dev/docs/ssr/overview/ https://lit.dev/docs/ssr/overview/ SSR support is coming along. It's taking a while because we're trying to do it in an interoperable way, both to allow mixing of web components from different libraries, and to plug into framework-specific SSR (There are Lit SSR plugins for Next and Nuxt available).
- superkuh 3y agoThere's nothing simple about custom-html element defined by javascript. It may be "Interoperable & future-ready" but it sure isn't interoptible with pretty much everything from 1995 to 2019.
- benno128 3y agoThis is just plain wrong. Web Components work in every browser that matters. They are standard DOM elements and can be written in plain HTML server-side or via legacy front-end libraries. I'm using web components in production to help interoperability between 2012 era Handlebars/jQuery/Backbone and modern tools like React and Prosemirror.
- superkuh 3y ago>Web Components work in every browser that matters. Reading between the lines here I'm getting the feel that this is actually, "Web Components work in every browser that people use to spend money." And I don't disagree. If you're doing something for work and being paid to do it then by all means use web components. The large number of people around the world you exclude weren't part of the demographic you were going to get money from. But saying that it works in every browser that matters is wrong.
- spankalee 3y agoWhat browsers do web components not work in that you would like to see support them? I think "every browser that matters" means, yes they don't work in IE or legacy Edge, and maybe don't work in Servo or Ladybird, but they work in Firefox, Edge, Chrome, Safari, Opera, etc. https://caniuse.com/custom-elementsv1 https://caniuse.com/custom-elementsv1
- lcnPylGDnU4H9OF 3y agoSorry, I responded to the wrong person.
- spankalee 3y agoMaintainer of Lit here! A few of the unique things I try to emphasize when talking about Lit because it's so different from a framework: Lit is just helpers to make web components. It's implementation detail. On the outside the components are just standard HTML elements. Because of that, Lit makes no assumption that other elements you're using in your components are made with Lit. This low coupling preserves interop, and makes it easy to incrementally adopt Lit, and incrementally leave it if you wish. Low lock-in is an important principle for us. Because of the low coupling, Lit doesn't have any centralized scheduling, diffing, etc. Each component is its own independent render root and schedules its own updates in microtasks. This has some great upsides - it's very easy to modify scheduling per component, and decouple costly subsections of a page to limit jank. And we get great performance from the emergent global properties of independent roots. We check for data changes in the property setters for each component, so data updates only cause component updates along the paths in the tree that both use that data and see a change. Then lit-html, the template system, doesn't use VDOM, but remembers where data is bound to the DOM and only updates that if the data changed. It's very efficient. Also, Lit requires no compiler to toolchain. You can use it from a CDN, or with import maps, or with a tool that resolves JS modules import specifiers. You can use decorators with TypeScript, or not. You can bundle or not. We do have TypeScript and ESLint plugins for working with templates.
- hardwaresofton 3y agoLit is awesome, thanks for maintaining it. I do more Svelte these days but have used Lit in the past and was very pleased with it. Looking forward to using Lit in the future since I think it does a really great job of getting out of your way and being supremely easy to use and standards-adjacent. > Because of the low coupling, Lit doesn't have any centralized scheduling, diffing, etc. Each component is its own independent render root and schedules its own updates in microtasks. This has some great upsides - it's very easy to modify scheduling per component, and decouple costly subsections of a page to limit jank. Could you share some downsides? > Also, Lit requires no compiler to toolchain. You can use it from a CDN, or with import maps, or with a tool that resolves JS modules import specifiers. You can use decorators with TypeScript, or not. You can bundle or not. We do have TypeScript and ESLint plugins for working with templates. This is awesome -- thanks for As for an actual new question, I'd love to know if there are any considerations on shared data in Lit -- with the just-web-components nature of Lit, data & reactivity are hard to fit in obviously but would be very beneficial to solve in a way that is just as easy to use as the rest of lit. I took a stab at what it could look like and wrote a demo[0] and post[1], but have not kept up with the Lit community since then to see if there's some other solution/pattern gaining steam. [0]: https://mrman.gitlab.io/services-as-dom-elements https://mrman.gitlab.io/services-as-dom-elements [1]: https://vadosware.io/post/sade-pattern-services-as-dom-elements https://vadosware.io/post/sade-pattern-services-as-dom-eleme...
- JohnMunsch 3y agoWe absolutely love Lit. We've used it for our Web Components after a brief (bad) dalliance with using Angular Elements to make some. We pair it with Storybook, finicky though it is, to have a catalog of our components and stories showing off the variances for each.
- deleted 3y ago[deleted]
- andrewmcwatters 3y agoI mean, if you're going to use web standards, why not just go all the way. Compare to https://legacy.reactjs.org/docs/add-react-to-a-website.html https://legacy.reactjs.org/docs/add-react-to-a-website.html. Preview at https://andrewmcwatters.github.io/custom-elements/ https://andrewmcwatters.github.io/custom-elements/. Example at https://github.com/andrewmcwatters/custom-elements https://github.com/andrewmcwatters/custom-elements: // https://developer.mozilla.org/en-US/docs/Web/API/Web_components/Using_custom_elements // Create a class for the element class LikeButton extends HTMLElement { static get observedAttributes() { return ['liked']; } constructor() { // Always call super first in constructor super(); this.liked = false; // Create a shadow root /* const shadow = */ this.attachShadow({mode: 'open'}); this.render(); } get liked() { return this.hasAttribute('liked'); } set liked(state) { this.toggleAttribute('liked', Boolean(state)); } attributeChangedCallback(name, oldValue, newValue) { this.render(); } render() { const shadow = this.shadowRoot; if (this.liked) { shadow.innerHTML = 'You liked this.' return; } shadow.innerHTML = `<button onclick="this.parentNode.host.liked = true;"> Like </button>`; } } // Define the new element customElements.define('like-button', LikeButton);
- spankalee 3y agoPeople do this and it's fine! Lit's just there to help once you handle more features and corner cases, and do this for 10's to 100's of components. We're hear numerous times from developers who start with raw web components that the started to put common functionality into a base class, expanded their base class, then realized they were building a clone of LitElement, so switched to Lit. That's fine too! Leaning on common, well-testing implementation is great, and being able to switch to it seamlessly is one of the benefits of web components.
- spankalee 3y agoI think a lot of people would still prefer to write and read the Lit version of that <like-button> too: https://lit.dev/playground/#gist=25ef7a5ea9b73406b4418ba59cf29c49 https://lit.dev/playground/#gist=25ef7a5ea9b73406b4418ba59cf... @customElement('like-button') class LikeButton extends LitElement { @property() liked = false; render() { return this.liked ? 'You liked this.' : html`<button @click=${() => this.liked = true}>Like</button>`; } }
- just_here_for_t 3y agoLit in a professional setting was a profoundly negative experience. Ooof. Just use Angular or React or one of whatever the top 3 things are right now.
- JohnMunsch 3y agoI couldn't disagree more. We are a professional setting and have an app that is ten years old at this point that has used them previously and is expanding the use of them, not contracting them. This is after using Angular for a long time (we actually use our Web Components from Angular). I would say starting a new application in 2023 based upon Angular or React would be the Ooof thing to do.
- judah 3y agoI love Lit! Easy, fast, super lightweight as it's a thin layer over standards-based web components. Using it for all my side projects, as well as stuff at work. Server-side rendering is still a missing piece. But overall, I'm very happy using it going forward. And if you need a web component library to pair it with, Shoelace[0] is a fantastic library of prebuilt web components using Lit. I'm loving this stack. [0]: https://shoelace.style https://shoelace.style
- synergy20 3y agonot a frontend guy,is this more of jsx or htmx? what is it's major selling point? thanks
- ianpurton 3y agoWeb components are already built into the browser. Lit is like a wrapper around those.
- reverseblade2 3y agoThis is done with lit https://github.com/OnurGumus/FunPizzaShop/tree/main https://github.com/OnurGumus/FunPizzaShop/tree/main
- fareesh 3y agoWhen I write HTML/JS, productivity and convenience for me means the ability to easily style and not reinvent: a) Select dropdowns as feature-rich as select2 (search, style, custom click handlers, custom appearance in box, multiselect, callbacks) b) Data Tables as feature-rich as jQuery DataTables (search, sort, paginate, w/ server-side data, callbacks) c) A high-quality, customizable charting library that's interoperable with the components d) A slider / carousel / swiper that's as feature-rich as swiper.js e) A sane and typical component library (ideally from one place like Ant) I don't build libraries, I want to use them to build applications, and I don't want to spend too much time re-inventing them or making them play nice with each other - i.e. figuring out when one of them is done initializing so that I can trigger the "initialize" of the other and so on. The solutions thus far range from some compilation hellscape where I have to write everything in a custom dialect, which then gets compiled to HTML/CSS/JS and then I have to debug things cryptically because it's generated code. The other end of the spectrum is something that's lightweight and uses the platform extensively like htmx or what lit appears to be positioned as. I've written production applications using Angular, React, Vue, Alpine and it seems like the newer the library, the less likely it is to have an easy way to support the large selection of component libraries you could just throw together and they "just worked" in the days of jQuery + something. As a result, I end up having pages that are still jQuery + something because neither my users nor my customers care about these details, and the tradeoff is minor. As a developer it sure would be nice to have a dx where you didn't have to reinvent these things or work with ancient libraries.
- spankalee 3y agoLit is there to help you write web components, so if you don't want to write components it's not a big help, and that's ok. The flip side is that you should ideally be able to find pre-made web components that fit your need, like I think you're asking for. There are a lot of components out there, which you can hopefully find with enough diligence. What's missing is a great comprehensive catalog of components. Something I've tried to work on, but it's hard to find enough time or funding to complete.
- fareesh 3y ago
- lowi 3y agoLit is great, really easy to grasp and to use. One thing I don't understand in lit (or vuejs, svelte etc...) is why we can't have an each loop that would use information about what has changed. In my most common case, I am simply updating an item in an array (or removing/adding an item) and the each loop could use the list of operations to do the changes instead of iterating over all the items. For large array (1000+ items) for a SVG diagramming tool, performance would be much improved, no?
- LoganDark 3y ago"skip the boilerplate" but it's an npm package requiring a build system (:
- jgalt212 3y agoThe most recent episode of JS Party (284) is on Lit. I highly endorse this podcast, but I have not listened to this one yet. https://changelog.com/jsparty/284 https://changelog.com/jsparty/284
- cutler 3y agoclass ... static ... constructor ... super ... this ... extends ... @. Give me a break. I thought we'd moved on from Angular's attempt to turn the front-end into Spring.
- dgb23 3y agoYou can just use their templating library lit-html (I have in several projects now) and manage events and state yourself. It's extremely convenient and lightweight.
- deleted 3y ago[deleted]
- jstummbillig 3y agoI have no clue what web components are and at this point I am afraid to ask. Probably something to take up with ChatGPT at some point.
- fold_left 3y agoI'm not saying for one moment that it matters but one thing I was really surprised to learn was that lit (16.6kb) is actually larger than preact (11kB). With it taking advantage of Web Standards so well, I expected it would have a big advantage to be much smaller.
- deleted 3y ago[deleted]
- Kuinox 3y agoOne thing I don't get, is how can you use global icons libs like fontawesome, in your lit components.
- openplatypus 3y agoDo yourself a favour, try https://hilla.dev https://hilla.dev with Lit Components :) Such a joy.
- gitaarik 3y agoI created some libs for Lit to make things easier: LitState: Shared component state management - https://github.com/gitaarik/lit-state https://github.com/gitaarik/lit-state LitStyle: Shared component styles - https://github.com/gitaarik/lit-style https://github.com/gitaarik/lit-style LitDocumentEvent: Global event handling - https://github.com/gitaarik/lit-document-event https://github.com/gitaarik/lit-document-event Also check out "Lion" from ING, which contains all kinds of handy components that you can use and configure and style to use them in your app: https://github.com/ing-bank/lion https://github.com/ing-bank/lion