Link tags: a

9214

sparkline

Learn Images

Mat has written this free course for you all about images on the web. Covering image formats, responsive images, and workflows, this is one to keep on speed dial.

WebPageTest’s Guiding Principles - WebPageTest Blog

  1. Make the right thing easy
  2. Always answer “so what”?
  3. Close the gap between “something is wrong” to “we fixed it”

Modern Health, frameworks, performance, and harm – Eric Bailey

A person seeking help in a time of crisis does not care about TypeScript, tree shaking, hot module replacement, A/B tests, burndown charts, NPS, OKRs, KPIs, or other startup jargon. Developer experience does not count for shit if the person using the thing they built can’t actually get what they need.

We’re all trying to find the guy who did this

Imagine the web is a storefront, React is a hot dog car, and here’s Create React App dressed as a hot dog:

HTML is the cornerstone of the web — so why does creating a “React app” produce an empty HTML file? Why are we not taking advantage of the most basic feature of the web—the ability to see content quickly before all the interactive code loads? Why do we wait to start loading the data until after all the client-side code has finished loading?

The Web Platform Is Back

So much ink spilled supposedly explaining what “the web platform” is …when the truth is you can just swap in the “the web” every time that phrase is used here or anywhere else.

Anyway, the gist of this piece is: the web is good, actually.

Chronophoto - The Photographical History Game

This is a fun game—with the same kind of appeal as that Wiki History Game I linked to—where you have to locate photographs in time.

Container Queries and Typography

I feel like we need a name for this era, when CSS started getting real good.

I think this is what I’ve been calling declarative design.

Inside the Globus INK: a mechanical navigation computer for Soviet spaceflight

The positively steampunk piece of hardware used for tracking Alexei Leonov’s Apollo-Soyuz mission.

Efficiency over performance

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.

Software and its Discontents, Part 2: An Explosion of Complexity | Kellan Elliott-McCrea: Blog

Talking primarily to engineering leaders, but also CEOs, VCs, ICs, and other practitioners, the most common response to the question of “has something substantially changed?” is that software, counter intuitively, has gotten harder to build. This is counter intuitive because the tools are orders of magnitude better, the amount of work you can cheaply outsource is nearly miraculous, computers are so damn fast and cheap these days, the quality of resources, much of it free, is off the charts, and the talent pool has exploded, and shows every sign of being smarter and better educated than ever. But software has gotten harder to build in one very particular and important way: it’s gotten more complex.

Kellan nails it:

We’ve developed an aesthetics of complexity: the sense that a good system is a complex one, that you should prefer a SPA over a web page, a distributed system over a simple one, a service over a config file, the idea if you aren’t on the latest technology you’re wasting your time, and potentially damaging your career.

Accessibility strategy – GOV.UK Design System

The primary goals of this strategy are to inform decision-making and enhance the success of accessibility-related activities within the GOV.UK Design System team.

Interestingly, accessibility concerns are put into two categories: theoretical and evidenced (with the evidenced concerns being prioritised):

  1. Theoretical: A question or statement regarding the accessibility of an implementation within the Design System without evidence of real-world impact.
  2. Evidenced: Sharing new research, data or evidence showing that an implementation within the Design System could cause barriers for disabled people.

clamp() Calculator · Chris Burnell

Like a little mini Utopia:

Handy little tool for calculating viewport-based clamped values.

Hand-thrown frontends - Robb Owen

I’ve personally never really seen frontend as an assembly job. Lego is admittedly awesome, but for me the mental model of assembling Lego bricks in the required order until a Jira ticket can be marked as “done” feels too linear and too rigid for how I like to work. And that’s not to mention the pain that comes when you have to partially dismantle your bricks to correct some earlier misstep.

I like the pottery analogy.

Patrick / articles / Is the developer experience on the Web so terrible?

Over the past 10 years or so, we’ve slowly but very surely transitioned to a state where frameworks are the norm, and I think it’s a problem.

I concur.

Use the frameworks and libraries that make sense for you to deliver the best UX possible. But also learn the web platform from the ground up. Take time to understand how web browsers work and render webpages. Learn HTML, CSS, JavaScript. And keep an eye, if you can, on the new things.

Pattern Wise, System Foolish

A library of UX components is one common part of a design system, but the system itself is something bigger. A good system is also a shared set of strategies for solving visual and interactive communication challenges, a playbook rather than a script.

I like this way of putting it:

The problem is that treating a design system as a pantry full of widgets is, in and of itself, a failure of both craft and imagination. Think of it like a language: if a writer’s only engagement with it is grabbing words from the dictionary and heaping them together until “message” is achieved, things are going to suck. Language is more than a bag of words.

Henry From Online | How To Make a Website

Write meaningful HTML that communicates the structure of your document before any style or additional interactivity has loaded. Write CSS carefully, reason your methodology and stick to it, and feel empowered to skip frameworks. When it comes time to write JavaScript, write not too much, make sure you know what it all does, and above all, make sure the website works without it.

The whole article is great, and really charmingly written, with some golden nuggets embedded within, like:

  • You’ll find that spending more time getting HTML right reveals or even anticipates and evades accessibility issues. It’s just easier to write accessible code if it’s got semantic foundations.
  • In my experience, you will almost always spend more time overriding frameworks or compromising your design to fit the opinions of a framework.
  • Always style from the absolute smallest screen your content will be rendered on first, and use @media (min-width) queries to break to layouts that allow for more real estate as it becomes available.
  • If your site doesn’t work without JavaScript, your site doesn’t work.
  • Always progressively enhance your apps, especially when you’re fucking with something as browser-critical as page routing.

CSS { In Real Life } | Disentangling Frameworks

I just quoted Chris saying:

I think some tools are a good idea. But as few as possible, and the easier they are to stop using, the better.

Now Michelle asks:

Suppose we want to stop using Tailwind one day?

Turns out it’s a bit of a roach motel, much like most JavaScript frameworks: you can get in but you can’t easily get out.

So whenever possible, the safest, and most future-proof bet is to use the native features of the web platform.

Scalable CSS - Chris Coyier

Wise words:

Myself, I think some tools are a good idea. But as few as possible, and the easier they are to stop using, the better.

To paraphrase Michael Pollan:

Write CSS, not too much, mostly vanilla.

Line heights in CSS work better with ratios | Andy Bell

There’s a broader point here about declarative design:

Setting very specific values may feel like you’re in more control, but you’re actually rescinding control by introducing fragility in the form of overly-specific CSS.

Colin Devroe - Blogging is alive and well

The past, present and future of blogs.