Each typeface highlights a piece of history from a specific underrepresented race, ethnicity, or gender—from the Women’s Suffrage Movement in Argentina to the Civil Rights Movement in America.
This is how it goes. We put a load of shit into a single web page. This makes the page slow. Slow to load, slow to render. Slow.
Instead of getting rid of the shit, we blame the page refresh.
I would urge front-end developers to take a step back, breathe, and reassess. Let’s stop over engineering for the sake of it. Let’s think what we can do with the basic tools, progressive enhancement and a simpler approach to building websites. There are absolutely valid usecases for SPAs, React, et al. and I’ll continue to use these tools reguarly and when it’s necessary, I’m just not sure that’s 100% of the time.
This is a bit ranty but it resonates with what I’ve been noticing lately:
I’ve discovered how many others have felt similarly, overwhelmed by the choices we have as modern developers, always feeling like there’s something we should be doing better.
I think we’re often guilty of assuming that because our tools are great solutions for some things, they’re automatically the solution for everything.
Let’s take a meandering waltz through what other people have to say about simplicity.
Onboarding. Reaching out. In terms of. Synergy. Bandwidth. Headcount. Forward planning. Multichannel. Going forward. We are constantly bombarded and polluted with nonsense speak. These words and phrases snag and attach themselves to our vocabulary like sticky weeds.
Words become walls.
I love this post from Ben on the value of plain language!
We’re not dumbing things down by using simple terms. We’re being smarter.
Read on for the story of the one exception that Ben makes—it’s a good one.
Tales of over-engineering, as experienced by Bridget. This resonates with me, and I think she’s right when she says that these things go in cycles. The pendulum always ends up swinging the other way eventually.
A really terrific piece from Garrett on the nature of the web:
Markup written almost 30 years ago runs exactly the same today as it did then without a single modification. At the same time, the platform has expanded to accommodate countless enhancements. And you don’t need a degree in computer science to understand or use the vast majority of it. Moreover, a well-constructed web page today would still be accessible on any browser ever made. Much of the newer functionality wouldn’t be supported, but the content would be accessible.
I share his concerns about the maintainability overhead introduced by new tools and frameworks:
I’d argue that for every hour these new technologies have saved me, they’ve cost me another in troubleshooting or upgrading the tool due to a web of invisible dependencies.
We assume that complex problems always require complex solutions. We try to solve complexity by inventing tools and technologies to address a problem; but in the process we create another layer of complexity that, in turn, causes its own set of issues.
The Principle of Least Power looms large over this:
Some of the most important things in the world are intentionally designed “stupid”. In any system, the potential for error directly increases with its complexity - that’s why most elections still work by putting pieces of paper in a box.
The cosmonaut counterparts of the Mercury women astronauts: Zhanna Yorkina, Irina Solovyova, Tatyana Kuznetsova, Valentina Ponomareva, and Valentina Tereshkova.
Ponomareva recalled there being no envy between the women in the squad. According to her, it was a healthy spirit of competition. Everyone did their best to be number one, but also supported each other’s efforts.
One of those cosmonauts went to space: none of the women training for the Mercury missions did. There would be a shockingly gap of twenty years between the launch of Valentina Tereshkova and the launch of Sally Ride.
This is an excellent case study!
The technical details are there if you want them, but far more important is consideration that went into every interaction. Every technical decision has a well thought out justification.
One facet of this whole CSS debate involves one side saying, “Just learn CSS” and the other side responding, “That’s what I’ve been trying to do!”
I think it’s high time we the teachers of CSS start discussing how exactly we can teach a correct mental model. How do we, in specific and practical ways, help developers get past this point of frustration. Because we have not figured out how to properly teach a mental model of CSS.
I just binge-listened to the six episodes of the first season of this podcast from Stephen Fry—it’s excellent!
It covers the history of communication from the emergence of language to the modern day. At first I was worried that it was going to rehash some of the more questionable ideas in the risible Sapiens, but it turned out to be far more like James Gleick’s The Information or Tom Standage’s The Victorian Internet (two of my favourite books on the history of technology).
There’s no annoying sponsorship interruptions and the whole series feels more like an audiobook than a podcast—an audiobook researched, written and read by Stephen Fry!
Rush hour. The worst time of day to travel. For many it’s not possible to travel at any other time of day because they need to get to work by 9am.
This is exactly what a lot of web code looks like today: everything runs on a single thread, the main thread, and the traffic is bad. In fact, it’s even more extreme than that: there’s one lane all from the city center to the outskirts, and quite literally everyone is on the road, even if they don’t need to be at the office by 9am.
I tried very hard in that book, when it came to social media, to be platform agnostic, to emphasize that social media sites come and go, and to always invest first and foremost in your own media (website, blog, etc.) and mailing list.
I still stand by that advice, but if I re-wrote the book now, I would encourage artists to use much more caution when it comes to using social media websites like Facebook, Twitter, and Instagram.
This is really good breakdown of what’s different about CSS (compared to other languages).
These differences may feel foreign, but it’s these differences that make CSS so powerful. And it’s my suspicion that developers who embrace these things, and have fully internalized them, tend to be far more proficient in CSS.
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.
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.