Illustration by Kevin Cornell

The Cult of the Complex

by Jeffrey ZeldmanMay 31, 2018
Published in Code, CSS, HTML, JavaScript, State of the Web, Workflow
& Tools
’Tis a gift to be simple. Increasingly, in our
line of work, ’tis a rare gift indeed.
Article Continues Below
12 Comments
Share this:
Click to share on Facebook (Opens in new window)

Click to share on Twitter (Opens in new window)

Become a patron
Get the fastest deployments in UI/UX, with speed that blows developers
away. From static websites to WordPress to Kubernetes—whatever you
do, Buddy’s got your back.

A Book Apart:
Brief books for people who make websites.

An Event Apart:
3 days of design, code, and content for web & UX designers & devs.
In an industry that extols innovation over customer
satisfaction, and prefers algorithm to human judgement
(forgetting that every algorithm has human bias in its
DNA), perhaps it should not surprise us that toolchains
have replaced know-how.
Likewise, in a field where young straight white dudes
take an overwhelming majority of the jobs (including
most of the management jobs) it’s perhaps to be
expected that web making has lately become something
of a dick measuring competition.
It was not always this way, and it needn’t stay this way.
If we wish to get back to the business of quietly
improving people’s lives, one thoughtful interaction at a
time, we must rid ourselves of the cult of the complex.
Admitting the problem is the first step in solving it.
And the div cries Mary
In 2001, more and more of us began using CSS to
replace the non-semantic HTML table layouts with
which we’d designed the web’s earliest sites. I soon
noticed something about many of our new CSS-built
sites. I especially noticed it in sites built by the era’s
expert backend coders, many of whom viewed HTML
and CSS as baby languages for non-developers.
In those days, whether from contempt for the deliberate,
intentional (designed) limitations of HTML and CSS, or
ignorance of the HTML and CSS framers’ intentions,
many code jockeys who switched from table layouts to
CSS wrote markup consisting chiefly of divs and spans.
Where they meant list item, they wrote span. Where
they meant paragraph, they wrote div. Where they
meant level two headline, they wrote div or span with a
classname of h2, or, avoiding even that tragicomic
gesture toward document structure, wrote a div or span
with verbose inline styling. Said div was followed by
another, and another. They bred like locusts, stripping
our content of structural meaning.
As an early adopter and promoter of CSS via my work in
The Web Standards Project (kids, ask your parents), I
rejoiced to see our people using the new language. But as
a designer who understood, at least on a basic level, how
HTML and CSS were supposed to work together, I
chafed.
Cry, the beloved font tag
Everyone who wrote the kind of code I just described
thought they were advancing the web merely by walking
away from table layouts. They had good intentions, but
their executions were flawed. My colleagues and I here
at A List Apart were thus compelled to explain a few
things.
Mainly, we argued that HTML consisting mostly of divs
and spans and classnames was in no way better than
table layouts for content discovery, accessibility,
portability, reusability, or the web’s future. If you
wanted to build for people and the long term, we said,
then simple, structural, semantic HTML was best—each
element deployed for its intended purpose. Don’t use a
div when you mean a p.
This basic idea, and I use the adjective advisedly, along
with other equally rudimentary and self-evident
concepts, formed the basis of my 2003 book Designing
With Web Standards, which the industry treated as a
revelation, when it was merely common sense.
The message messes up the medium
When we divorce ideas from the conditions under which
they arise, the result is dogma and misinformation—two
things the internet is great at amplifying. Somehow, over
the years, in front-end design conversations, the premise
“don’t use a div when you mean a p” got corrupted into
“divs are bad.”
A backlash in defense of divs followed this meaningless
running-down of them—as if the W3C had created the
div as a forbidden fruit. So, let’s be clear. No HTML
element is bad. No HTML element is good. A
screwdriver is neither good nor bad, unless you try to
use it as a hammer. Good usage is all about
appropriateness.
Divs are not bad. If no HTML5 element is better suited
to an element’s purpose, divs are the best and most
appropriate choice. Common sense, right? And yet.
Somehow, the two preceding simple sentences are never
the takeaway from these discussions. Somehow, over the
years, a vigorous defense of divs led to a defiant (or
ignorant) overuse of them. In some strange way,
stepping back from a meaningless rejection of divs
opened the door to gaseous frameworks that abuse
them.
Note: We don’t mind so much about the abuse of divs.
After all, they are not living things. We are not purists.
It’s the people who use the stuff we design who suffer
from our uninformed or lazy over-reliance on these div-
ridden gassy tools. And that suffering is what we protest.
div-ridden, overbuilt frameworks stuffed with mystery
meat offer the developer tremendous power—especially
the power to build things quickly. But that power comes
at a price your users pay: a hundred tons of stuff your
project likely doesn’t need, but you force your users to
download anyway. And that bloat is not the only
problem. For who knows what evil lurks in someone
else’s code?
Two cheers for frameworks
If you entered web design and development in the past
ten years, you’ve likely learned and may rely on
frameworks. Most of these are built on meaningless
arrays of divs and spans—structures no better than the
bad HTML we wrote in 1995, however more advanced
the resulting pages may appear. And what keeps the
whole monkey-works going? JavaScript, and more
JavaScript. Without it, your content may not render.
With it, you may deliver more services than you
intended to.
There’s nothing wrong with using frameworks to quickly
whip up and test product prototypes, especially if you do
that testing in a non-public space. And theoretically, if
you know what you’re doing, and are willing to edit out
the bits your product doesn’t need, there’s nothing
wrong with using a framework to launch a public site.
Notice the operative phrases: if you know what you’re
doing, and are willing to edit out the bits your product
doesn’t need.
Alas, many new designers and developers (and even
many experienced ones) feel like they can’t launch a new
project without dragging in packages from NPM, or
Composer, or whatever, with no sure idea what the code
therein is doing. The results can be dangerous. Yet here
we are, training an entire generation of developers to
build and launch projects with untrusted code.
Indeed, many designers and developers I speak with
would rather dance naked in public than admit to
posting a site built with hand-coded, progressively
enhanced HTML, CSS, and JavaScript they understand
and wrote themselves. For them, it’s a matter of job
security and viability. There’s almost a fear that if you
haven’t mastered a dozen new frameworks and tools
each year (and by mastered, I mean used), you’re
slipping behind into irrelevancy. HR folks who write job
descriptions listing the ten thousand tool sets you’re
supposed to know backwards and forwards to qualify for
a junior front-end position don’t help the situation.
CSS is not broken, and it’s not too hard
As our jerrybuilt contraptions, lashed together with
fifteen layers of code we don’t understand and didn’t
write ourselves, start to buckle and hiss, we blame
HTML and CSS for the faults of developers. This fault-
finding gives rise to ever more complex cults of
specialized CSS, with internecine sniping between cults
serving as part of their charm. New sects spring up,
declaring CSS is broken, only to splinter as members
disagree about precisely which way it’s broken, or which
external technology not intended to control layout
should be used to “fix” CSS. (Hint: They mostly choose
JavaScript.)
Folks, CSS is not broken, and it’s not too hard. (You
know what’s hard? Chasing the ever-receding taillights
of the next shiny thing.) But don’t take my word for it.
Check these out:
• Getting Started with CSS Layout—Rachel Andrew,
Smashing Magazine
• Learn CSS Grid—Jen Simmons
• CSS Grid Layout—MDN web docs
• Grid by Example—Rachel Andrew
• A Complete Guide to Grid—Chris House, CSS-
Tricks
• Practical CSS Grid: Adding Grid to an Existing
Design—Eric Meyer, A List Apart
• Jen Simmons Labs
• Layout Land—YouTube
• A Book Apart: The New CSS Layout, by Rachel
Andrew
• The Story of CSS Grid, from its Creators—Aaron
Gustafson, A List Apart
• Transcript: Intrinsic Web Design with Jen Simmons
(The Big Web Show)
CSS Grid is here; it’s logical and fairly easy to learn. You
can use it to accomplish all kinds of layouts that used to
require JavaScript and frameworks, plus new kinds of
layout nobody’s even tried yet. That kind of power
requires some learning, but it’s good learning, the kind
that stimulates creativity, and its power comes at no
sacrifice of semantics, or performance, or accessibility.
Which makes it web technology worth mastering.
The same cannot be said for our deluge of frameworks
and alternative, JavaScript-based platforms. 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.
Keep it simple, smarty
Good communication strives for clarity. Design is its
most brilliant when it appears most obvious—most
simple. The question for web designers should never be
how complex can we make it. But that’s what it has
become. Just as, in pursuit of “delight,” we forget the
true joy reliable, invisible interfaces can bring, so too, in
chasing job security, do we pile on the platform
requirements, forgetting that design is about solving
business and customer problems … and that baseline
skills never go out of fashion. As ALA’s Brandon
Gregory, writing elsewhere, explains:
I talk with a lot of developers who list Angular, Ember,
React, or other fancy JavaScript libraries among their
technical skills. That’s great, but can you turn that mess
of functions the junior developer wrote into a custom
extensible object that we can use on other projects, even
if we don’t have the extra room for hefty libraries? Can
you code an image slider with vanilla JavaScript so we
don’t have to add jQuery to an older website just for
one piece of functionality? Can you tell me what
recursion is and give me a real-world example?
“I interview web developers. Here’s how to impress me.“
Growing pains
There’s a lot of complexity to good design. Technical
complexity. UX complexity. Challenges of content and
microcopy. Performance challenges. This has never been
and never will be an easy job.
Simplicity is not easy—not for us, anyway. Simplicity
means doing the hard work that makes experiences
appear seamless—the sweat and torture-testing and
failure that eventually, with enough effort, yields
experiences that seem to “just work.”
Nor, in lamenting our industry’s turn away from basic
principles and resilient technologies, am I suggesting
that CDNs and Git are useless. Or wishing that we could
go back to FTP—although I did enjoy the early days of
web design, when one designer could do it all. I’m glad I
got to experience those simpler times.
But I like these times just fine. And I think you do, too.
Our medium is growing up, and it remains our great
privilege to help shape its future while creating great
experiences for our users. Let us never forget how lucky
we are, nor, in chasing the ever-shinier, lose sight of the
people and purpose we serve.
Recently by Jeffrey Zeldman
Nothing Fails Like Success
Money and tech have a complicated relationship. We
trained our users to expect things for free. Quickly we
realized that wasn't a sustainable business model, so
we sold their data and served ads, which invites its own
problems. Now, we're trying to undo this tangled web.
How do we get back to a democratized web? Our own
Jeffrey Zeldman invites us to discuss how and to
#LetsFixThis.
Further reading about
Code
Responsible JavaScript: Part I
 The web is drowning in a sea of JavaScript, awash with unnecessary
bloat, inaccessible cruft, and unsustainable patterns. Jeremy Wagner
plots a course to navigate the JavaScript Sea responsibly by building the
right things the right way and using the web platform the way it was
meant to be used.
Semantics to Screen Readers
As an extension to our From URL to Interactive series, designer and
front-end developer Melanie Richards takes a deep dive into how our
content is accessed by a wide array of screen readers, which are highly
customizable to users. Understanding the nuances of accessibility APIs,
thorough testing approaches, and the wealth of resources available, site
creators can create the most widely accessible content for the most
users possible.
About the Author

Jeffrey Zeldman
Designing and blogging since 1995, Jeffrey Zeldman (@zeldman)
founded A List Apart in 1998 and Happy Cog™ design studios in 1999;
co-founded the web design conference An Event Apart; co-founded and
publishes A Book Apart—brief books for people who make websites;
wrote the industry-changing front-end bible Designing With Web
Standards, now in a third edition coauthored by Ethan Marcotte;
teaches in the MFA Interaction Design program at School of Visual Arts
NYC; and hosts The Big Web Show, an internet radio spectacular. More.