Grim reading from the games industry, especially if you work at Shopify where the CEbrO has just mandated that you have to use this shite.
Here’s the main problem I’ve found with generative AI, and with “vibe coding” in general: it completely sucks out the joy of software development for me.
I hate the way they’ve taken over the software industry, I hate how they make me feel while I’m using them, and I hate the human-intelligence-insulting postulation that a glorified Excel spreadsheet can do what I can but better.
We trained people to care deeply and then funnelled them into environments that reward detachment. And the longer you stick around, the more disorienting the gap becomes – especially as you rise in seniority. You start doing less actual design and more yapping: pitching to stakeholders, writing brand strategy decks, performing taste. Less craft, more optics; less idealism, more cynicism.
- Support open source software
- Support open web platform technology
- Distribution on the web should never be throttled
- External links should be encouraged, not de-emphasized
I can’t recommend React to any project or customer anymore.
Using almost any other modern alternative, you will save time, money and nerves, even if you haven’t used them before.
Don’t stick to technology just because you know it.
So, let’s start with a simple premise: how can we make design less opaque and encourage teams to make small changes more efficiently? Not every product decision needs to be a big, complicated design process.
This checklist, in four parts, is meant to be a simple, lightweight way for the team to get the ‘gist’ of the issue and make a shared decision quickly. It’s a starting point, a way to get the critical information in once place so the entire team can understand and discuss. The four parts are:
- Gather: Bring the right info together into a single place
- Impact: List the size of the problem and possible risks
- Sketch: Create a preliminary sketch of a solution
- Team Huddle: Get the product team to discuss and agree on a solution.
This is a really thoughtful piece by Rich, who’s got conflicted feelings about large language models in the design process. I suspect a lot of people can relate to this.
What I do know is that I find LLMs useful on occasion, but every time I use one I die a little inside.
Practice Progressive Enhancement.
Build first and foremost with forgiving technologies, declarative technologies, and forward and backward compatible coding techniques.
All content should be readable without scripting.
If it’s worth building on the web, it’s worth building it robustly, and building it to last.
I like the look of this proposal that would allow authors to have more control over network priorities for third-party iframes—I’ve already documented how I had to use a third-party library to fix this problem on the Salter Cane site.
This describes how I like to work too.
I’m not a fan of Nicholas Carr and his moral panics, but this is an excellent dive into some historical media theory.
What Innis saw is that some media are particularly good at transporting information across space, while others are particularly good at transporting it through time. Some are space-biased while others are time-biased. Each medium’s temporal or spatial emphasis stems from its material qualities. Time-biased media tend to be heavy and durable. They last a long time, but they are not easy to move around. Think of a gravestone carved out of granite or marble. Its message can remain legible for centuries, but only those who visit the cemetery are able to read it. Space-biased media tend to be lightweight and portable. They’re easy to carry, but they decay or degrade quickly. Think of a newspaper printed on cheap, thin stock. It can be distributed in the morning to a large, widely dispersed readership, but by evening it’s in the trash.
Want to use all those great features that have been in landing in browsers over the past year or two? View transitions! Scroll-driven animations! So much more!
Well, your coding co-pilot is not going to going to be of any help.
Large language models, especially those on the scale of many of the most accessible, popular hosted options, take humongous datasets and long periods to train. By the time everything has been scraped and a dataset has been built, the set is on some level already obsolete. Then, before a model can reach the hands of consumers, time must be taken to train and evaluate it, and then even more to finally deploy it.
Once it has finally released, it usually remains stagnant in terms of having its knowledge updated. This creates an AI knowledge gap. A period between the present and AI’s training cutoff. This gap creates a time between when a new technology emerges and when AI systems can effectively support user needs regarding its adoption, meaning that models will not be able to service users requesting assistance with new technologies, thus disincentivising their use.
So we get this instead:
I’ve anecdotally noticed that many AI tools have a ‘preference’ for React and Tailwind when asked to tackle a web-based task, or even to create any app involving an interface at all.
In which Rich nails Clearleft’s superpower:
“Clearleft is a relatively small team, but we can achieve big results because we are nimble and extremely experienced. As strategic design partners, we have a privileged position where we can work around a large company’s politics,” Rutter said. “We need to understand those politics — and help the client staff navigate them — but we don’t need to be bound by them. We bring a thoroughly user-centered approach to our design partnership, and that can be something novel to companies. By showing them what good design looks like (not so much the interface, as the actual process of getting to really well-designed products and services), we can be disruptive within the organization and leave them in a much better place.”
If I was only able to give one bit of advice to any company: iterate quickly on a slow-moving platform.
Excellent advice from Harry (who first cast his pearls before the swine of LinkedIn but I talked him ‘round to posting this on his own site).
- Opt into web platform features incrementally
- Embrace progressive enhancement to build fast, reliable applications that adapt to your customers’ context
- Write code that leans into the browser, not away from it
I’m not against front-end frameworks, and, believe me, I’m not naive enough to believe that the only thing a front-end framework provides is soft navigations, but if you’re going to use one, I shouldn’t be able to smell it.
Many interactions are not possible without JavaScript, but that doesn’t mean we should look to write more than we have to. The server doing something useful is a requirement for building an interesting business. The client doing something is often a nice-to-have.
There’s also this:
It’s really fast
One of the arguments for a SPA is that it provides a more reactive customer experience. I think that’s mostly debunked at this point, due to the performance creep and complexity that comes in with a more complicated client-server relationship.
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.
Anselm isn’t talking about becoming a CSS wizard, but simply having an understanding of what CSS can do. I have had similar experiences to this:
In the past years I had various situations where TypeScript developers (they called themselves) approached me and asked whether I could help them out with CSS. I expected to solve a complex problem but for me — knowing CSS very well — it was always a simple, straightforward solution or code snippet.
Let’s face it, “full stack” usually means “JavaScript”—HTML and CSS aren’t considered worthy of consideration. Their loss.
I’m subscribing to this RSS feed.
This tracks (ahem) with my experience of coding on trains.
Hidde lists the potentially flaky connectivity as a downside, but for many kinds of deep work I’d say it’s very much a feature, not a bug.