Posts:

The fundamental reactivity question is: what's changed? Let's dive into the spectrum of reactivity depth and understand the pros and cons of these different strategies.

Reactivity is a creative, opinionated, scrappy corner of front-end JavaScript. Part 1 of a series getting the lay of the land on reactivity - defining some terms, introducing the actors, and marveling at the diversity.

Brooks described a 10-person team structure 50 years ago. It turns out to be a surprisingly good model for working with AI agents- with some important caveats about where it breaks down.

Javascript is single threaded... mostly! Let's look at how you can spin up workers and use them to run things concurrently!

Promises weren't always a platform primitive. Neither were async tasks... kind of. Let's talk about the internals of async tasks and promises and a little bit of their history!

The beginner copies and pastes. The mid-level engineer makes abstractions. The experienced engineer gets stuff done.

Wake up, honey, URLPattern just dropped. It's time to make our own SPA router with web components!

I found myself commiting a cardinal web-dev sin: making a util function to work with dates. This is my story. Learn from me.

I'm celebrating the Highlight API being available in all browsers with some examples!

AI is a hot topic right now. Unfortunately, CEOs and presidents think that AI will replace people, increase efficiencies, and make more money. What is at risk an ethical issue: what do we give up by using AI, and how to we protect human dignity?

We discuss why attributes and properties are often confused, and I share my super-secret of learning and coding.

What started out as adding syntactic sugar to javascript prototypes fundamentally changed javascript forever. Classes are no longer "just" a simpler layer over prototypes. Classes are becoming the expected unit of abstraction and are affecting the way specifications are written. Let's dive deep into classes, objects, and prototypes!

The platform is getting so good that it's not hard for us to get reactive and declarative components going with a few utilities and web components. This is a look at how easy it is to build your own (web components) framework today.

Services and dependency injection feel good with web components. The trick is to come up with a strategy that handles the run-time nature of web components. In this post I suggest a service/DI pattern that works so well with web components and frameworks as well!

Any larger application with web components will need some way to share state and notify consumers that the state has changed. We can 'thread' props down through the DOM tree, or we could use something like context. Front end frameworks have solutions for this: sometimes it's a 'service.' Many times it's a 'store.' Let's talk about reactive stores in web components and start from the simplest possible examples!

Eventually while creating web components you're going to want to use something like render props, where you can let the consumer of your components decide how things look and feel. In web components it requires a bit of a shift in mindset from what we're used to with frameworks. In this post I'm going to share a few strategies to invert control with rendering.

There's been a lot of discussion on whether web components are good or not. But there is one property of web components that might make them the best or the worst solution for your needs.

Man I love the platform. It's gotten really great recently with custom elements, new CSS like anchoring, and new element apis like the popover api. Let's look at making a popover element in this post.

Web components are by default pretty isolated. There are some nice patterns to start sharing state and actions among web components. This article explores the 'provider' pattern

Sometimes you want to check the contents of slots in the shadow DOM and conditionally do things based on what's in them. Can you do this with slots? Yes! It's a little strange though...

We can create form elements with our new web components, but we need to do a few new things: attach internals, handle focus delegation, and register the component as a bona fide form element with a value. It's pretty simple once you get into it- let's make a special text component as an example.

The Shadow DOM allows us a certain level of encapsulation, and there are two options for which mode you'd like the Shadow DOM to be int: open or closed. We'll talk about the differences, the pros and cons, and ultimately whether it's worth it to close the Shadow DOM.

Slots are a fantastic new feature that comes along with the Shadow DOM. You don't even need to make a custom element to use them. Let's look at how to use slots, name slots, and some of the lifecycles and features that come along with them.

The Shadow DOM has scoped styles, which means that styles outside the shadow root don't affect it. But there are some exceptions! We will discuss the `:part()` psuedo-selector, css variables, declarative shadow DOM, and other ways the shadow DOM can be styled!

Let's visit how you would do CSS styles in a web component, and how Lit includes styles.

It can be tedious to wire up reactivity in a web component ourselves. Let's see how easy it can be with Lit

Let's take a look at web component attributes and how you can get your components to react to attribute changes!

We look at why web components are a good solution now, and the very basics on how to make one.