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.
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!)
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.
(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.)
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. …
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…
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.
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:
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.
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…
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…