Chaotic JavaScript Patterns

Dubious solutions to dubious problems

Evin Sellin
4 min readOct 18, 2021
Thanks Kevin Dooley!

Depending on who you ask, JavaScript is one of the following:

  1. A charming, expressive language with a few quirks.
  2. A nasty pile of terrible behavior, each instance worse than the last.

Today, we will be steelmanning the second argument by providing a few code snippets purpose-built to sow confusion. While you can certainly write chaotic JavaScript without these techniques, I hope to provide you with an extended toolset that can help you, the programmer, curry favor with the Ghaunadar the Ancient One, Chaos Deified.

Edit: I realize I have to be 100% clear. Never, ever, do any of these.

Problem 1: Object keys are too restrictive!

Isn’t it annoying how only strings and symbols can be keys to objects in JavaScript? For goodness sake, even Python allows us to at least index based on tuples! Is JavaScript really going to be outdone by Python?

An example of the glaring issue can be seen below:

the literal worst

Whatever can we do? Isn’t there any way we can improve this situation?

Solution: Symbols + toPrimitive + Object.prototype

We can get around this limitation by just rewriting Object’s toPrimitive call so it creates a new symbol for every object! Any object, when converted to a primitive, will resolve to a new, distinct symbol that you can index off of!

nothing bad can come of this

This works for objects, arrays, class instances, even classes themselves, you name it! We’ve fixed JavaScript by using the power of JavaScript! Isn’t JavaScript wonderful?

(As an aside, JavaScript’s Map data structure natively allows this! If you were hoping to solve this problem in a reasonable fashion, that’s almost certainly the way to go about it!)

Problem 2: I end up relying too much on my closure!

Let’s say we’ve got a section within a function that you could imagine splitting out into it’s own function, but frankly it’s only used in one place, and splitting it out might be more confusing than helpful.

The only problem is that there’s nothing preventing us from accidentally relying on a or b in that section, which would make it harder to split out in the future. Dang, I wish I could ensure a block only had access to z, but was still part of the function!

Solution: Nuke the Closure

Using proxies + with() allows us to do some programatic shenanigans to the stack. We can restrict the closure to only have access to the things the block cares about!

An example of how this strategy works is listed below:

If we have some subsection of a function which semantically only operates on variable z, we can restrict access to those variables and those variables alone, ensuring that we can abstract it out later if we want to reuse it. The above code snippet then becomes:

just make sure to disable strict mode ok

A kind of interesting property via a terrible, terrible technique!

Problem 3: I hate quote marks!

This is a continuation on the above technique, where proxies + with() gives you programatic access to the closure in exchange for your soul.

Let’s say you typed foo[bar] when you meant to type foo[‘bar’]. Now JavaScript’s telling you that bar is undefined even though it’s really obvious what you meant to type? Why is it being so pedantic? God, computers are stupid sometimes.

Solution: Bare Strings

Wrap every file in a big ol’ with() clause using a specialized proxy, like above! Now any valid identifier that’s not otherwise defined is now a valid string as well!

with + proxies = instant joy, tell ur friends

Now forgetting those quote marks will be a thing of the past! We did what we set out to do!

Problem 4: People keep commenting out my code!

Picture this: You’ve written a core function. Then somebody else comes along to your very nice implementation and comments out a line as part of their testing or whatever. That change gets accidentally added, submitted, then pushed. Your whole site goes down, and your shareholders’ portfolios decrease by 0.03%. Complete catastrophe.

Sure, tests SHOULD catch this, and sure, stuff SHOULD have gone through more stringent code review, and sure, maybe a linter would have helped or whatever. But this is the real world we’re talking about, and infrastructure is a pipe-dream. Code problems should be solved with CODE.

Solution: uncomment()

We can make use of JavaScript’s wonderful behavior once again! Calling toString() on a function returns the source of the function, which means we can define higher-order functions that operate on the source code itself! Wonderful!

just make sure to disable ur minifier

Well, this has been fun! See ya next ti…

Plea: Show me your chaotic JavaScript

I need to see the JavaScript you keep under the rug. The JavaScript buried deep underground, never to be unearthed by human hands. The JavaScript your dad warned you about.

Unearth them.

I must have them.

Evin Sellin is a software engineer and purveyor of bad programming takes. He sits on ugly snippets like a dragon on a hoard of treasure, constantly seeking more to add to his collection of horrors.

--

--

Evin Sellin
Evin Sellin

Responses (4)