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.

In my last adventure, I complained mightily about how a tiny bug in tree-sitter-scss was all that stood between me and my next heroic work accomplishment. Although I didn't mention it at the time, I had little faith that my submitted issue would be addressed anytime soon, since when looking at the tree-sitter grammar repository I could see that the SCSS parser had last been updated in early April of 2024 and had been idle for eight months.

I took matters into my own hands.

Update: Contrary to my whining down below, I spent the weekend playing with tree-sitter, found the bug, and have submitted a PR.

When you've got twenty years of developer experience, there is one source of frustration at work that can be greater than any other: when you can see the promised land but you know you can't get there and, worst of all, the wall between you and there is barely ankle high.

I am not, by any stretch of the imagination, an expert on parsers and scanners. I've written a few DSLs in my time and always leaned on something commonly available, usually either s-expressions, a readily available configuration language like YAML or TOML, or just a cut-down version of the host language with specificity for my DSL needs.

So let's talk about Shatterfly.

If you've ever needed to hunt through a massive HTML project for a specific, repetitive clause, there aren't a lot of tool that are really that helpful. I'm sure there are some tools better suited to it, but I found a recipe for gawk that I like.

I recently had a horrible experience where I could not get Lit to run the same test twice using the WebdriverIO Component Testing Guidelines for Lit.

The test is simple: Before each test, render the component, click on it, see if its internal state is what I expect, and then remove the component at the end of the test. I expected that if I ran the exact same test twice, it would work (or fail) twice.

It turns out Lit is being passive-aggressive about caching what you've done, won't re-render cached content preferring to re-connect it instead, and won't help you figure out that it doesn't exist anymore and can't be re-connected.

After six years of writing React professionally, I have decided that I really prefer Web Components to React, Angular, Vue, or any of their ilk. Web Components are the browser's native model for defining components; they don't need huge libraries to "route around" deficiencies in the browser nor do they need special context or event types; they just use the browser's own event dispatcher, and context is managed by putting stopPropogation on the context handler's DOM Node.

I recently spent some time trying to port my old jQuery/Backbone demo, Fridgemagnets, to a Web Component model.

I started out by using Lit-Element. Lit is a very small toolkit from Google which creates a bundle of only 5KB, much smaller than React's 40. I had good reasons: due to the history of Web Components, the API is awkward with very long method names and an annoyingly complex dance to convert text to a DOM Node. Lit streamlines a lot of that, but it also adds something that I usually find annoying: all your events that cause a state change in a component are batched and propagated at once, debounced to prevent refresh pauses. Lit wants to make web components "reactive," so your state is stored in monitored attributes.

For the most part, I can live with that. But in the conversion to FridgeMagnets, I hit a headache.