Lit!

Native web components are a pain to build and design, mostly because the API is complicated and naive implementations can have less than stellar performance. Lit is a library, originally developed by Google, that provides an alternative API for dealing with the web component lifecycle, as well as a scheduling system that decorates your existing DOM with comment fields that provide for all of the performance of a virtual DOM without any of the memory overhead. Lit also provides excellent ergonomics for defining properties, attributes, accessors to component internals, as well as powerful idioms for defining events, boolean and string passing, and passing complex JavaScript objects from one component to another.

The components here were originally developed for a similar library, Minze, which was one of several such libraries with similar intent. They, and an accompanying article, were developed by Sergej Samsoneko and published at Codrops.

If you're a web component developer, you know that you can use the css ::part pseudoelement to give external developers permission to style, well, parts of your component. But did you know that you can use ::part to selectively style those parts based on the state of the component?

I'll show you how you can declare parts dynamically and serially, just as if they were child selectors, and use that dynamism to allow developers to style your component differently if it's disabled, or readonly, or "successful!" This example will use Lit, but it should work with raw web components or with any other library like Svelte, Ornament, or Minze.

The DevFest Nantes 2019 presentation of Building Complex Applications with Web Components is probably one of the most important to Lit developers; everyone references Justin Fagnani's presentation of how to do routing, lazy loading, and context management. The presentation includes a section on dependency injection: how an object can request its dependencies from other components higher up in the DOM tree.

One of the problems I have with the code as presented is that it fails to handle the case where the dependency supplier must perform some asynchronous work before sending the dependency to the requester. I'll show you how to extend the example to handle that, and what capabilities that extension gives you.

It's commonplace in Web Components to use custom events. The custom event type is an inheritor of the Event class, but it includes a new field, detail: any, that allows you to attach data to the Event, which is useful for passing data up to the listener, right?

Wrong. It's a trap. You could, theoretically, inherit from CustomEvent and narrow the content of detail to what you specifically want, and I've seen lots of code where people do exactly that.

But there's a better way: just inherit from Event. Skip the CustomEvent class and just create your own events. I'll show you how.

In my new job, I've been working a lot with an existing codebase that uses web components (via Lit) for the HTML and Patternfly for the CSS, and I've discovered that Patternfly, as well as other CSS Libraries such as Tailwind or Bootstrap, are awkward fits for developing web components. You usually end up importing too much per component or sacrificing code readability on the altar of code size.

Let me give you an example:

React is the number one most popular web application development framework, hands down, with twice the user base of its next competitor, Angular. My framework of choice is LitElement, which doesn't even appear on some of these charts.

According to Stack Overflow, 55% of developer "admire" Lit, and less than 1% get to work in it. I, fortunately, get to work in Lit, but after four years of React experience I've discovered that Lit is so very different from React, Angular, and the rest that it takes a heavy mental shift to work in it.

I work professionally on a medium-sized web application written in Lit that orchestrates and administers single-sign-on for small-to-medium businesses. I really like Lit, and working on this thing has been like being thrown into the deep end of the pool. There are two aspects of Lit that make it really different from the others and can make it hard for some developers to make the mental shift.