With technology industry shifting its focus from consumer experience to modernization, giving way to complex algorithms driven by artificial intelligence rather than personal knowledge or intuition, if you like (disregarding the fact that algorithms were created by people), it should not come as a shock that toolchains have taken over the expertise.

In the same way, in the area with the bulk of young ambitious white guys (at all positions with no exception of management ones) it is anticipated that web design has turned into battle of egos.

It has not been like this before and it certainly should be this way any longer. If we’re going to the origins of the business, inaudibly enhancing human experiences, we should leave the tendency to complicate things behind and take baby steps, one considerate interplay per time. Naming the problem is the first stage in its solving.

And the Div is All I See

In 2001, CSS became the widespread replacement of HTML, that was commonly used for the earliest websites development.

Back then many coders, shifting from HTML table layouts to CSS, used mostly divs and spans in their markup. It was probably because of the confusion as to the HTML and CSS creators idea, or out of disdain to the premeditated limits of the languages. In items listing they wrote span, for paragraphs they wrote div. They wrote div or span with h2 classname for level two headline, or even skipping that hint at the document structure used div or span with prolix inline styling. The divs went in an infinite succession. They pullulated like cockroaches, depriving the content of meaningful structure.

Just Stick to the Point

The creators of the above mentioned code probably were under the illusion they were adding to the web progress simply shifting from HTML layouts. They wished for good but got as always. Their implementation was faulty.

Our point was that divs, spans and classnames HTML is not an advancement in comparison to table layouts when it comes to accessibility, flexibility, content discovery or the very webdesign perspective. We argue that, if you create for people and for the prospect, use simple and deliberate HTML where each component serves specific goal. Do not write div if you imply a p.

This concept together with other similarly elementary and obvious thoughts underlie the ground of Jeffrey Zeldman’s book Designing With Web Standards of 2003, which was taken as a breakthrough despite its common sense nature.

Word of mouth fumble about the medium

Concept, separated from the circumstances it originated from, usually leads to false doctrine  internet tends to exaggerate. So the idea of ‘ do not write div if you imply p’ turned into ‘using divs is bad’ over time.

Divs advocates’ counterstrike challenged this hollow criticism – it’s like W3C had intended the div to be the illegal pleasure. So let’s put it like this: any HTML element is neither good nor bad, the same applies with a fork, unless you eat soup with it. Proper applicability is what makes a difference.

The logic is simple. If there is no suitable HTML5 element for the specific goal, divs are perfectly fine, sometimes they are even the best appropriate choice. But still.

In one way or another, but both these simple ideas are never considered simultaneously. Severe defence of divs caused their inappropriate usage over time, while setting aside their meaningless denial gave way to their corruption by gaseous frameworks.

Keep in mind: It’s not divs abuse that we care about. These are the people, who use the products we design with it in an inappropriate way, we are concerned with. Mystery filling stuffed frameworks, outbuilt and div-driven, lend a hand to developers in designing sites quickly, but this speed comes at a price of structure overload, making your users upload masses of extra stuff your project does not actually require. And this is not the only drawback, since devil’s work can hide in that tremendous code.

It’s Still Hope for Frameworks

If you joined web design community within the last 10 years, you’ve probably started your way with learning frameworks, which you can now rely on. The majority of them are created on arrays of divs and spans, which are structurally the same lame HTML we built in 1995, no matter how advanced the end page may seem. So what is the key to keeping this whole monkey business going? JavaScript it is. It helps you render more services than expected and convey the content properly.

It’s not a bad thing taking frameworks advantages to speed up the process and run prototype tests, preferably in a staging environment. And hypothetically, if you’re not a newbie and have things sorted out so that you cross off the unnecessary bits, it’s ok to use framework for launching a site. The emphasis is on ‘you have things sorted out to cross off the unnecessary bits

Unfortunately, most new people in the field (and sometimes not newbies too) feel the need to stick in the needless NPM/Composer (and so on) packages to properly launch a site, without even the slightest comprehension of the purpose of those packages there. Keep in mind, it’s not a safe solution. But it seems like the danger goes disregarded, with the whole generation of dev  community is learning to launch products with insecure code.

In point of fact, lots of dev folks would rather lick the dust than confirm they hand-coded a project using advanced HTML, CSS or JavaScript they prefer and know perfectly. It’s a matter of professional honor for them, sort of a phobia that not using several new frameworks or tools every year would make them outdone by time. HR staff with their wordy job descriptions where efficiency in hundred frameworks ‘is a plus’ only make worse.

CSS is just fine

When our flimsy hickeys, covered with multiple unfamiliar code layers, begin to boil and erupt we criticize HTML and CSS, which, in fact, are only tools in clumsy hands of developers. ‘Put a blame’ attitude creates even more composite sects of specialized CSS followers, having devastating battles between themselves as a part of their charisma. More groups emerge with the same critical position towards CSS, to only split up and argue over the exact way CSS is broken, or which external tool or language can fix it without controlling layout. (JavaScript is usually the number one choice in such debates).

CSS is neither broken and bad, nor too difficult. (Catching up with fashion tendencies or simply catching a hen, that is difficult). Well, trust but verify, so check these out:

CSS Grid is consequential and easily understandable, try it to create any kinds of layouts previously made through JavaScript and frameworks, or even go further and seek absolutely new kinds of layouts. These endeavors demand some efficient learning, but as the saying goes ‘live and learn’, since it’s a good thing to engage you with. This learning ignites creativity, at no price of performance, semantics or accessibility. It surely makes it worth learning.

It’s smart to make it simple

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:

Effective communication requires simplicity. The most excellent design is the one the most clear and thus simple. We should never ask designers how complicated we can make a website, but, unfortunately, it’s what we do now. With our chase up the ‘delight’ we tend to forget the simple pleasure, clear and imperceptible design can bring. In our obsession with job security we collect platform requirements ignoring the true purpose of our job, that is in finding best solutions for businesses and customers’ problems. We fail to remember that ground skills can never get out-of-date. As ALA’s Brandon Gregory is reasoning:

I interview web developers. Here’s how to impress me.

Awkward phase crisis

Good design is never simple in its nature. There are a lot of complexity layers: technical, UX/UI, content and performance. It will always be not an easy job.

Simplicity is difficult, especially for designers. The best experience is imperceptible, with simplicity veiling sweat and toil followed by a row of failures, so that finally, after numerous attempts we come to experiences that ‘work ok’.

Mourning for our current industry shift from basics and flexible technologies, I’m in no way inspire that CDN and Git are impractical, or suggest that we should return to FTP (although early period of web design when designers could do practically everything certainly brought me some joy).

But today is good too. And we know, most of you would agree.  Our medium is evolving and it’s still up to us, to influence its future while giving perfect experiences to our clients. Do not let you be misguided from your true calling by chasing rainbows. Always remember how lucky you are to have your purpose and people you serve.