This month marks 10 years that I’ve been paid to build web user interfaces. And today is the second anniversary of Guillermo Rauch’s essay Pure UI. Those two anniversaries have led me to reflect on the past and future of UI development.

The past 10 years has seen major improvements in how cross-discipline teams work together to create interfaces. We are much better at thinking about all the different ways an interface should display, depending on the user, their data, their device, and other context.

In contrast, we still struggle to understand how complex interfaces behave given all the possible…

Thanks to an extended holiday vacation and some family illnesses, I was lucky enough to spend two weeks reading about how people and teams learn. It was really interesting.

Why read about learning?

A few months ago, I started working at Stripe. It has felt like Neo getting plugged into the training modules. Except instead of kung fu, I know about complex online business models, brand-new payment methods, and detailed financial regulations. (It might not sound like it, but this has been really fun!)

Stripe has lots of teams working on lots of things. The organization has to understand and adapt to everything going…

Let’s escape the day-to-day to survey what’s coming next

Very early in my programming career, I read a transcript of the talk “You and Your Research”, by Richard Hamming, a mathematician whose name appears in the title of at least six Wikipedia pages for important things he invented.

I was struck by a question which he persistently asked of his colleagues:

What are the important problems of your field?

and the observation he made of the successful scientists around him:

Great scientists have thought through, in a careful way, a number of important problems in their field, and they keep an eye on wondering how to attack them.


I gave a talk at tonight’s ReactJS Denver meetup about Preact.

  • Part 1 describes Preact, why you might want to use it, and the tradeoffs you have to make by not using full React.
  • Part 2 walks through what Preact is doing internally to render and diff a simple application. To many people, the virtual dom and component model seem like deep mysteries that mere mortals shouldn’t try to understand. As I hopefully demonstrated, this isn’t true. It’s a reasonably simple algorithm with a few fiddly little details. …

Or: what Souders’ books didn’t tell you because it only happened in the last two years.

(This is a blog version of a presentation I gave at work a few weeks ago. Because I talked about a couple internal-only things, I can’t put up the video, but I hope it is worthwhile to share the slides and some notes.)

The New Fast

This presentation is focused on bringing you up to date on the best practices for building very fast web sites. It assumes as a pre-requisite that you already know the best practices of a few years ago, which I take to be the two Steve Souders books: High Performance Websites and Even Faster Web Sites. …

And some suggestions from a complete outsider

Yesterday I published a post arguing that more programmers should learn about Concurrent ML. Especially for UI development, CML offers better abstractions and some ready-made solutions for problems that are currently hard or ugly to solve.

But experts in this material may have noticed something odd about my post: I tried very hard to avoid saying “Concurrent ML” except when actually discussing the history of the ideas. Instead, I used names like “synchronizable abstraction” and “protocol” in an effort to make the ideas clearer to those who had never heard of CML.

So, disclaimer: I’m not an expert in CML…

Or: what is Concurrent ML all about?

In this post I’d like to introduce you to a powerful idea for thinking about concurrent programs. Synchronizable abstractions were developed more than twenty years ago by John Reppy in his work creating the language Concurrent ML. Despite that age, and their use in several large-scale systems, synchronizable abstractions remain little known.

Why learn about synchronizable abstractions?

  • They’ll expand your mind by unifying Go’s synchronous channels, Haskell’s MVars, and JavaScript’s promises under one new primitive.
  • They’re already used by programmers with trustworthy taste, like the implementers of Racket and Guile Scheme.
  • Concurrent ML partly inspired React Fiber and can help us understand some of the…

How the virtual dom actually gets rendered to the DOM

So far in this series, we’ve gotten a feel for the Preact repo and looked at the component model from a high level. When we left off last time, we had just finished our picture of the muturally-recursive process of diffing virtual DOM trees and rendering components:

And we had also made a long list of details that this picture left out, like:

  • Crazy DOM special cases, like event binding and XML namespaces
  • Pairing DOM children to vnode children and how key works
  • Recycling DOM nodes for performance
  • Functional and higher-order components
  • Hydration, mount and unmount callbacks, and refs


What distinguishes the React component model, the difference between functional and class-based components, and an overview of how it all works.

In the first post in this series, we started to build a mental model of the Preact codebase, explored some fringe code for utilities and global options, and saw how JSX becomes virtual dom trees. In this second post, we’ll look at the (P)react component model: what it is, how functional and class-based components work, and how the implementation is structured.

What (P)react is really about

Let’s start by dismissing a major misconception about the React UI model (and the parts of it implemented by Preact). I still frequently read that the main benefit of React is the performance benefit of using virtual DOM diffing…

An introduction and gentle first steps in a series where we’ll read the Preact codebase and try to completely understand it.

About the series

I assume you are already familiar with the React component model and virtual dom rendering. A first React book or online course should be enough background. I also assume you know what Preact is and are interested in it either to make your applications load faster or just because you have a better chance of understanding its implementation than reading the whole React codebase. I won’t try to sell you on Preact, and this is the last bit of marketing in the series:

Preact is the fast 3kB alternative to React with the same ES6 API.

I don’t assume any…

Adam Solove

Building the web. Everything should be faster.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store