Illustration by

The Cult of the Complex

’Tis a gift to be simple. Increasingly, in our line of work, ’tis a rare gift indeed.

Article Continues Below

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 whose hiring practices overwhelmingly favor young white men, it’s perhaps to be expected that web making has 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#section2

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#section3

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#section4

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#section5

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#section6

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:

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#section7

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#section8

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.

12 Reader Comments

  1. With many of the development trends, it seems like the problems are self-inflicted by not quite understanding something. So in creating a solution, the core problem isn’t understood and results in overcomplication.

    I think the business pressure of ‘deliver fast’ has also played a part in complicating workflows under the guise of automation. If I can say such and such is automated, it’s immediately perceived as being efficient, even though the costs of set up, maintenance and on-boarding aren’t considered.

    It’s also interesting that we say we care about the environment and being inclusive, yet don’t approach development with the mindset that every byte has a cost, nor make accessibility a requirement.

    So my question is, where are the companies and agencies who focus on these things – solving the actual problem and taking the time to simplify the complex? This mindset must still be out there somewhere, right?

  2. > where are the companies and agencies who focus on these things

    I’ve been involved with web accessibility for 18 years now, and currently the company I work for provides, amongst other things, instructor led training on how to meet accessibility requirements. I routinely meet “developers” who don’t even know basic HTML. Here’s one for you: next time you are talking to a developer, ask them about Description lists (previously called definition lists, but renamed in HTML5). If they can’t code up something as basic as that, is it any wonder they don’t get the whole ‘semantic structure’ bit of HTML?) Double bonus points if they know how table headers and ids work.

    I lament the fact that there is no formal training in web technologies, so you have a legion of developers out there who don’t know what they don’t know. It’s fine and dandy to know how to work with frameworks, but I challenge hiring managers to have potential candidates hand code a basic web page in notepad during their interview, and if they can’t do that, why are you hiring them? And is it any wonder things start to crumble when they aren’t built on a solid foundation?

    BTW, if you aren’t sure:
    Description Lists –

    Table headers and ids –

  3. Sometimes, not very often, npm goes down. Then I literally can’t work anymore as I need to do an npm install to pull down hundreds of packages before I can write a single line of code.

    Times like this make me realise what life as a web developer has become.

    I completely agree, web development has become too complex and I don’t know what to focus on and what to learn anymore. As soon as you learn something its out of date and replaced by something else. It makes me concerned with the future of the industry and my future career.

  4. Mr. Zeldman thanks for this article, is really fresh air! I work in a fantastic small reality where we still know almost 100% of the code (both frontend and backend) we are using for websites or web applications.
    But having a glance at job offers or when we need to cooperate with some other professionists, it seems the world cannot live without knowing at least 3 frameworks and the “basic” knowledge of HTML, CSS, js is not even mentioned nor considered, just something school thing, not professional.
    So it is some time I have been asking myself if I am outdated with my “hand made” coding way, even if I don’t feel, as I could solve any problems, interface with any system.
    Reading your article, a source for sure “on the topic”, really lift me up. So thanks a lot!

  5. This article really pleased me. I said to my team recently, after we spent time going through Jen Simmons excellent Grid tutorials, “I think CSS frameworks are doomed. Why will we need them anymore when layout can be this simple?”

    I used the word “simple” referring to how slim the HTML markup was, thanks to the power of a true layout engine in CSS.

    This kind of simplification has spread to how we will handle our progressive enhancement as well. This excellent video: had us discussing that our next move is to provide very simple, clean layouts to all browsers that do not support grid. Since we no longer have to use hacks (floats, inline blocks, or other tricks) to create the layouts we have, we plan to ditch them entirely for browsers that can’t comprehend a layout engine. I’m also discouraging “flex-box fallbacks” so that we are planning to use Grid in the way our team intends and Flexbox in the way our team intends, not as a supplemental workaround.

    I’m dreaming of really tight CSS files with this mindset and really tiny HTML – and I couldn’t be more excited!

    Now, to use the “The results can be dangerous” link from your article to scare my workplace (e-commerce site) into ditching a fair amount of the 3rd party services and cookies in use and I will watch our performance scores soar! 🙂

  6. “I am baffled and numbed by the growing preference for complexity over simplicity. ”

    I think we should all remember that “complexity” and “simplicity” can be relative notions. There’s a near-endless supply of programmers who think functional programming is the simplest thing ever, but are baffled by “float: right”.

    Also, dismissing a new technology as “too complex”, “overkill”, etc. is often a lazy way of not having to adapt to a changing landscape.

  7. Great insight (as always) Jeffrey.

    This leaves me with many questions like:

    How do we ‘disrupt’ the trend of ‘complex’ to raise the emphasis on a semantic and purposeful web?

    How do we reward the efforts of those who choose less tools (less complex) in favor of better HTML?

    The craft-beer movement has ‘disrupted’ the corporate beer making industry, could there be a similar ‘craft web making’ movement that would ‘upset’ the trend of complexity?

  8. Back in 2003 it was this website that got me properly thinking about and exploring building page layouts using CSS and HTML. Over the years I’ve been turned on to new approaches and technologies by revisiting ALA on a regular basis. I have to say when things like SAAS and LESS came out and even before that when jQuery was finding its feet it used to just baffle me that people were using these tools without a clear fundamental understanding of the layer that they working on top of. It’s like the many Rails developers I know these days who have a really bad – I mean a REALLY BAD – understanding of basic Ruby development principals. Or the many front-end developers who rely on mixins to accommodate older browsers without understanding why browsers vendors have (or had) their own specific CSS rules. Or the many WordPress “developers” who can only write PHP when the code being written is strictly defined within the syntax and functionality of the core WordPress libraries.

    I think the main takeaway from this article is that, much like history, if you don’t understand the mistakes you made in the past then you are forced to repeat them in the future. Using a framework or a library or whatever is actually pretty pointless if you don’t know WHY you are using it and WHAT its doing and HOW its doing it. Because if you understand the WHY and the WHAT and the HOW chances are you won’t use it. You’ll do it by hand. Because you know how to do it by hand. And for me that’s the skill I look for when hiring a front-end developer because anyone who understands the foundational principles of HTML, CSS and vanilla JS will have zero trouble mastering Angular or React or whatever other (excellent) framework may be required for a particular project.

  9. It is a common conception that most online webmasters and the web world as a whole is occupied by the 18 to 34 year old male. Though this may be prevalent thinking, there is booming evidence of today’s’ retiree, making websites, and as astute in internet business endeavors as their younger counterparts, with a unique set of qualifications in their favor

  10. “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.”

    I think it’s worth considering whether sexualized slurs based on skin color, gender, or sexual orientation really serve to advance what you’re trying to say. It might seem like harmless bigotry, but racism is a process that needs fuel to sustain itself. Statements like the ones you’re making promote the idea that we should evaluate people on the basis of their external characteristics rather than by the content of their character. It’s an attitude that is profoundly toxic to positive discourse, and it’s worth emphasizing that those you’re choosing to stereotype won’t be the only people (or even the primary ones) that are negatively affected by this kind of thinking.

  11. Enjoyed reading the article above , really explains everything in detail,the article is very interesting and effective.Thank you and good luck for the upcoming articles

  12. As a developer that used to love developing internet experiences in code, I am frustrated as well as numbed by the growing choice for complexity over simpleness. Intricacy benefits convincing people they might not potentially do your work. Simpleness benefits everything else.

Got something to say?

We have turned off comments, but you can see what folks had to say before we did so.

More from ALA