SimplePrimate

Lately there has been a lot of discussion about the pros and cons of authoring HTML and CSS directly in JavaScript. Since web design is a subject that people get pretty passionate about, there’s been a fair amount of heated debate over it. In one camp you have developers coming from an app-dev background who see it as an efficient way to architect sites and increase maintainability. On the other side you have web purists who feel the practice results in bad code and violates the separation of concerns that has formed the bedrock of the web for so long.

If I had to place myself in one camp or the other it would certainly be on the side of the web purists. I’ve dedicated the last 15 years or so to teaching HTML and CSS with a focus on web standards and accessibility. So I feel very strongly that any new methodology that might result in degrading the quality of the underlying code should be examined with a critical eye. However, one thing I’ve learned over the years is not to cling to one specific approach to authoring content with any sort of dogmatic view. The web is a constantly shifting landscape of technologies, strategies, consumers, and content. If there is one thing that we can be 100% sure of, it is change.

So I’m really not interested in advocating for one approach or another, that’s been done before by people much smarter and more involved than me. I myself use JavaScript to help assemble pages, convert Markdown files, and generate this blog, so it would be pretty hypocritical of me to condemn it out of hand, and although I don’t use them personally the majority of the web community uses CSS preprocessors to help author their stylesheets. JavaScript as an authoring tool is here to stay. That horse, as they say, is out of the barn. What I want to talk about is how we should be careful to ensure that our tools and methodologies serve us and not the other way around.

As the web has become more complex we have sought to create new and more efficient ways to architect our sites. The move towards component-based design has created an entirely new level of complexity to deal with. Methodologies like BEM, OOCSS, and SMACSS began to dominate CSS authoring, and libraries like React and Angular have become de facto standard authoring tools in many environments. While these tools have brought many benefits to authors they have unfortunately created the perception that HTML and CSS are second-class citizens. Many people now view the global nature of CSS as a problem and specificity as something to be overcome instead of the powerful scoping feature that it is. HTML, and the native semantics and controls it offers, are often thrown out in favor of using generic DIVs and SPANs to build one widget after another. Most of the production code I explore today is a nested soup of DIV elements that would give our table layouts of yesterday a run for their money. In many cases our tools are to blame, as many are designed to architect code in this manner, or at least don’t contain mechanisms to prevent it. The recent move to in-line CSS inside JavaScript and to rendering HTML in the client at run-time are simply extensions of this approach.

Because of this much of the blame has been placed directly on JavaScript and JavaScript developers themselves. Many times the argument has been made that developers don’t take the time to learn and understand HTML and CSS, and in some cases there is certainly truth to this. Part of me wonders though why we haven’t done a better job of creating tools that enforce web standards and take advantage of the benefits that HTML and CSS offer? I’m not saying that our tools should be restrictive, just that they should make it easier to write solid code, not harder. To me it doesn’t matter whether you write your HTML and CSS by hand or use JavaScript to generate it for you. What matters is the output, how it is structured, and how it is served to the client. When we allow our tools to take precedent over the quality of our output the entire web suffers. Sites are likely to be less accessible, less performant, and suffer from poor semantics.

Perhaps it’s already too late to change direction. I’m already conditioned for a poor experience when browsing most large media sites. Even over a fast connection most of those sites are slow to load, are so ad and marketing heavy they interrupt the consuming of content, and frequently break. It’s gotten to the point that when I experience a fast, well-constructed site I’m usually shocked. If I feel this way I can only imagine how people not in the industry feel. As they wait for dozens of dependencies to load, or for their browser to render client-side HTML, I wonder how many of them simply shrug and blame their connection?

Clearly the need to continue to educate web professionals and to refine and improve our existing toolsets is important. Our responsibility as a community is to encourage best practices, educate people about their importance, and show a demonstrable difference between the approaches so that there is an incentive to change that is based on more than “it’s the right thing to do.” There are major gains to be had by architecting our code the right way, let’s keep focusing on those and not the means by which we get there.