Who killed the web designer?
Alternatively, “April naively wanders into gender politics and says a lot of dumb things”
Heather Buchel’s article It’s 2023, Here is Why Your Web Design Sucks traces the death of the job title “web designer” and the subsequent rise of the “frontend developer” role. She writes that design, being distinctly feminine-coded, didn’t appeal to the men entering the web programming field and that their disinterest de-emphasized that expertise until it disappeared. She also links to a separate article, Tailwind and the Femininity of CSS, that explains how few people bother learning CSS in depth as being due to its proximity to the feminine design role. Friends, I had a strong reaction to these articles. How can people I am so alike have drawn such different conclusions than me? Did I just miss this shift in the industry? Or worse, am I part of the problem?
Like many others, I learned HTML and CSS as a child from Lissa in order
to make my Neopets store pretty. When I first read
this article on how Neopets inspired a generation of young women
I actually cried. Never before have I felt like an article truly understood me. From Neopets, I went
to Perl, to Microsoft Frontpage, to PHP, building a pile of websites that I am blessed to have had
erased by the passage of time. I am continuously bothered both by how bad software engineer design
taste is and how little they understand the web (no, the solution to your CSS problem is not to just
add one more rule with !important
.) While at times I’ve said regrettable things about CSS, I also
only recently learned I’ve been doing it all wrong for years. I have a
deep respect for how technical both CSS, and design, can be. And yet I like Tailwind, it makes far
more sense to me than CSS ever did, and while I’m sad that engineers struggle to design it has never
made sense to me to hire a web designer (whereas I’ve never said no to a designer.)
In contrast to the “design is feminine and men pushed it out of the role circa 2010, in the same way they pushed women out of computing in the 60s” explanation, I would attribute the shift to a few related trends converging.
First, web apps like GMail (2004), Google Maps (2005), and Google Docs (2006), fundamentally raised the bar of user expectations. It wasn’t enough to show content on different pages anymore. Users were flocking to the responsiveness and interactivity provided by single-page applications. And while the old web was characterized by relatively static, information dense websites, this new web was increasingly dominated by highly dynamic, non-text user-generated content (YouTube launched in 2005.) It is incredibly difficult to think about information architecture design principles while also writing GLSL shaders. Maybe you’re the rare soul who can, do you also know how to localize a webapp like Google Maps into 80+ languages? You have to split the role somehow.
At the same time as client-side applications became dramatically more complicated, browsers stopped evolving the client-side (just look at the sad timelines of CSS and JS.) This is presumably because of Internet Explorer, and was such a large problem that Google built Chrome (2008.) If you need to make the client more dynamic, but you’re targeting assembly, you’re going to write tools to map the high level abstractions you want down to the low level. It’s no coincidence that both Google’s ClosureJS and Google Web Toolkit launched in 2006. Both bring advanced bundling, transpilation, localization, modularization, and unfortunately oodles of complexity. Today’s modern epidemics, JS and CSS bundlers and a billion frontend NodeJS frameworks, are the continuation of this legacy. We no longer write GWT Java that targets both the client and the server, we instead write JavaScript that targets both because the client is often more complicated. The exception are the folks writing htmx, but htmx only works for relatively simple clients.
There is a question worth asking here, why did tools like GWT that were developed by backend engineers growing towards frontend win out over (hypothetical? I can't think of any) tools written by web designers moving towards backend? The explanation I lean towards is that web designers just didn't write the necessary tools, but I would also buy an explanation that backend engineers, being more male and more respected, were just louder and dominated the conversation.
I’m less certain about this one, but WYSIWYG tools evolved to be good enough that web designers weren’t a required part of the process. You need someone to design the app, and you need someone to write the backend, but do you really need a web designer too? Good web design is beautiful, an interactive New York Times article or Bartosz Ciechanowski’s explanations of everyday things always blow me away, but they put time and energy into these things not because they need to but instead because they love art. The difference between a WYSIWYG version of my company’s website and the hand-made version I wrote is likely immaterial. But, to me, mine is beautiful because its complexity is distilled. It did not make business sense for me to spend time on it, and I’ve been fairly criticized because it’s hard for non-technical people to modify it.
Finally, CSS became write-once read-never. Old CSS was some background
s and font-size
s in a
jumble and instantly understandable. Layouts these days are so complicated and require such a mess
of rules that behavior is no longer obvious. Maybe you would instantly recognize what a practical
implementation of these directives would look like and
easily be able to modify it, without the context, but I can’t. And that’s the best CSS I’ll ever see.
It’s often easier to clear the entire class and write completely new rules when you need different
behavior. Tailwind makes sense if you accept this reality. You put the CSS in the HTML because
you’re going to toss it as soon as you change it, and the repetition is manageable because you’re
using a preprocessor anyway (you’re using Sass, aren’t you?) CSS, like PostScript, is a beautiful
idea that never really made sense or reached its potential in practice. There’s a reason we’re
emailing each other PDFs these days.
With all of that said, I agree with Heather on her broader point. Web design these days really does suck. And while I think the trends above are the real story of how we got here, I’m not really happy about any of them. We took something simple (how I miss the days of Neopets and Geocities) and made it incredibly complicated. I don’t think any of us would choose to live in a world with 2.6 million modules on NPM. How many times can you write left-pad? But I also don’t think any of us would choose to go back to the days of MapQuest.
And, ironically, I am actually more pessimistic than Heather is about all of this. I don’t think education will help this problem. I understand this stuff because I devoted my childhood to learning it, along with spending a further decade working professionally in this area, and continue to spend far too much of my adulthood extending my understanding of it. Expecting people to spend this much time, or worse expecting schools to be able to teach it, is simply unreasonable. I only see two ways out of this: we find ways to decomplexify web apps (ES modules and CSS nesting are good first steps) or we continue building even better tools. Maybe 2024 will bring us the tool that finally bottles up all this complexity? A lot of this is likely doable by large language models.
Web designers died for the same reasons modern manufacturing killed hand-made craftsmanship. Let’s treasure the few who remain.