A stack is also technical debt, non-transferable knowledge, accelerated obsolescence, and vendor lock-in. That means fragility and overall unnecessary complication. Popular stacks inevitably turn into cargo cults that build in spite of the web, not for it.
The web platform does not require build toolchains. Always default to, and regress to, the fundamentals of CSS, HTML, and JavaScript. Those core standards are the web stack.
Web development follows a familiar cycle. First we glue together a solution with whatever we have — JavaScript, image hacks, Flash, anything. Then the platform matures, and CSS or HTML eventually makes that same workaround native. Rounded corners, custom fonts, smooth scrolling, sticky positioning: all of these started as JavaScript-heavy hacks before CSS turned them into a single declaration.
We are in another one of those transition moments. A new wave of long-requested CSS features is finally landing, and many of them are explicitly designed to replace patterns that used to require JavaScript. Not as approximations — as first-class platform primitives that handle the edge cases, run in the right thread, and need zero dependencies.
We value learning. We value the merits of language design, type systems, software maintenance, levels of abstraction, and yeah, if I’m honest, minute syntactical differences, the color of the bike shed, and the best way to get that perfectly smooth shave on a yak. I’m not sure what we’re called now, “heirloom programmers”?
Do I sound like a machine code programmer in the 1950s refusing to learn structured programming and compiled languages? I reject that comparison. I love a beautiful abstraction just as much as I love a good low-level trick.
If the problem is that we’ve painted our development environments into a corner that requires tons of boilerplate, then that is the problem. We should have been chopping the cruft away and replacing it with deterministic abstractions like we’ve always done. That’s what that Larry Wall quote about good programmers being lazy was about. It did not mean that we would be okay with pulling a damn slot machine lever a couple times to generate the boilerplate.
I don’t like magic.
I’m not talking about acts of prestidigitation and illusion. I mean the kind of magic that’s used to market technologies. It’s magic. It just works. Don’t think about it.
I’ve written about seamless and seamful design before. Seamlessness is often touted as the ultimate goal of UX—“don’t make me think!”—but it comes with a price. That price is the reduction of agency.
When it comes to front-end development, my distrust of magic tips over into being a complete control freak.
I don’t like using code that I haven’t written and understood myself. Sometimes its unavoidable. I use two JavaScript libraries on The Session. One for displaying interactive maps and another for generating sheet music. As dependencies go, they’re very good but I still don’t like the feeling of being dependant on anything I don’t fully understand.
I can’t stomach the idea of using npm to install client-side JavaScript (which then installs more JavaScript, which in turn is dependant on even more JavaScript). It gives me the heebie-jeebies. I’m kind of astonished that most front-end developers have normalised doing daily trust falls with their codebases.
While I’m mistrustful of libraries, I’m completely allergic to frameworks.
Often I don’t distinguish between libraries and frameworks but the distinction matters here. 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.
Think of React. In order to use it, you basically have to adopt its idioms, its approach, its syntax. It’s a deeper level of dependency than just dropping in a regular piece of JavaScript.
I’ve always avoided client-side React because of its direct harm to end users (over-engineered bloated sites that take way longer to load than they need to). But the truth is that I also really dislike the extra layer of abstraction it puts between me and the browser.
Now, whenever there’s any talk about abstractions someone inevitably points out that, when it comes to computers, there’s always some layer of abstraction. If you’re not writing in binary, you don’t get to complain about an extra layer of abstraction making you uncomfortable.
I get that. But I still draw a line. When it comes to front-end development, that line is for me to stay as close as I can to raw HTML, CSS, and JavaScript. After all, that’s what users are going to get in their browsers.
My control freakery is not typical. It’s also not a very commercial or pragmatic attitude.
Over the years, I’ve stopped doing front-end development for client projects at work. Partly that’s because I’m pretty slow; it makes more sense to give the work to a better, faster developer. But it’s also because of my aversion to React. Projects came in where usage of React was a foregone conclusion. I wouldn’t work on those projects.
I mention this to point out that you probably shouldn’t adopt my inflexible mistrustful attitude if you want a career in front-end development.
Fortunately for me, front-end development still exists outside of client work. I get to have fun with my own website and with The Session. Heck, they even let me build the occasional hand-crafted website for a Clearleft event. I get to do all that the long, hard stupid way.
Meanwhile in the real world, the abstractions are piling up. Developers can now use large language models to generate code. Sometimes the code is good. Sometimes its not. You should probably check it before using it. But some developers just YOLO it straight to production.
That gives me the heebie-jeebies, but then again, so did npm. Is it really all that different? With npm you dialled up other people’s code directly. With large language models, they first slurp up everyone’s code (like, the whole World Wide Web), run a computationally expensive process of tokenisation, and then give you the bit you need when you need it. In a way, large language model coding tools are like a turbo-charged npm with even more layers of abstraction.
It’s not for me but I absolutely understand why it can work in a pragmatic commercial environment. Like Alice said:
Knitting is the future of coding. Nobody knits because they want a quick or cheap jumper, they knit because they love the craft. This is the future of writing code by hand. You will do it because you find it satisfying but it will be neither the cheapest or quickest way to write software.
But as Dave points out:
And so now we have these “magic words” in our codebases. Spells, essentially. Spells that work sometimes. Spells that we cast with no practical way to measure their effectiveness. They are prayers as much as they are instructions.
I shudder!
But again, this too is nothing new. We’ve all seen those codebases that contain mysterious arcane parts that nobody dares touch. coughWebpackcough. The issue isn’t with the code itself, but with the understanding of the code. If the understanding of the code was in one developer’s head, and that person has since left, the code is dangerous and best left untouched.
This, as you can imagine, is a maintenance nightmare. That’s where I’ve seen the real cost of abstractions. Abstractions often really do speed up production, but you pay the price in maintenance later on. If you want to understand the codebase, you must first understand the abstractions used in the codebase. That’s a lot to document, and let’s face it, documentation is the first casuality of almost every project.
So perhaps my aversion to abstraction in general—and large language models in particular—is because I tend to work on long-term projects. This website and The Session have lifespans measured in decades. For these kinds of projects, maintenance is a top priority.
Large language model coding tools truly are magic.
I don’t like magic.
The datalist element is all fucked up on iOS. Again.
I haven’t “upgraded” my iPhone to iOS 26 and I have no plans to. The whole Liquid Glass thing is literally offputting. So I wouldn’t have known about the latest regression in Safari if a friend hadn’t texted me about the problem.
He was trying to do a search on The Session. He was looking for the tune, The Road To Town. He started typing this into the form on the home page of the site. He got as far as “The Road To”. That’s when the entire input was obscured by a suggestion from the associated datalist.
This is incredibly annoying and seems to be a pattern of behaviour for Safari. Features are supported …technically. But the implementation is so buggy as to be unusable.
I’ll probably have to do some user-agent sniffing, which I hate. And it won’t be enough to just sniff for Safari on iOS 26. Remember that every browser on iOS is just Webkit in a trenchcoat.
Time to file a bug and then wait God knows how long for an update to get rolled out.
Update: I filed a bug, but in the meantime it looks like user-agent sniffing is going to be impossible.
You might not need (much) JavaScript for these common interface patterns.
While we all love the power and flexibility JS provides, we should also respect it, and our users, by limiting its use to only what it needs to do.
Yes! Client-side JavaScript should do what only client-side JavaScript can do.
I like the idea of adding this to personal websites:
Mastodon shows an “Alt” button in the bottom right of images that have associated alt text. This button, when clicked, shows the alt text the author has written for the image.
And by LLMS I mean: (L)ots of (L)ittle ht(M)l page(S).
I really like this approach: using separate pages instead of in-page interactions. I remember Simon talking about how great this works, and that was a few years back, before we had view transitions.
I build separate, small HTML pages for each “interaction” I want, then I let CSS transitions take over and I get something that feels better than its JS counterpart for way less work.
- Violates User Expectations
- Causes Motion Sickness
- Reduces Accessibility for Disabled Users
- Inconsistent Performance Across Devices
- Impairs Usability for Power Users
- Increases Page Load Times
- Breaks Native Browser Features
- Makes Scroll Position Unclear
- Adds Maintenance Overhead
- Disrespects the User’s Control
I hold this truth to be self-evident: the larger the abstraction layer a web developer uses on top of web standards, the shorter the shelf life of their codebase becomes, and the more they will feel the churn.
The datalist element is good. It was a bit bumpy there for a while, but browser implementations have improved over time. Now it’s by far the simplest and most robust way to create an autocompleting combobox widget.
Hook up an input element with a datalist element using the list and id attributes and you’re done. You can even use a bit of Ajax to dynamically update the option elements inside the datalist in response to the user’s input. The browser takes care of all the interaction. If you try to roll your own combobox implementation, it’s almost certainly going to involve a lot of JavaScript and still probably won’t account for all use cases.
Safari on iOS—and therefore all browsers on iOS—didn’t support datalist for quite a while. But once it finally shipped, it worked really nicely. The options showed up just like automplete suggestions above the keyboard.
But that broke a while back.
The suggestions still appeared, but if you tapped on one of them, nothing happened. The input element didn’t get updated. You had to tap on a little downward arrow inside the input in order to see the list of options.
That was really frustrating for anybody on iOS using The Session. By far the most common task on the site is searching for a tune, something that’s greatly (progressively) enhanced with a dynamically-updating datalist.
I just updated to iOS 18 specifically to see if this bug has been fixed, and it has:
Fixed updating the input value when selecting an
optionfrom adatalistelement.
Hallelujah!
But now there’s some additional behaviour that’s a little weird.
As well as showing the options in the autocomplete list above the keyboard, Safari on iOS—and therefore all browsers on iOS—also pops up the options as a list (as if you had tapped on that downward arrow). If the list is more than a few options long, it completely obscures the input element you’re typing into!
I’m not sure if this is a bug or if it’s the intended behaviour. It feels like a bug, but I don’t know if I should file something.
For now, I’ve updated the datalist elements on The Session to only ever hold three option elements in order to minimise the problem. Seeing as the autosuggest list above the keyboard only ever shows a maximum of three suggestions anyway, this feels like a reasonable compromise.
A depressing but accurate description of the economics of web development.
I concur:
Just because a user interface uses 3D-buttons and some shading doesn’t mean that it has to look tacky. In fact, if you have to make the choice between tacky-but-usable and minimalistic-but-hard-to-use, tacky is the way to go. You don’t have to make that choice though: It’s perfectly possible to create something that is both good-looking and easy to use.
This is a wonderfully in-depth interactive explainer on touch target sizes, with plenty of examples.
If there’s one takeaway from all this, it’s that the web is a flexible medium where any number of technologies can be combined in all sorts of interesting ways.
I love, love, love the deep thinking that Lea has put into this, really digging into the guts of what design does.
Overfitting happens when solutions don’t generalize sufficiently and is a hallmark of poor design. Eigensolutions are the opposite: solutions that generalize so much they expose links between seemingly unrelated use cases. Designing eigensolutions takes a mindset shift from linear design to composability.
Lea ties this into web standards too. It’s really helped clarify for me why I want more declarative options for common use cases (like a share button)—it’s about raising the ceiling without raising the floor.
Claire L. Evans has written a beautiful piece on the difference between growth and scalability:
Life is nonhierarchical, and it shirks top-down control. But scalability relies on hierarchy, on the isolation of elements stripped of history and context. It is predicated on the assumption that nature is little more than a raw material to be processed and commodified until it is spent. This is, of course, unsustainable — at any scale.
Bruce raises an interesting question with media playing in popovers—shouldn’t the media pause when the popover is closed? I agree with Bruce that this is a common use case that should be covered declaratively.
A plea to let users do web things on websites. In other words, stop over-complicating everything with buckets of JavaScript.
Honestly, this isn’t wishlist isn’t asking for much, and it’s a damning indictment of “modern” frontend development that we’ve come to this:
- Let me copy text so I can paste it.
- If something navigates like a link, let me do link things.
- …
My week at the Belfast TradFest culminated in a cathedral.
Everyone who has been taking classes during the week made their way to Belfast cathedral for a communal finish. Every class played a short piece to round out their week of workshops.
The whole experience was quite lovely. At one point, I was unexepectedly moved to tears by the performance of the cello class (not a common instrument in Irish traditional music).
When I got home, I decided to send a message to Neil Martin who taught that class. It was just a quick line or two to tell him how special it was.
He responded, saying he found the whole experience of the closing concert very moving and powerful.
I was glad I sent that note of thanks.
Then, a day later, I received my own note of thanks. It wasn’t music-related. Someone I had met and chatted with at a conference last year told me that they had just watched the video of my talk, The State Of The Web. They were very moved by it. Then they took the time to send me an email to tell me. As you can imagine, I was really touched to be on the receiving end of that.
I resolved that I would do it more myself. Whether it’s a piece of music, writing, or anything else, I’m going to try to remember to pass on my appreciation more often.
That’s a good place to end, isn’t it? A nice heart-warming reminder that small acts of thoughtfulness can make a big difference to someone else’s well-being.
But there’s a corollary to that lesson. Acts of thoughtlessness will almost certainly make a very big difference to someone else’s well-being.
This is something I know in theory but struggle with in practice. I’ve experienced the regret of wishing I hadn’t acted so stupidly in my dealings with work colleagues, for example.
There’ll be some discussion happening on a topic that I might have strong feelings about, and I let those strong feelings take over my behaviour. Quite frankly, I act like a dickhead.
Sure, I can analyse it in hindsight and identify what causes this unintended behaviour, but that sounds an awful lot like excusing it. In the end, it doesn’t matter what my intentions were or what the circumstances were. It’s my actions that matter. More specifically, it’s the effect of my actions on other people that matter.
So, yeah, I am going to try to do more of those small thoughtful acts, like sending thank-you messages to people. But frankly, that’s a stretch goal. The shamefully low bar I first have to pass is to simply treat people with the respect they deserve. To paraphrase the Hypocratic oath: first, don’t be an asshole.
There’s an oft-quoted adage:
They may forget what you said, but they will never forget how you made them feel.
This is usually applied in the inspirational, positive sense: get out there and make people feel good! But it works equally well as a warning.