Orangemn6's blog


Orangemn6's blog


The Dark Side of Javascript: A Look at 3 Features You Never Want to Use

Orangemn6's photo
·Apr 3, 2021·

7 min read

JavaScript has some dark corners filled with spiders, and here are 3 of them

JavaScript has been around for quite a while already (around 26 years) and during that time, the language has evolved, a lot.

Most of this evolution has served a purpose, and especially in the latest iterations, the community of developers has managed to influence some of these changes, making JavaScript a very flexible and useful language.

However, during all these years of evolution, one could say that there are some vestiges of a bygone era, features that haven’t yet been taken out but that really serve no purpose (or rather, aren’t very efficient at that) anymore.

Here are three features of JavaScript that even if they’re still available under the runtime you’re using, you still want to avoid.

Void operator

You’ve probably seen this bad boy in action at one point. Back in the day, whenever you had a link that would fire a JavaScript function when clicked, you would add href="javascript:void(0)" to make sure the default action wouldn’t fire.

But what exactly did that mean?

The void operator is a way to generate the undefined value in JavaScript. That’s right, it takes an expression, any expression, and returns undefined every single time.

I know what you’re thinking: why not just use the actual undefined keyword, already available? Well, you see, before ECMAScript 5, the undefined keyword wasn’t a constant value. That’s right, you could define undefined which if you think about it, isn’t that something we all wanted to do at one point?

Although of course, doing that makes no sense which is why eventually it was re-defined as a constant value, and changing it is no longer an option. However, because you could change it back in the day, void would allow you to access the coveted undefined value, even if the constant was no longer working.

In fact, a great way to re-define the constant only for your namespace, avoiding any issues with 3rd party libraries, would be by creating your own IIFEs where one of the parameters received, was indeed, undefined, like this:

Of course, today the void operator still has its uses, but they’re non-essential. For example, the best use case in today’s JavaScript is to help avoid unintended returns on single-line arrow functions.

As you probably know, a single-line arrow function will return the result of that line, even if you don’t specifically use the return statement.

Both these functions will return something. Clearly, for the double function, that’s intended, but the other one might not be, you might just want to call this function, but you’re not interested in its result value. There you can write a new script.

And that would immediately obscure the returned value and make sure your call only returns undefined.

This behavior, to me, provides a minimal benefit, rendering void useless in this time and age of JavaScript.

I would suggest you avoid it and let it wither into a deprecated state.

With statement

This one is yet one of those constructs that JavaScript has but you’ve probably never heard about it because it’s not really promoted. In fact, even MDN’s official documentation discourages you from using it, because it can lead to very confusing code.

You see, the with statement allows you to extend the scope chain for a given statement. In other words, it allows you to inject an expression into the scope of a given statement, ideally, simplifying said statement.

Here is an example so you get what I’m awkwardly trying to say:

Notice the “magic” of the with statement inside the greet function. Now this is a basic example showing the “happy path” of the expression. But let’s take a look at another case where things get a bit more complicated:

What do you think would be the output from that execution?

Hey Fernando, here is a message for you: You got 2 emails
Hey Fernando, here is a message for you: **Unrelated message**

You’ve unwillingly overwritten the second argument of your function by adding an equally named property to your object. Something, I might add, that is completely normal, since one would never expect both to be at the same scope level. However, thanks to with we’ve mixed both scopes and the result is not ideal.

This is all to say, avoid with, while it might seem like a great way to save some keystrokes, you’ll create code that can turn very complex very fast, and mentally parsing it can be a challenge for someone else (or you, two weeks in the future).


If you’re old enough (like me), you’ve experienced the hate for go-to statements in other languages such as C. That was terrible, that was a feature that made a lot of sense back in the day, but that eventually, with newer solutions to the same problem, became so obsolete and bad that it turned into an anti-pattern.

So of course, JavaScript had to implement it. Kind of.

A go-to statement is a way for you to place a marker anywhere on your code, and then jump there, from anywhere else. You could be jumping to the middle of a function, or inside an IF statement, it was like a magic portal to anywhere inside your code. I’m sure you can see how that can be a problem, it’s just too much power, too much flexibility, of course we’re going to miss use it!

JavaScript however, implemented a similar, yet not identical construct: labels.

A labeled statement in JavaScript is a mark you put before a statement which you can then either break out of or continue. Notice how there is no more go-to which is a definite plus.

You can write something like this:

And the output would be:


Of course, that example looks an awful lot like an if..else statement. And you can perfectly say that it doesn’t look that bad. However, you’re breaking from the normal flow of the code and skipping statements. If you’re aiming to do that, an if..else is much easier to mentally parse by others.

The problem with labels becomes a bit more evident when we include their interaction with loops and the continue statement.

Can you mentally parse the above code and tell me exactly what the output will be? It’s not impossible, but it’ll take you a while. The above script will print:

{ i: 0, j: 0 }
{ i: 1, j: 0 }
{ i: 2, j: 0 }
{ i: 3, j: 0 }
{ i: 4, j: 0 }
{ i: 5, j: 0 }
{ i: 6, j: 0 }
{ i: 7, j: 0 }
{ i: 8, j: 0 }
{ i: 9, j: 0 }

Essentially, the second if is evaluating true on 0 so the continue statement affects the outer loop, causing it to move to the next index value, which in turn, resets the inner loop, causing it to go back to zero, and the same thing happens, over and over, ten times. The first if , in case you’re wondering, never gets to evaluate to true, because j never reaches any value other than 0.

Labels can be tricky little fellas, and even if you get them to work, they make a lot of sense from an interpreter perspective, but you should be writing code for humans, not for machines. Someone else is going to come and read it (or even you in 3 weeks), and the moment they lay eyes on the labels, they’ll hate you forever — and of course, they’ll take a lot longer to understand the basic flow of your code, but that’s a secondary problem at this point.

I love JavaScript, don’t get me wrong, I’ve been interacting with it in different ways since I started working as a web developer 18 years ago. I’ve seen the language evolve and, like a fine wine, get better with time. However, I’d be lying if I said there aren’t some dark corners of the language where I just don’t like to get myself into. And these 3 elements show exactly that.

The good news is that in my years of experience, I’m yet to see either with or labels be implemented and deployed into production. That’s not to say there aren’t cases like that, but the fact that I’ve never seen one makes me think not many code-review processes let them pass.

How about you? Have you seen any of these constructs being used in modern-day JavaScript?

Tip: Share components between projects using Bit

Bit makes it simple to share and reuse independent components across projects.

Bit component can be independently maintained and developed so that you don’t need to worry about structuring a full dev environment just to make a few changes.

Use Bit to collaborate more effectively and keep a consistent design.

**Bit** (Github) supports Node, TypeScript, React, Vue, Angular, and more.

Exploring React component shared on []( React component shared on

Share this