Links

Turns out, if you have a website and you think of the browser as a way to navigate documents — rather than a runtime to execute arbitrary code and fetch, compile, and present them — things can be a lot simpler than our tools often prime us to make them.

You can’t write a compelling narrative about the thing you didn’t build. Nobody gets promoted for the complexity they avoided.

Complexity looks smart. Not because it is, but because our systems are set up to reward it.

Your AI coding agent, the one you use to write code, needs to reduce your maintenance costs. Not by a little bit, either. You write code twice as quick now? Better hope you’ve halved your maintenance costs. Three times as productive? One third the maintenance costs. Otherwise, you’re screwed. You’re trading a temporary speed boost for permanent indenture.

[…] The math only works if the LLM decreases your maintenance costs, and by exactly the inverse of the rate it adds code. If you double your output and your cost of maintaining that output, two times two means you’ve quadrupled your maintenance costs. If you double your output and hold your maintenance costs steady, two times one means you’ve still doubled your maintenance costs.

A developer who builds accessible interfaces is more skilled. Say this out loud. Repeat it often. A developer who creates accessible interfaces isn’t doing extra work; they’re doing the work the right way.

No matter how rapidly technology changes, I am coalescing around some core beliefs:

1. Things that are worth doing are worth doing well.
2. Things that are done well require time and effort.
3. You make meaning through the doing.
4. Ideas are common; effort is not.
5. There are no shortcuts.

Harry Roberts on what CSS containment actually is, what each contain value does, and how to use it confidently on real projects without creating hard-to-debug side effects.

Simon Willison on what they mean by “good code”:

• The code works. It does what it’s meant to do, without bugs.
• We know the code works. We’ve taken steps to confirm to ourselves and to others that the code is fit for purpose.
• It solves the right problem.
• It handles error cases gracefully and predictably: it doesn’t just consider the happy path. Errors should provide enough information to help future maintainers understand what went wrong.
• It’s simple and minimal - it does only what’s needed, in a way that both humans and machines can understand now and maintain in the future.
• It’s protected by tests. The tests show that it works now and act as a regression suite to avoid it quietly breaking in the future.
• It’s documented at an appropriate level, and that documentation reflects the current state of the system - if the code changes an existing behavior the existing documentation needs to be updated to match.
• The design affords future changes. It’s important to maintain YAGNI - code with added complexity to anticipate future changes that may never come is often bad code - but it’s also important not to write code that makes future changes much harder than they should be.
• All of the other relevant “ilities” - accessibility, testability, reliability, security, maintainability, observability, scalability, usability - the non-functional quality measures that are appropriate for the particular class of software being developed.

Libraries are bits of other people’s code that I call from my code. Frameworks are other people’s code that call bits of my code.

Writing code has never been the sole activity of a software engineer. The craft has always been figuring out what code to write. Any given software problem has dozens of potential solutions, each with their own tradeoffs. Our job is to navigate those options and find the ones that are the best fit for our unique set of circumstances and requirements.

When you offload your thinking, you might be on-loading someone else’s you’d never agree to — personally or collectively.

Today I learned about the CSS property text-underline-position. As Stuart mentions, the under value forces the underline to sit below all the descenders, giving you a consistent baseline.

a {
	text-underline-position: under;
}

• Good software depends on judgment, communication, and clear abstraction. AI has amplified this.
• AI coding is automation of implementation, so design and stewardship become more important.

Zach Leatherman on frontend architecture and building for longevity amid framework churn:

1. 👏 Hire someone that’s good at HTML and CSS to build components independent of JS frameworks 👏
2. Plug components into a JS framework and layer on behavior later
3. Pay HTML/CSS devs what they deserve for giving part of your codebase longer shelf life than unpasteurized milk

It’s never been a good idea to ship everything you think of. Every addition accretes complexity and comes with a cognitive cost.

Maybe we need to reframe the concept of scarcity from us, the makers of software, to them, the users of software. Their resources are what matter most:

• Attention (too many features and they can’t all be used, or even tried)
• Stability (too much frequent change is an impediment to learning a product)
• Clarity (too many options creates confusion and paralysis)
• Coherence (too many plots and subplots cannot tell a unified story)

Similarly we all love when the swifts visit (beautiful birds), so somebody started a group to get swift nest boxes made and installed collectively, then applied for subsidy funding, then got everyone to chip in such that people who couldn’t afford it could have their boxes paid for, and now suddenly we’re all writing to MPs and following the legislation to include swift nesting sites in new build houses. Etc.

It’s called collective efficacy, the belief that you can make a difference by acting together.

Every time you are inclined to use the word “teach”, replace it with “learn”. That is, instead of saying, “I teach”, say “They learn”. It’s very easy to determine what you teach; you can just fill slides with text and claim to have taught. Shift your focus to determining how you know whether they learned what you claim to have taught (or indeed anything at all!). That is much harder, but that is also the real objective of any educator.

The problem is that Live Text, “Select text in images to copy or take action,” is enabled by default on iOS devices (Settings → General → Language & Region), which can interfere with the contextual menu in Safari. Pressing down on the above link may select the text inside the image instead of selecting the link URL.

Excellent framing from Jim Nielsen, building on Jake Nations’ talk about shipping code we don’t fully understand.

Easy means you can do with little effort.

Simple means you can understand what you do with little effort.

In this excellent, data-driven talk, Alex Russell explains:

• What “winning” means for the web and why it’s a vital cause
• How the web is losing the competition today on mobile, despite its success on desktop
• The path forward: Getting things out of frameworks and using the web platform

Jeremy Wagner and Rachel Andrew explain how to use analytics to select a Baseline target and what to do when you don’t have any real user data.

In cases where there isn’t any real user data:

[…] you can get a general idea of support for different Baseline targets through RUM Archive Insights, even allowing you to filter down to the country level.

They also address a practical follow-up question: what to do about features that don’t meet your chosen Baseline target.

Baseline doesn’t prescribe a specific path here, but the authors suggest a useful framework for categorizing features based on their “failure mode”:

• Enhancement: If the feature is used in an unsupported browser, the experience is not broken. The experience could possibly be degraded, but may not likely be noticeable to the user. Example: loading="lazy".
• Additive: The feature provides some additive benefits that may be noticeable—such as changes in page styling or some functionality. The difference may not be noticeable to users if the feature is unsupported, barring comparison in a browser that does support it. Example: Subgrid
• Critical: If the feature is unsupported, the user will have a negative user experience—possibly even one that’s broken altogether. Example: File System Access API used as a central and necessary feature.

They also highlight Clearleft’s browser support policy, where they target Baseline Widely available while still evaluating whether newer features can be used as progressive enhancements before ruling them out entirely.