This would be a fascinating experiment to run in Firefox nightly! This is in response to that post I wrote about third-party scripts.
I’m really pleased with how this turned out. I wasn’t sure if anybody was going to be interested in the deep dive into history that I took for the first 15 or 20 minutes, but lots of people told me that they really enjoyed that part, so that makes me happy.
The Web is smothering in useless images. These clichéd, stock images communicate absolutely nothing of value, interest or use. They are one of the worst forms of digital pollution because they take up space on the page, forcing more useful content out of sight. They also slow down the site’s ability to download quickly.
Worlds of scarcity are made out of things. Worlds of abundance are made out of dependencies. That’s the software playbook: find a system made of costly, redundant objects; and rearrange it into a fast, frictionless system made of logical dependencies. The delta in performance is irresistible, and dependencies are a compelling building block: they seem like just a piece of logic, with no cost and no friction. But they absolutely have a cost: the cost is complexity, outsourced agency, and brittleness. The cost of ownership is up front and visible; the cost of access is back-dated and hidden.
Timelines of people, interfaces, technologies and more:
30 years of facts about the World Wide Web.
Cassie’s excellent talk on SVG animation is well worth your time.
The climate crisis as technical debt:
What we’re dealing with is hundreds of years of something that software world calls technical debt. Technical debt is the shortcuts and trade-offs engineers use to get something done either cheaper or in less time, which inevitably creates the need to fix systems later, often at great cost or difficulty.
Some technical debt is understood up front, some comes from builders being ignorant of the system they are working in. Most of our planet’s infrastructure is mired in huge amounts of technical debt, most of which we didn’t know we were signing up for at the time, some of which we’re just incurring recklessly as we go along, unable to face the scale of the problem and pushing it off on the next generation.
This is quite a beautiful homage to Kubrick’s masterpiece.
Here’s the talk that Remy and I gave at Fronteers in Amsterdam, all about our hack week at CERN. We’re both really pleased with how this turned out and we’d love to give it again!
Facebook and even Instagram are at odds with the principles of the open web.
Decomputerization doesn’t mean no computers. It means that not all spheres of life should be rendered into data and computed upon. Ubiquitous “smartness” largely serves to enrich and empower the few at the expense of the many, while inflicting ecological harm that will threaten the survival and flourishing of billions of people.
Frank yearns for just-in-time computing:
With each year that goes by, it feels like less and less is happening on the device itself. And the longer our work maintains its current form (writing documents, updating spreadsheets, using web apps, responding to emails, monitoring chat, drawing rectangles), the more unnecessary high-end computing seems. Who needs multiple computers when I only need half of one?
The transcript of Andy’s talk from this year’s State Of The Browser conference.
I don’t think using scale as an excuse for over-engineering stuff—especially CSS—is acceptable, even for huge teams that work on huge products.
The video of a talk in which Mark discusses pace layers, dogs, and design systems. He concludes:
- Current design systems thinking limits free, playful expression.
- Design systems uncover organisational disfunction.
- Continual design improvement and delivery is a lie.
- Component-focussed design is siloed thinking.
It’s true many design systems are the blueprints for manufacturing and large scale application. But in almost every instance I can think of, once you move from design to manufacturing the horse has bolted. It’s very difficult to move back into design because the results of the system are in the wild. The more strict the system, the less able you are to change it. That’s why broad principles, just enough governance, and directional examples are far superior to locked-down cookie cutters.
When you ever had to fix just a few lines of CSS and it took two hours to get an ancient version of Gulp up and running, you know what I’m talking about.
I feel seen.
When everything works, it feels like magic. When something breaks, it’s hell.
I concur with Bastian’s advice:
I have a simple rule of thumb when it comes to programming:
less code === less potential issues
And this observation rings very true:
This dependency hell is also the reason why old projects are almost like sealed capsules. You can hardly let a project lie around for more than a year, because afterwards it’s probably broken.
Get an idea of how much your website is contributing to the climate crisis.
In total, the internet produces 2% of global carbon emissions, roughly the same as that bad boy of climate change, the aviation industry.
A handy tool for tweaking the animations in your SVGs.
The way you build web pages—using
IntersectionObserver, for example—can have a direct effect on the climate emergency.
Webpages can be good citizens of battery life.
It’s important to measure the battery impact in Web Inspector and drive those costs down.
If you treat data as a constraint in your design and development process, you’ll likely be able to brainstorm a large number of different ways to keep data usage to a minimum while still providing an excellent experience. Doing less doesn’t mean it has to feel broken.