I recently released a side project called Quiet UI. It's, perhaps unexpectedly, a component library. This begs the question:

I like using GitHub issues for actionable things such as bugs and backlog items I've committed to doing. Non-maintainers are encouraged to open issues only for bugs, whereas everything else is a discussion.

It's been awhile since I wrote about FOUCE and I've since come up with an improved solution that I think is worth a post.

It’s disappointing that some of the most outspoken individuals against Web Components are framework maintainers. These individuals are, after all, in some of the best positions to provide valuable feedback. They have a lot of great ideas!

Components are like little machines. You build them once. Use them whenever you need them.

I've been struggling with the idea of reflecting attributes in custom elements and when it's appropriate. I think I've identified a gap in the platform, but I'm not sure exactly how we should fill it.

In the Web Component world, attribute reflection is commonly used to style custom elements both internally and as public APIs for consumers. If you're not familiar, attribute reflection occurs when an attribute in the DOM is updated due to changes in a corresponding property.

In a SemVer world, major releases are those which contain incompatible API changes. We often see software projects anchor themselves to major versions for long periods of time, usually with the promise of stability.

I often get asked why I use Lit to build web components. Hands down, it's become my preference after years of working with various libraries and tools. Here's why I use it.

It's hard to put a value on a design system. It's a lot easier to add up the costs of said design system, especially in terms of salaries and development time. It's even easier to target a design system as the thing that's holding up a product from getting delivered.