Stop Turning “Avoid Because” Or “When Appropriate” Into “Never Use This”

Far too often in web development people turn good advice into bad practice; or worse misinterpret and twist the specification’s recommendations into “never ever do the alternative”. More often than not, the result is bloated code and the equivalent of slogging around a flaming hogshead.

Image for post
Image for post


This comes up in HTML far far too often.

A simple example of this is how the <em> and <strong> tags should be used instead of <i> and <b> when their semantic meaning of “emphasis” and “more emphasis” is more grammatically appropriate. The past 20+ years I’ve heard all sorts of nonsense as folks magically transform that into “never use <b> and <i>, with some going so far as to make up about the bold and italic tags being deprecated.

HTML is supposed to be about semantics, saying what things are or would be in a professionally written document for structural or grammatical reasons. To that end all four of these tags have separate meanings and usage cases. When you make an entity name in a legal document bold, or a book title italic when it’s not being <cite>d, you are NOT applying “emphasis” or “more emphasis” to that text!

An example of this a friend of mine made around 15 years ago illustrates this well:

<i>GURPS,</i> <b>Steve Jackson Games'</b> flagship role-playing game, was first released in 1985. Several licensed adaptations of other companies' games exist for the system, such as <i>GURPS Bunnies and Burrows.</i> However, <b>SJ Games</b> has no connection with <b>Wizards of the Coast</b>, producers of the <i>Dungeons and Dragons</i> RPG. <em>No <i>GURPS</i> content is open-source.</em> <strong>Do not plagiarize <b>SJ Games</b> work!</strong>
-- <cite>RoosterBoy</cite>

The <i> tag for the product names, <b> for the relevant legal entities, <em> for emphasis, <strong> for even more emphasis. IF you do not understand this, you would have been kept back in the 5th grade prior to the mid 1980’s for failing to pass English.

We see the same broken mentality with people up, down, left, and right making their lives miserable and alienating users by having turned “don’t use tables for layout” into “never use tables”. They then slather on endless nonsense about things like “render time” or “load time”, and other such trash. Here’s a tip, if a 386SX/25 running windows 3.1 on dialup could handle a table in IE 4, please zip your lip about render time or load time in an age where a $80 cheap Chinese smartphone has a 1.5ghz quad core and broadband quality throughput!

Tables exist for tabular data. Yes, using them just because “wah wah, eye wunts columnsies” is dumbass and should be avoided. — like unordered lists — when you actually have tabular data!

I think much of this stems from people STILL having the derpy presentational markup mindset — just look at the garbage ignorant, incompetent, and inept “frameworks” using classes to recreate the worst of HTML 3.2—mated to the majority of dev’s not leveraging semantics as they fail to learn there are more tags that go into a table than just <tr> and <td>! Much less the semantic relationship things like the scope and axis attributes create.

Take this properly formed cart table:

<table class="shoppingCart">
<caption>Shopping Cart</caption>
<th scope="col">Qty</th>
<th scope="col">Iten</th>
<th scope="col">Unit Price</th>
<th scope="col">Price</th>
<th scope="row">AMD Ryzen 5 3600</td>
<th scope="row">Gigabyte Gaming X X570 Motherboard</th>
<th scope="row">G'Skill Ripjaws 32gb (2x16) DDR4 3600 memory kit</th>
<th scope="row" colspan="3">
<em>Free for orders over $100 USD
<th scope="row" colspan="3">Grand Total (USD)</th>

There is NO reason not to use a table for that, but there are people out there thoroughly convinced that “tables are evil” because they are either parroting what they were told, and/or failed to learn about semantic markup… aka the entire reason HTML even exists in the first place. More so when the alternatives fail to make the proper semantic associations for non-visual UA’s that the SCOPE attribute provides saying on which axis the <th> are to be applied.

Side note, leveraging the semantics there is NO reason to be pissing in classes on every blasted TR, TD, and TH inside there for the vast majority of layouts… something the alternatives of nested DIV’s and list abuse oft cannot say. Hence the table isn’t just the correct semantic markup, it’s typically LESS markup too!

Also HTML 5 now allows TFOOT after TBODY instead of before, which I applaud. I then scream “you idiots” at the W3C for the other way around now being invalid code… when TFOOT before TBODY was done for a REASON!

In JavaScript

This gets even worse as being a “real” programming language — Yeah, right — the folks using it tend to be even more pedantic about things. This is particularly true of “career educators” and “career students” who insist on shoe-horning impractical and irrelevant “programming models” and “paradigms” into their code regardless of if it fits the job.

Poster child for this one. You’ll hear people turn “avoid double equals when it matters” into “never ever use ==”. Ignorant, stupid, and arbitrary.

The way I’ve seen developers the past decade or so leap over “men and horses, hoops and garters, lastly through a hogshead of real fire” just so they can use “===” instead of “==” is ridiculously absurd at times.

A great case study for this is when people get the value from a <option> tag or any other form element. The returned result is always a string, but when people want to compare to a number rather than using the loose compare which would they go through and force typecasting because “double equals doesn’t compare type”.

Why full of it? Because 0 != null != undefined != false. Check it:

console.log(0 == null); // returns false
console.log(0 == undefined); // returns false
console.log(0 == false); // returns false
console.log(0 == '0'); // returns TRUE!

I’ve seen people go so far as to make complete copies of arrays typecast so they can === just to avoid using == when they’re only doing the comparison ONCE. It’s utter and complete nonsense and does NOTHING to improve code clarity or quality. More often than not all you are doing is introducing bloat.

It’s why the distinction between == and === exists, and not using it “because it doesn’t compare type” is utter and total nonsense in the vast majority of scenarios and codebases. People talk about it being “hacky” or “sloppy” when the alternatives they come up with are many, MANY times worse.

The SWITCH and CASE statements get a lot of similar malarkey shoveled on them, one of the worst being the “avoid dropthrough” nonsense which is utterly unfounded and total BS. There is with drop-through, hell it’s one of the reasons to use switch/case in the first place. Yet every single blasted “linter” out there by default complains about it.

This is oft brought up alongside the equally nonsensical:

Whilst the notion of function complexity has merit, people take it to absurd extremes with this “one function for every blasted line of code” approach. They take an overall simple idea and turn it into a convoluted mess by over-applying it. You can see this in modern codebases where people are creating functions or even entire classes for single-line actions, one file per class or even per function, and overall turning what should be ten lines of code into several dozen if not hundreds.

And I’m saying compromise code legibility by obfuscating it all down to single cryptic lines. I’m saying your convoluted “functions and classes for everything” approach is overcomplicating the simplest of tasks.

Take something as simple as a DOM make routine… you know, used to simply bypass innerHTML and all the issues it brings to the table?

function make(tag, commands) {
tag = document.createElement(tag);
for (var cmd in commands) {
var value = commands[cmd];
switch (cmd) {
case 'after':
value.parentNode.insertBefore(tag, value.nextSibling);
case 'before':
value.parentNode.insertBefore(tag, value);
case 'content':
if (value instanceof Array) {
for (var arr of value) tag.appendChild(arr[0], arr[1]);
} else tag.appendChild(
value instanceof Node ?
value :
case 'first':
value.insertBefore(tag, null);
case 'last':
case 'content':
case 'style':
for (var i in value)[i] = value;
case 'className':
cmd = 'class';
if (
value instanceof Array ||
'object' == typeof value ||
'function' == typeof value
) tag[cmd] = value;
else tag.setAttribute(cmd, value);
return tag;
} // make

That function is NOT overly complex warranting being broken into separate pieces… and there’s not a blasted thing wrong with the drop-through to turn className into class. NOR is there anything wrong with re-using the passed parameter “tag”, something else the various shmucks, shmendriks, and putz’ out there kvetch about for nothing.

Remember, if you can’t say anything nice, say it in Yiddish.

This example even brought up something else people complain about or avoid for nothing.

This is another thing the chazerei known as “linters” oft have the chutzpah to go meshugenah over. Oh noes, you put a static value before the variable, the horrors. Seriously, this is a thing to get upset about someone doing?!? Whiskey Tango Foxtrot!

The laugh is that many minifiers — such as Google’s closure compiler — will switch your statements to yodish because many structures — typeof is a great example — actually minify better if the static is first because it creates longer runs of the same characters in the code. This is where a lot of the “DRY” folks screw up is that they go so nuts trying not to repeat themselves, they either make more code, or they make less code that doesn’t gzip as well. No joke, it’s possible to write code that’s smaller, but gzips poorly. Most archival compression schemes have… issues that way.

As such the difference between:

‘object’ == typeof e


typeof e == 'object'

Is basically bupkis…apart from the fact the former if done more than once in a script will actually gzip compress smaller when deployed client-side.

“and that is why you fail” — Yoda

So why do people make these blanket assumptions?

It’s easy to blame it on stupidity, but I prefer to chalk it up to ignorance and the blind belief of what others tell you. , it just means you don’t know any better. You can fix ignorant.

A lot of times when people hear that something is bad for one reason, they automatically assume it’s a unholy terror to be avoided at all costs. Instead of weighing the pro’s and con’s they turn “use this when appropriate” into “never use that, use this instead”.

This is only exacerbated by the attitude that “beginners are too stupid to understand it, so just do it this other way all the time”. How insulting is that? If YOU understand it enough to be saying “never do that” and you were once a beginner, where do you get off saying these people are too stupid to understand it too? Simple fact is, this usually amounts to nothing more than projections, because they themselves don’t actually understand it, and are just blindly parroting what they were told.

We see this in other aspects of JavaScript, like how “with” is invalid in “strict” code. Why? Because some JavaScript developers got their panties in a twist over their lack of being able to grasp a simple construct programmers in C, Pascal, Ada, and a host of other languages have used for decades without problems. They use the “stupidity of beginners” as an excuse to vomit up bloated, harder to read code in the name of making it easier to read. The same with the current hot and trendy over-scoping with the derpy LET and CONST that only create memory thrashing, premature garbage collection, and molly-coddles people too lazy to use good naming conventions and leverage objects where appropriate. Same for the current media darling arrow function crap, that’s needlessly and pointlessly cryptic, harder to work with, solves problems you shouldn’t even have in the first place, and adds bloated overhead in the form of “function calls for nothing”.

It really makes me think I have an entirely different definition of the word “easy”… and honestly I truly believe that none of these concepts are so hard that are “too stupid” to grasp them; no matter what so many of these “experts” claim.

In fact if anyone tells you to not do something because “it’s too hard for beginners” they themselves are likely beginners; unqualified to flap their yap on the topic; so run. Run for your life.

I don’t think that you’re too stupid for this, and it’s far that they seem to.

Written by

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store