visible.md3 min read

← index

The complexity is not new, it is just visible

Twenty years ago the same problems existed. We ignored them.

3 min

Build pipelines, bundlers, CSS frameworks with their own toolchains, progressive web apps, Core Web Vitals, layout shifts, quick images and the list is real and the conclusion drawn from it usually isn’t.

I’ve been making things for the web for about as long as anyone writing these laments. Perl first then PHP 4 fairly soon after. I recognise the problem being described and I read it differently because all of that complexity was there twenty years ago and we simply ignored it. That isn’t the same as it being simpler. It means we were taking risks that look insane with hindsight.

Take deployment which is the part people get most nostalgic about and there were no build pipelines and we absolutely had scripts we ran to build things. There was Pagemill for making site-wide changes before pushing a new version. Then you’d make the changes, check briefly that it worked locally and FTP the files up by hand, breaking the site while you did it because anyone navigating during the upload would get half the old version and half the new one. Some of us put up a maintenance page for the duration which meant blocking every visitor rather than confusing a few of them.

That’s certainly simpler. It’s also much worse for the person using the site and on anything that touched data you were risking corrupting somebody’s records because their request arrived in the middle. The remarkable thing is how rarely it went badly wrong and I’m not confident it was rare so much as invisible to us.

We didn’t have CSS frameworks and we did have in-house templates and those had their own toolchains that nobody called a toolchain. Over time most of that migrated into content management systems and their template builder plugins and I’d take a modern utility framework over that arrangement without hesitating.

We had Core Web Vitals too, in the sense that we had traffic analytics telling us the same things less precisely. We had layout shift and called it a flash of unstyled content. We even had something like quick images, implemented as a pile of generated preload and swap functions from a visual editor and the modern picture element is a great deal nicer than that was.

So the complexity didn’t arrive. It got named, measured and turned into things you can be held accountable for. Every item on the list is a problem that always existed, that used to be absorbed silently by users and by luck and that somebody eventually built a tool to handle properly.

That’s why it feels heavier. Being handed a Core Web Vitals score is more work than not knowing your site is slow and knowing about layout shift is more work than shipping it and never finding out. The industry didn’t get more complicated so much as it stopped being able to pretend.

Writing web software is really good fun at the moment, better than it’s been for a long time. I use language models in my own work constantly because they’re excellent and not to simplify any of this. The complexity isn’t new. It’s just visible now and visible problems are the only kind anybody ever fixes.

If you want the older way back, you can have most of it and people do and write the HTML by hand, put the styles in a file, upload it and don’t measure anything. That works, it’s genuinely pleasant and the reason it feels lighter is that you’ve opted out of knowing whether it’s any good rather than because the problems went away.

What you can’t have back is the ignorance and that was always the thing doing the heavy lifting in the story about how simple it used to be.