A History of Web Dev Holy Wars

If you are a web developer, there are two phrases that you should never use: “You should always…” and “You should never…”¹

My fellow developer, John “Not That One” Williams,² recently wrote a blog post about the slow uptake of new CSS features. The entire post is worth reading, but there is a section toward the end that got my writin’ fingers itching:

Much of ‘the discourse’ borders on snobbery, and occasionally someone will strip all the way down to their skivvies and leap right into the deep-end of elitism… I have unfollowed folks on Mastodon who are contributing great things to the web platform because they spend three-quarters of the time running other people down for using tools they don’t approve of. Sans context. React? Always bad. Next!

All this has happened before, and all of it will happen again.³ As long as I’ve been following web development, there have been gatekeeping, elitism, and holy wars surrounding the “right way” to do a particular thing. Here are some of my favorites, in roughly reverse-chronological order.

• ”JavaScript frameworks are ruining the web."
• "Utility classes are for people who don’t understand CSS."
• "Using JavaScript at all is contrary to the spirit of the web."
• "If you wait for Safari to implement a CSS feature before you use it, you’re holding back the web."
• "Never use PHP — it’s a terrible language."
• "Server-side rendering is obsolete — everyone has JavaScript enabled now."
• "All websites and apps need server-side rendering — not everyone has JavaScript enabled."
• "Stop minifying your code — code on the web should be readable."
• "Always minify your code — you should never waste bandwidth."
• "CSS preprocessors are for people who don’t understand CSS."
• "If you still support Internet Explorer, you’re holding back the web."
• "If you don’t support Internet Explorer, you’re abandoning disadvantaged visitors."
• "Every HTML element on your site should be named semantically."
• "If you still support Netscape Navigator, you’re holding back the web."
• "Your site needs to look exactly the same in every browser."
• "Never use PHP — it’s a terrible language.” (but 20 years ago)

The zealots who looked disdainfully on anyone who violated one of these sacred tenets from years past look pretty foolish now, not so much because they were wrong (though some of them definitely were), but because the window of time when that particular rule mattered was so short. Too many people wasted time that they could have used to make useful things or teach people valuable skills, spending it instead on heated arguments that sowed division and hurt feelings. In the end, what do they have to show for it?

“What are you saying, Jesse? That we should never try to convince people to try a better way to do something?” I’m disappointed that you would use such an obvious straw man argument. As a straw man yourself, you should know better!

No, of course that’s not what I’m saying. First of all, it would violate my own rule from the very first paragraph in this blog post. But more importantly, there is a big difference between zealotry and advocacy. A zealot focuses on what people are doing wrong. “Stop doing that! Do this instead! You don’t want to be like the people who do that.”

By contrast, advocates focus on how good ideas can improve people’s lives. Think of Ethan Marcotte, who coined the term “Responsive Web Design” in his industry-changing article, then spent years teaching, listening to feedback, refining his idea, and sharing his findings. Another example would be Brad Frost with Atomic Design. He didn’t just come up with a good idea and tell people about it. He came up with better and better ways to explain it, contributed to software that helped people implement it, and wrote an entire book about it. Over time, he modified his ideas, adapted to new tools, and was happy to let Atomic Design coexist with different conceptual frameworks for front end design. These are people who politely changed the entire business of web design by starting with a good idea and promoting it with knowledge, patience, and flexibility.

Or maybe you have an example that’s even closer to you. In John Williams’⁴ blog post that I linked earlier, he mentions that even he had to be persuaded by his project manager to embrace responsive design back in its early days. When you have an idea you want to spread, you don’t have to change the whole industry at once — it’s enough to persuade one person at a time.

Footnotes