For 3 decades now (indeed a little more) my life has revolved around the Web. Developing for it, developing software to help others develop for it, writing about it, teaching about it, talking about it.
Curiously the last couple of weeks’ roundups have had some backwards looking aspects to them–last week we had a refresher and history on web typography, and a look at the history of document formats like .docx, .ppt, and pdf. This week we look at image maps, some prehistoric CSS and JavaScript, and an anniversary for the Web, which has me both grateful and enraged–but you’ll have to read on to know why.
Plus plenty of JavaScript, CSS, HTML, UX, animations, Product Design–and some thoughts about the detrimental impact of LLMs on the craft of coding.
I genuinely hope you find my roundup useful-I certainly do.
You can subscribe to our newsletter, and get these, and only these, once a week in your inbox.
For me, the trouble was always that this is contextual, but that context isn’t meaningful to us developers so much as it’s meaningful to JavaScript. You and I are used to telling JavaScript what things are: this is the identifier we typed, where we typed it, scoped to the pair of brackets we typed around it, and it has the value we assigned to it.
That’s not the case with this, which is—brace for it—a keyword that refers to the object bound to the function where this is invoked at the time when that function is called.
That is an absolute nightmare of a sentence, I know, but bear with me. It breaks down to two important concepts: this references the object bound to a function, and the object referenced by this is determined at the time a function is called. Once you’ve got a handle on those two aspects, this is— well, still a little weird, but the knowable kind of weird.
So what is the element? Originally devised by Apple to power something called “Dashboard widgets” (I don’t know what they are but they sound awful), it was later standardized as part HTML5. The element, like , is a kind of replaced element. That is, where supported and initialized correctly, it represents (is replaced by) embedded content.
At this point, the use of artificial intelligence and machine learning models in software has a long history. But the past three years really accelerated the evolution of “AI products”. From behind the scenes models to chat to agents, here’s how I’ve seen things evolve for the AI-first companies we’ve built during this period.
Software release of WWW into public domainDate: 30 Apr 1993 The document that officially put the World Wide Web into the public domain on 30 April 1993.
There are thousands of words I could write about this document–one I have had the privilege of holding in my own hands (inside a protective sleeve). It is 32 years old today. In 1993, CERN relinquished its rights to the World Wide Web, creating the modern world. This extraordinary act of, well generosity doesn’t begin to do justice to it, by Tim Berners Lee and Robert Caillau brought us the Web. Their generosity has been traduced by the companies and individuals that solely exist and lay claim to their extraordinary wealth and power almost entirely because of it. Enclosers gotta enclose I guess. But great good has come of it as well. I’ll try to focus on that today.
Let’s run through a quick refresher. Image maps date all the way back to HTML 3.2, where, first, server-side maps and then client-side maps defined clickable regions over an image using map and area elements. They were popular for graphics, maps, and navigation, but their use declined with the rise of CSS, SVG, and JavaScript.
A bit more web design nostalgia today. Most developers these days have very likely never heard of an image map (we cover map JavaScript below, an entirely different thing that you are more likely to have heard of).
These HTML elements are a way of associating links with regions of an image. In the days before CSS layout, before web fonts, almost all web design was done by rendering your design into an image (or images). And so making various parts of an image into links was very powerful.
Here Andy Clarke revisits the map element (it’s still part of HTML–like almost everything that ever as been) for a project he’s currently working on. Who knows, one day it might be the right tool for something you are working on.
Instead of that deep immersion where I’d craft each function, I’m now more like a curator? I describe what I want, evaluate what the AI gives me, tweak the prompts, and iterate. It’s efficient, yes. Revolutionary, even. But something essential feels missing — that state of flow where time vanishes and you’re completely absorbed in creation. If this becomes the dominant workflow across teams, do we risk an industry full of highly productive yet strangely detached developers?
Curiously I have found myself more in a flow state in recent months than in a long time while using LLMs as part of my software development process. But, as other things we’ve linked to recently have made clear, the nature of software engineering and development is undergoing a profound transformation. I think it’s very far from clear where we end up–my instinct is people will be looking at and writing or at least editing code (in the literary sense as much as the software sense) for some time to come–but I my be wrong about that.
A few years back, when I was digging intensely into how design systems mature, I stumbled on the concept of a design system origin story. There are two extreme origin stories and an infinite number of possibilities between. On one hand you have the grassroots system, where individuals working on digital products are simply trying to solve their own daily problems. They’re frustrated with having to go cut and paste elements from past designs or with recreating the same layouts over and over, so they start to work more systematically. On the other hand, you have the top down system, where leadership is directing teams to take a more systematic approach, often forming a small partially dedicated core team to tackle some centralized assets and guidelines for all to follow. The influences in those early days bias a design system in interesting and impactful ways.
Ben Callahan considers how biases get embedded in design systems and how to reason about and address that.
Good vs Great Animations
Good vs Great AnimationsWe all want our UIs to feel great and animations can definitely help with that. But how do you actually create a great animation? This article is a collection of practical tips to help you go from good to great animations.
Since the rollover image swap effect (JavaScript’s first killer use case nearly 30 years ago) and the CSS hover effect (an early gateway drug for CSS), animation has been an important feature of web design. The technologies we have now-the long established transitions and animations in CSS, various animation libraries, and more recently View Transitions (welcome React developers, good to have you on board)– give us great power when it comes to animation.
I’ve been giving a lot of thought to how to make CSS files modular in the UI library without requiring any sort of build system.Today I want to talk about how the CSS @layer at-rule makes this a lot easier! Let’s dig in…
Quick quiz–how long has Cascade Layers been widely available? Even I was surprised it has been in all evergreen browsers since early 2022. But it feels like they are underutilised (guilty as charged here too). Here Chris Ferdinandi gets you tried with cascade layers. We also have some talks here at Conffab on the topic.
This report from ArcTouch and Fable assesses the accessibility of 50 leading Android and iOS apps across five industries: Food & Delivery, Payments, Fitness, Shopping, and Streaming.
Our analysis of app accessibility reveals a concerning reality: The vast majority of apps are failing users with disabilities.
72% of those who rely on any of the four assistive technologies we tested may have a poor or failing app experience in at least one step of a typical user journey.
How is accessibility going on Mobile? This report from ArcTouch and Fable concludes that ‘while accessibility awareness is growing, overall app performance remains “fair,” with significant room for improvement even in the best-performing industry’. Something that could have been written any time about the Web for the last 30 years sadly.
A decent app is a fully local web app—everything, including the LLM, runs in the user’s browser.
A decent app respects users—it doesn’t track, manipulate, show ads, or send data elsewhere. Our architecture is built to guarantee this.
Create a “Hello, World” decent app in 30 seconds with our open-source tool. This gives you a React-based web app with UI, an LLM endpoint, and local data storage.
Local First is an architecture we’ve covered a little, and which is gaining some traction. Decent Apps are an approach to developing (and deploying) privacy preserving, low cost (to developers and users) apps that can even use LLMs locally.
Navigating Frontend System Design Interviews with the CCDAO Framework
So, how do you effectively prepare for a frontend system design interview when you’re unsure where to begin? That’s exactly what this newsletter series is about. My goal is to help you structure your knowledge so you can develop a complete mental map of frontend architecture. This will not only enhance your ability to tackle new challenges but also help you communicate effectively during interviews.
Frameworks can act as roadmaps, ensuring you cover essential topics that interviewers care about—making it clearer that you and the interviewer speak the same technical language. Of course, interviewer styles vary, and there are factors beyond your control, but you can control how well you structure and deliver your thoughts.
Let’s dive into the CCDAO framework—five essential steps to guide you through a frontend system design interview. Memorizing this acronym will help you remain systematic and avoid missing important considerations.
Junto Qiu outlines CCDAO, which stands for “Collect information, Component Structure, Data Modelling, API Design and Optimisation Considerations”, a simple framework that can help you to organise your thoughts during system design interviews with a focus on the front end.
What’s a CSS boilerplate? Like an HTML boilerplate, a CSS boilerplate is one or more CSS files you want to include in every project. For most people, this is just a reset style sheet; for others, it also contains additional base or even component styles.
We take it a step further. This boilerplate uses a reset stylesheet and comes with pre-defined rules, but primarily, it establishes a structure using Cascade Layers, giving you more control over the cascade.
React Server Components (in?)famously has no API surface. It’s an entire programming paradigm largely stemming from two directives:
‘use client’
‘use server’
I’d like to make a bold claim that their invention belongs in the same category as structured programming (if / while), first-class functions, and async/await. In other words, I expect them to survive past React and to become common sense.
When I use AI to build software I feel like I can create almost anything I can imagine very quickly. AI feels like a power tool. It’s a lot of fun.
Many AI apps don’t feel like that. Their AI features feel tacked-on and useless, even counter-productive.
I am beginning to suspect that these apps are the “horseless carriages” of the AI era. They’re bad because they mimic old ways of building software that unnecessarily constrain the AI models they’re built with.To illustrate what I mean by that, I’ll start with an example of a badly designed AI app.
As many have observed about new forms of media, they emerge form existing media and in their early stages ‘ape’ the forms of their predecessors. The same argues Pete Koomen is true for many AI products, and their UI and functionality. A helpful way of thinking about how to build products with AI.
Hello, and welcome to CSS Hell, where you will be subjected to 15 unimaginably torturous CSS puzzles. “What did I do to deserve this?”, you ask. But you know perfectly well: you blashpemized Cascading Style Sheets. I saw that time your friends were complaining about CSS and you piled on with “CSS isn’t even a real programming language”. It is. I saw you upvote that Reddit meme about vertically aligning a div. Just use a flexbox. I saw you chuckle sensibly at those CSS Is Awesome designs. I couldn’t stand to let Håkon Wium Lie’s divine creation be slandered in this way, so I decided to show the nonbelievers like you the wrath of CSS’s unhinged power.
I saw this post on Reddit about a JavaScript coding assessment and it got me thinking. A common task developers perform is iterating over arrays. And two of the most frequently used methods for this are map() and forEach(). Both seem similar, but the differences can significantly affect how your code behaves. Let’s take a closer look at both and why I think map() wins out as the better choice when transforming data.
To a man with a hammer, everything is a nail–and for developers (I include myself in this) once we learn an approach to solving a problem, such as iterating over an array, we tend to keep using that approach even when better alternatives emerge. Here Matt Smith looks at forEach and map for iterating over arrays. When to use each approach and why.
Why you need to know your site’s performance plateau (and how to find it)
“I made my pages faster, but my business and user engagement metrics didn’t change. WHY???”
“How do I know how fast my site should be?”
“How can I demonstrate the business value of page speed to people in my organization?”
The answers might lie with identifying and understanding the performance plateau for your site.
What is the “performance plateau”?
The performance plateau is the point at which changes to your website’s rendering metrics (such as Start Render and Largest Contentful Paint) cease to matter because you’ve bottomed out in terms of business and user engagement metrics.
Performance is well know to be highly correlated with measurable business outcomes–until it’s not. But why? Tammy Everts discusses the performance plateau.
Great reading, every weekend.
We round up the best writing about the web and send it your way each Friday.
