There’s a theory that you can cure this by following standards, except there are more “standards” than there are things computers can actually do, and these standards are all variously improved and maligned by the personal preferences of the people coding them, so no collection of code has ever made it into the real world without doing a few dozen identical things a few dozen not even remotely similar ways. The first few weeks of any job are just figuring out how a program works even if you’re familiar with every single language, framework, and standard that’s involved, because standards are unicorns.
Scores of people who just want to deliver their content and have it look vaguely nice are convinced you need every web technology under the sun to deliver text.
This is very lawnoffgetting but I can relate.
I made my first website about 20 years ago and it delivered as much content as most websites today. It was more accessible, ran faster and easier to develop then 90% of the stuff you’ll read on here.
20 years later I browse the Internet with a few tabs open and I have somehow downloaded many megabytes of data, my laptop is on fire and yet in terms of actual content delivery nothing has really changed.
I know that Jeffrey and I sound like old men yelling at kids to get off the lawn when we bemoan the fetishisation of complex tools and build processes, but Jeffrey gets to the heart of it here: it’s about appropriateness.
As a designer who used to love creating web experiences in code, I am baffled and numbed by the growing preference for complexity over simplicity. Complexity is good for convincing people they could not possibly do your job. Simplicity is good for everything else.
And not to sound like a broken record, but once again I’m reminded of the rule of least power.
It turns out that Diana Smith isn’t just a genius with CSS—she’s a fantastic writer too. This post is somehow heartfelt and lighthearted at the same time. It’s also very humorous, but beneath the humour there’s an excellent point here about the rule of least power …and doing things the long, hard, stupid way.
Because something about those limitations just calls to me. I know I’m not alone when I say that a rigid set of restrictions is the best catalyst for creativity. Total artistic freedom can be a paralyzing concept.
That can sometimes be the case with programming. If you have the most powerful programming languages in the world at your disposal, it starts to seem natural that you should then have no difficulty solving any programming problem. With all these amazing tools offering countless solutions to solve the same problem, it’s no wonder that we sometimes freeze up with information overload.
We talk about complexity, but it’s all opt-in. A wonderfully useful (and simple) website of a decade ago remains wonderfully useful and simple. Fortunately for all involved, the web, thus far, has taken compatibility quite seriously. Old websites don’t just break.
Harsh (but fair) assessment of the performance costs of doing everything on the client side.
Maybe being able to speak a foreign language is more fun than using a translation software.
Whenever we are about to substitute a laborious activity such as learning a language, cooking a meal, or tending to plants with a — deceptively — simple solution, we might always ask ourselves: Should the technology grow — or the person using it?
See, this is what I’m talking about—seamlessness is not, in my opinion, a desirable goal for its own sake. Every augmentation is also an amputation.
Some questions for us to ask ourselves as we design and build:
- Empowerment: Who’s having the fun?
- Resilience: Does it make us more vulnerable?
- Empathy: What is the impact of simplification on others?
I wonder if I have twenty years of experience making websites, or if it is really five years of experience, repeated four times.
I saw Frank give this talk at Mirror Conf last year and it resonated with me so so much. I’ve been looking forward to him publishing the transcript ever since. If you’re anything like me, this will read as though it’s coming from directly inside your head.
In one way, it is easier to be inexperienced: you don’t have to learn what is no longer relevant. Experience, on the other hand, creates two distinct struggles: the first is to identify and unlearn what is no longer necessary (that’s work, too). The second is to remain open-minded, patient, and willing to engage with what’s new, even if it resembles a new take on something you decided against a long time ago.
I could just keep quoting the whole thing, because it’s all brilliant, but I’ll stop with one more bit about the increasing complexity of build processes and the decreasing availability of a simple view source:
Illegibility comes from complexity without clarity. I believe that the legibility of the source is one of the most important properties of the web. It’s the main thing that keeps the door open to independent, unmediated contributions to the network. If you can write markup, you don’t need Medium or Twitter or Instagram (though they’re nice to have). And the best way to help someone write markup is to make sure they can read markup.
Following on from that link about the battle between control vs. using what the browser already gives you, Baldur sums up the situation:
To pick a specific example: the problem with an over-engineered form is that the amount of code required to replace no engineering (i.e. native form controls with basic styling) is enormous and almost always only partially successful (i.e. under-engineered).
They are under-engineered because they are over-engineered—tried to replace native controls.
And so we get two schools of engineering thought:
- Keep it simple.
If, as it’s starting to look like from my perspective, these two communities are incapable of learning from each other, then maybe we should start consider some sort of community divorce?
You get to keep WebGL, Shadow DOM, WASM, React, and Angular.
(I know which group I’d rather be in.)
Boxman’s talk about complexity, reasoning, philosophy, and design is soooo good!
I think Eric is absolutely right. The barrier to entry for accomplishing what you want with CSS is much lower now. It only seems more complicated if you’re used to doing things the old way.
I envy “the kids”, the ones just starting to learn front end now. They’re likely never going to know the pain of float drop, or wrestling with inline blocks, or not being able to center along one axis. They’re going to roll their eyes when we old-timers start grumbling about the old days and say, “Floats?!? Who ever thought floats would be a good way to lay out a page? That’s totally not what they’re for, anyone can see that! Were you all high as a kite, or just utterly stupid?” You know, the way “the kids” talked ten years ago, except then it was about using tables for layout.
I am responsible for the code that goes into the machine, I do not want to shirk the responsibility of what comes out. Blind faith in tools to fix our problems is a risky choice. Maybe “risky” is the wrong word, but it certainly seems that we move the cost of our compromises to the client and we, speaking from personal experience, rarely inspect the results.
I love John’s long-zoom look at web development. Step back far enough and you can start to see the cycles repeating.
Underneath all of these patterns and practices and frameworks and libraries are core technologies. And underlying principles.
These are foundations – technological, and of practice – that we ignore, overlook, or flaunt at our peril.
Laurie Voss on the trade-off between new powerful web dev tools, and the messiness that abusing those tools can bring:
Is modern web development fearsomely, intimidatingly complicated? Yes, and that’s a problem. Will we make it simpler? Definitely, but probably not as soon as you’d like. Is all this new complexity worthwhile? Absolutely.
I agree that there’s bound to be inappropriate use of technologies, but I don’t agree that we should just accept it:
I think we can raise our standards. Inappropriate use of technology might have been forgivable ten years ago, but if we want web development to be taken seriously as a discipline, I think we should endeavour to use our tools and technologies appropriately.
But we can all agree that the web is a wonderful thing:
Nobody but nobody loves the web more than I do. It’s my baby. And like a child, it’s frustrating to watch it struggle and make mistakes. But it’s amazing to watch it grow up.
Philip Ball certainly has a way with words.
Paul is turning his excellent talk on design systems into a three part series. Here’s part one, looking at urban planning from Brasília to London.
The trouble with overflow menus is that you didn’t actually take anything away, you just obnoxiously obfuscated it.
Words of warning and advice from Daniel.
Instead of prioritizing, we just sweep complexity under the rug and pretend that it doesn’t exist.
I love this. I really love this. Remy absolutely nails what makes the web so great.
There’s the ubiquity:
If the viewer is using the latest technology beefy desktop computer that’s great. Equally they could view the website from a work computer, something old and locked in using a browser called IE8.
Then there’s the low barrier to entry—yes, even today:
It’s the web’s simplicity. Born out of a need to connect documents. As much as that might have changed with the latest generation of developers who might tell you that it’s hard and complex (and they’re right), at the same time it is not complicated. It’s still beautifully simple.
Anyone can do it. Anyone can publish content to the web, be it as plain text, or simple HTML formed only of <p> tags or something more elaborate and refined. The web is unabashed of it’s content. Everything and anything goes.
I might just print this out and nail it to the wall.
If you sit back for a moment, and think about just how many lives you can touch simply by publishing something, anything, to the web, it’s utterly mind blowing.
I can relate to every single word that Bastian has written here.
The longer I look at boilerplates, build tools, frameworks and ways to make my life as a developer easier, the more I long for the basics.