Adoption. — Ethan Marcotte
Ethan highlights a classic case of the McNamara Fallacy—measuring adoption of design system components.
Ethan highlights a classic case of the McNamara Fallacy—measuring adoption of design system components.
I quite like this change of terminology when it comes to making fast websites. After all, performance can sound like a process of addition, whereas efficiency can be a process of subtraction.
The term ‘performance’ brings to mind exotic super-cars suitable only for impractical demonstrations (or ‘performances’). ‘Efficiency’ brings to mind an electric car (or even better, a bicycle), making effective use of limited resources.
I love this list of ever-increasing timelines. All that’s missing is the time since the Carrington Event, just to remind us what could happen when the next one hits.
My talk, Building, was about the metaphors we use to talk about the work we do on the web. So I’m interested in this analysis of the metaphors used to talk about markup:
- Data is documents, processing data is clerking
- Data is trees, processing data is forestry
- Data is buildings, processing data is construction
- Data is a place, processing data is a journey
- Data is a fluid, processing data is plumbing
- Data is a textile, processing data is weaving
- Data is music, processing data is performing
This is a story about pizza and geometry.
The interactive widget here really demonstrates the difference between showing and telling.
A fascinating interactive journey through biometrics using your face.
While I’ve always been bothered by the downsides of SPAs, I always thought the gap would be bridged sooner or later, and that performance concerns would eventually vanish thanks to things like code splitting, tree shaking, or SSR. But ten years later, many of these issues remain. Many SPA bundles are still bloated with too many dependencies, hydration is still slow, and content is still duplicated in memory on the client even if it already lives in the DOM.
Yet something might be changing: for whatever reason, it feels like people are finally starting to take note and ask why things have to be this way.
Interesting to see a decade-long perspective. I especially like how Sacha revisits and reasseses design principles from ten years ago:
- Data on the Wire. Don’t send HTML over the network. Send data and let the client decide how to render it.
Verdict: 👎
It’s since become apparent that you often do need to send HTML over the network, and things seem to be moving back towards handling as much as possible of your HTML compilation on the server, not on the client.
This version of Roboto from Font Bureau is a very variable font indeed.
One of my favourite episodes of the Clearleft podcast is on measuring design. This post from Chris is a complements that episode in a sensible and practical style.
What gets measured gets done. You are what you measure. Measurement eliminates argument. If you work in an environment that puts store in these oft-quoted business adages then I urge you to take a moment to challenge your calculations. Let’s review our metrics to ensure they can stand up and be counted.
You had me at “beautifully resilient apps with progressive enhancement”.
This is a great clear walkthrough of enhancing a form submission. A lot of this seems like first principles to me, but if you’ve only ever built single page apps, then thinking about a server-submission process first might well be revelatory.
A personal site, or a blog, is more than just a collection of writing. It’s a kind of place - something that feels like home among the streams. Home is a very strong mental model.
In which Rob takes a deep dive into isometric projection and then gets generative with it.
I sometimes imagine a chair made by someone who sits all twisted. Sitting in that chair yourself, you couldn’t help but to sit in the same way.
When a designer designs an object, their stance will be encoded and transmitted to the user. Imposed.
Is culture really passed on like this, not just with chairs or superheroes, but in a general sense?
Out of all of these metaphors, the two most enduring are paper and physical space.
I’ve noticed a trend in recent years—a trend that I’ve admittedly been part of myself—where performance-minded developers will rebuild a site and then post a screenshot of their Lighthouse score on social media to show off how fast it is.
Mea culpa! I should post my CrUX reports too.
But I’m going to respectfully decline Phil’s advice to use any of the RUM analytics providers he recommends that require me to put another script
element on my site. One third-party script is one third-party script too many.
The discussions around data policy still feel like they are framing data as oil - as a vast, passive resource that either needs to be exploited or protected. But this data isn’t dead fish from millions of years ago - it’s the thoughts, emotions and behaviours of over a third of the world’s population, the largest record of human thought and activity ever collected. It’s not oil, it’s history. It’s people. It’s us.
I hadn’t come across this before—run Lighthouse tests on your pages from six different locations around the world at once.
This is a great HTML boilerplate, with an explanation of every line.
You catch more flies with honey than Tailwind.