Someday You Will Have Forgotten More Javascript than Most People Know

Easy. Just do array.sort(). Sheesh.

Have you ever heard the old cliche, “That dude’s forgotten more <insert special skill> than you’ll ever know?”

I used to think that was some kind of compliment to the experienced guy, but now it’s just a slap in the face to everyone involved.

I got to be the poster child for that saying the other day. The instructor asked who wanted to work at the whiteboard today and I enthusiastically volunteered.

The objective: perform a bubble sort on an array of numbers and return the result.

I was all in my head going, “I’ve been coding for decades, this’ll be easy!” and hopped right up. When I took my first coding lessons in 1982 it was about the only way. I just now looked on Wikipedia and saw that there are about a hundred of them.

Name           Average     Worst     Memory     Stable     Method             Bubble sort     O(n2)      O(n2)       O(1)      Yes    Exchanging             Selection sort  O(n2)      O(n2)       O(1)      No     Selection             Insertion sort  O(n2)      O(n2)       O(1)      Yes    Insertion             Merge sort      O(n log n) O(n log n)  O(n)      Yes    Merging             Quicksort       O(n log n) O(n2)       O(1)      No     Partitioning             Heapsort        O(n log n) O(n log n)  O(1)      No     Selection

That’s when I remembered that I had been using built-in sort functions for so long that the basic algorithm for a sorting function had slipped out of my memory!

On the plus side, I was able to hem and haw and hack my way through it eventually, but what should have been a two minute operation and bing, bang, boom, done became a humiliating floundering-around session in front of the whole class.

I blame it on my own reliance on “libraries,” “devtools,” “imports,” “dependencies” or whatever fun name you want to slap on “somebody else doing my work for me.”

Here’s another fun anecdote. Not personal, but about someone else:

There was this guy who made an npm package called “kik.” In it, he had a block of code that was 11 lines long and only performed one silly function. It basically just trimmed excess spaces off the ends of a string.

But somehow this little library became incorporated as a dependency on a bunch of other libraries. Libraries that provided functionality that people needed to perform complex, important tasks.

Then along came a mobile app, also called “kik,” that wanted to put their own package on npm. Of course they couldn’t, because the name was already taken.

What did they do? Well, what could they do — they just threatened to sue until npm finally caved and told the original “kik” guy that he would have to rename his package.

So he just deleted it altogether. I mean, it’s 11 lines of code that trims spaces off of strings. Who cares, right?

What do you mean it “just stopped working?”

The Internet cared. Because the moment he removed his package from the npm repository, half the Internet stopped working. Not so much because people were clamoring for this white-space-removing chunk of code, but because they were using other libraries that referenced other libraries that referenced other libraries that included it.

(that was an example of recursion just then: I had a base case, implemented a process toward that base, and repeated the same process until the base state was reached)

But crashdaddy, you wail, we need those libraries to accomplish important tasks and functions! Of course you do. I do too. My own website relies heavily on APIs and libraries. I use JQuery, I use CanvasJS, I use Bootstrap.

So you know how I got over my reticence about using libraries and dependencies? Through the concept of object mutability.

You’re outta control

Srsly. You know about mutable and immutable objects. Take a string for instance. It seems like you can make changes to a string, but in reality you’re just creating a new string that incorporates those changes. It’s a whole big thing.

A library that you link to is what you would call a mutable object. It can be edited, renamed or deleted at the owner’s whim from wherever it’s stored. Those edits can immediately impact you as the user.

Suppose you link all your fonts to the Google fonts API. All they have to do one day is to accidentally send one of their little spider bots to crawl across those font files making one tiny name change (like, say they want to add a numerical index code of some sort to the end of the font name).

Next thing you know your whole website is being displayed in Arial.

That’s just a simple example.

So what do you do? Turn the library into an immutable object. Simply store it locally and call it from your own server.

Have I reformed completely? Probably not. I like the convenience of libraries just as much as anyone else.

One that I use a lot is the Phaser library that provides arcade-game functionality for the HTML5 canvas element. It’s powerful and convenient and I’m probably a lot like you in that I would rather focus on the pew-pew-pew code for a game than on the calculus behind the physics.

But instead of linking to it, there’s a nice, immutable copy of it residing on my own server right this minute, so if, say CBS ever threatens them over the name “phaser” and they just rename it, mine will still work while everybody else’s crashes.

Star Date 2020: We renamed our javascript library and the Internet fell apart

I’ll have the market cornered on HTML5 canvas-based arcade games! Muahaha.

(for like a day)

The takeaway from all this is just this: try to reduce your external dependencies when you can, try to remember how to code as opposed to just calling functions, and try not to delete your own library when half the Internet is reliant on it.