If you’re top priority is paid employment, right now, React is a great choice for that.
True. But…
If your priority is long-term resilience and maintainability, vanilla JS (probably with a light build process on top of it) is the ideal choice.
It will never become obsolete, or suffer from a breaking version change. It’s fast and performant, results in less code sent over the wire, and generally has a smaller footprint of things to break.
Jen pointed me to this proposal, which should help smooth over some of the inconsistencies I documented in iOS when it comes to the Web Audio API.
I’ve preemptively add this bit of feature detection to The Session:
if ('audioSession' in navigator) {
navigator.audioSession.type = "playback";
}
For me, a complicated Javascript build system just doesn’t seem worth it for small 500-line projects – it means giving up being able to easily update the project in the future in exchange for some pretty marginal benefits.
This! Also, this:
I’m writing this because most of the writing I see about JS assumes that you’re using a build system, and it can be hard to navigate for folks like me who write very simple small Javascript projects that don’t require a build system.
A search engine for images and audio that’s either under a Creative Commons license or is in the public domain.
This is an interesting little blogging tool: it turns a folder of notes on your Mac into a website.
- Create dedicated folder in the Apple Notes.
- Connect it to Montaigne.
- Add notes with your content.
- Everything will be published to the web automatically.
I’ve already written about how much I enjoyed hosting Leading Design San Francisco last week.
All the speakers were terrific. Lola’s talk was particularly …um, interesting:
In this talk, Lola will share her adventures in the world of blockchain, the hostility she experienced in her first go-round in 2018, and why she’s chosen to head back to a technology that is going through its largest reputational and social crisis to date.
Wait …I was supposed to stand on stage and introduce a talk that was (at least partly) about blockchain? I have opinions.
As it turned out, Lola warned me that I’d be making an appearance in her talk. She was going to quote that blog post. Before the talk, I asked her how obnoxious I could be about blockchain in her intro. She told me to bring it.
So in the introduction, I deployed all the sarcasm I had in me and said:
Listen, we designers have a tendency to be over-critical of things sometimes. There are all these ideas that we dismiss: phrenology, homeopathy, flat-earthism …blockchain. Haters gonna hate.
I remember somebody asking online a while back, “Why the hate for web3?” And someone I know responded by saying “We hate it because we understand it.” I think there’s a lot of truth to that.
But look, just because blockchains are powering crypto ponzi schemes and N F fucking Ts, it’s worth remembering that it’s also simply a technology. It’s a technological solution in search of a problem.
To be fair, it’s still early days. After all, it’s only been over a decade now.
It’s like the law of instrument says; when all you have is a hammer, everything looks like a nail. Blockchain is like that. Except the hammer is also made of glass.
Anyway, Lola is going to defend the indefensible and talk about blockchain. One thing to keep in mind is this: remember when everyone was talking about “The Cloud”? And then it turned out that you could substitute the phrase “someone else’s server” for “The Cloud?” Well, every time you hear Lola say the word “blockchain”, I’d like you to mentally substitute the phrase “multiple copies of a spreadsheet.”
Please give an open mind and a warm welcome to Lola Oyelayo Pearson!
I got some laughs. I also got lots of gasps and pearl-clutching, as though I were saying something taboo. Welcome to San Francisco.
Lola gave as good as she got. I got a roasting in her talk.
And just to clarify, Lola and I are friends—this was a consensual smackdown.
There was a very serious point to Lola’s talk. Cryptobollocks and other blockchain-powered schemes have historically been very bro-y, and exploitative of non-bro communities. Lola wants to fight that trend.
I get it. But it reminds me a bit of the justifications you hear from people who go to work at Facebook claiming that they can do more good from the inside. Whatever helps you sleep at night.
The crux of Lola’s belief is this: blockchain technology is inevitable, therefore it is uncumbent on us as ethical designers to ensure that the technology is deployed in a way that empowers people instead of exploiting them.
But I take issue with the premise. Blockchain technology is not inevitable. That’s the worst kind of technological determinism. It’s defeatist. It’s a depressing view of “progress” driven not by people, but by technological forces beyond our control.
I refuse to accept that anti-humanist deterministic view.
In any case, for technological determinism to have any validity, there needs to be something to it. At least virtual reality and machine learning are based on some actual technologies. In the case of cryptobollocks, there is no there there. There is nothing except the hype, which is why you’ll see blockchain enthusiasts trying to ride the coattails of trending technologies in a logical fallacy that goes something like this:
Blockchain is bullshit. It isn’t even very clever bullshit. And it certainly isn’t inevitable.
I’ve mentioned before that I’m not a fan of initialisms and acronyms. They can be exclusionary.
It bothers me doubly when everyone is talking about AI.
First of all, the term is so vague as to be meaningless. Sometimes—though rarely—AI refers to general artificial intelligence. Sometimes AI refers to machine learning. Sometimes AI refers to large language models. Sometimes AI refers to a series of if/else statements. That’s quite a spectrum of meaning.
Secondly, there’s the assumption that everyone understands the abbreviation. I guess that’s generally a safe assumption, but sometimes AI could refer to something other than artificial intelligence.
In countries with plenty of pastoral agriculture, if someone works in AI, it usually means they’re going from farm to farm either extracting or injecting animal semen. AI stands for artificial insemination.
I think that abbreviation might work better for the kind of things currently described as using AI.
We were discussing this hot topic at work recently. Is AI coming for our jobs? The consensus was maybe, but only the parts of our jobs that we’re more than happy to have automated. Like summarising some some findings. Or perhaps as a kind of lorem ipsum generator. Or for just getting the ball rolling with a design direction. As Terence puts it:
Midjourney is great for a first draft. If, like me, you struggle to give shape to your ideas then it is nothing short of magic. It gets you through the first 90% of the hard work. It’s then up to you to refine things.
That’s pretty much the conclusion we came to in our discussion at Clearleft. There’s no way that we’d use this technology to generate outputs for clients, but we certainly might use it to generate inputs. It’s like how we’d do a quick round of sketching to get a bunch of different ideas out into the open. Terence is spot on when he says:
Midjourney lets me quickly be wrong in an interesting direction.
To put it another way, using a large language model could be a way of artificially injecting some seeds of ideas. Artificial insemination.
So now when I hear people talk about using AI to create images or articles, I don’t get frustrated. Instead I think, “Using artificial insemination to create images or articles? Yes, that sounds about right.”
Instead of thinking about responsive design in terms of media queries, I like to think of responsive design in these categories.
- Responsive to the content
- Responsive to the viewport
- Responsive to the container
- Responsive to the user preferences
A very astute framing by Ted Chiang—large language models as a form of lossy compression for text.
When we’re dealing with sequences of words, lossy compression looks smarter than lossless compression.
A lot of uses have been proposed for large language models. Thinking about them as blurry JPEGs offers a way to evaluate what they might or might not be well suited for.
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.
I shared this link in Slack with my co-workers today:
Cultivating depth and stillness in research by Andy Matuschak.
I wasn’t sure whether it belonged in the #research or the #design channel. While it’s ostensibly about research, I think it applies to design more broadly. Heck, it probably applies to most fields. I should have put it in the Slack channel I created called #iiiiinteresting.
The article is all about that feeling of frustration when things aren’t progressing quickly, even when you know intellectually that not everything should always progress quickly.
The article is filled with advice for battling this feeling, including this observation on curiosity:
Curiosity can also totally change my relationship to setbacks. Say I’ve run an experiment, collected the data, done the analysis, and now I’m writing an essay about what I’ve found. Except, halfway through, I notice that one column of the data really doesn’t support the conclusion I’d drawn. Oops. It’s tempting to treat this development as a frustrating impediment—something to be overcome expediently. Of course, that’s exactly the wrong approach, both emotionally and epistemically. Everything becomes much better when I react from curiosity instead: “Oh, wait, wow! Fascinating! What is happening here? What can this teach me? How might this change what I try next?”
But what really resonated with me was this footnote attached to that paragraph:
I notice that I really struggle to generate curiosity about problems in programming. Maybe it’s because I’ve been doing it so long, but I think it’s because my problems are usually with ephemeral ideas, incidental to what I actually care about. When I’m fighting some godforsaken Javascript build system, I don’t feel even slightly curious to “really” understand those parochial machinations. I know they’re just going to be replaced by some new tool next year.
I feel seen.
I know I’m not alone. I know people who were driven out of front-end development because they felt the unspoken ultimatum was to either become a “full stack” developer or see yourself out.
Remember Chris’s excellent post, The Great Divide? Zach referenced it recently. He wrote:
The question I keep asking though: is the divide borne from a healthy specialization of skills or a symptom of unnecessary tooling complexity?
Mostly I feel sad about the talented people we’ve lost because they felt their front-of-the-front-end work wasn’t valued.
But wait! Can I turn my frown upside down? Can I take Andy Matuschak’s advice and say, “Oh, wait, wow! Fascinating! What is happening here? What can this teach me?”
Here’s one way of squinting at the situation…
There’s an opportunity here. If many people—myself included—feel disheartened and ground down by the amount of time they need to spend dealing with toolchains and build systems, what kind of system would allow us to get on with making websites without having to deal with that stuff?
I’m not proposing that we get rid of these complex toolchains, but I am wondering if there’s a way to make it someone else’s job.
I guess this job is DevOps. In theory it’s a specialised field. In practice everyone adding anything to a codebase partakes in continual partial DevOps because they must understand the toolchains and build processes in order to change one line of HTML.
I’m not saying “Don’t Make Me Think” when it comes to the tooling. I totally get that some working knowledge is probably required. But the ratio has gotten out of whack. You need a lot of working knowledge of the toolchains and build processes.
In fact, that’s mostly what companies hire for these days. If you’re well versed in HTML, CSS, and vanilla JavaScript, but you’re not up to speed on pipelines and frameworks, you’re going to have a hard time.
That doesn’t seem right. We should change it.
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.
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.
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.
Styling a list of nested details elements to create a beautiful lokking tree view, all in CSS, all nicely accessible.
The interactive widgets embedded in this article are excellent teaching tools!
AI becomes a stand-in term for whatever technologies and techniques are new, shiny, and just beyond the grasp of our understanding. We use it to gesture at a future we cannot fully comprehend or currently realise. As soon as we do, it will no longer be “AI.”
Almost no-one has given informed constent to being tracked through spy pixels in emails, and yet the practice is endemic. This is wrong. It needs to change.
Two weeks ago I was on stage for two days hosting Leading Design in London.
Last week I was on stage for two days hosting Clarity in New Orleans.
It was an honour and a pleasure to MC at both events. Hard work, but very, very rewarding. And people seemed to like the cut of my jib, so that’s good.
With my obligations fulfilled, I’m now taking some time off before diving back into some exciting events-related work (he said, teasingly).
Jessica and I left New Orleans for Florida on the weekend. We’re spending a week at the beach house in Saint Augustine, doing all the usual Floridian activities: getting in the ocean, eating shrimp, sitting around doing nothing, that kind of thing.
But last night we got to experience something very unusual indeed.
We stayed up late, fighting off tiredness until strolling down to the beach sometime after 1am.
It was a mild night. I was in shorts and short sleeves, standing on the sand with the waves crashing, letting my eyes adjust to the darkness.
We were looking to the south. That’s where Cape Canaveral is, about a hundred miles away.
A hundred miles is quite a distance, and it was a cloudy night, so I wasn’t sure whether we’d be able to see anything. But when the time came, shortly before 2am, there was no mistaking it.
An orange glow appeared on the ocean, just over the horizon. Then an intense bright orange-red flame burst upwards. Even at this considerable distance, it was remarkably piercing.
It quickly travelled upwards, in an almost shaky trajectory, until entering the clouds.
And that was it. Brief, but unforgettable. We had seen the launch of Artemis 1 on the Space Launch System, the most powerful rocket ever launched.
When Dan wrote this a week ago, I thought it sounded very far-fetched. Now it sounds almost inevitable.