Hello, I’m humble developer who works with a lot of JavaScript frameworks, libraries, modules, addons, plugins, browsers, preprocessors, processors, postprocessors, plugins for processors (Autoprefixer), plugins for browsers (Ember inspector), plugins for libraries (jQuery), addons for frameworks.

Isn’t it a lot of tools that we need to work with on daily basis? How big is your package.json file? Do you know what each dependency is doing? I’ve assumed here that all of them have a purpose in your project. So this is an assumption, and here’s the fact — each of them has name, which you probably need to remember. Some describe its usage — like anti-ecological tree-kill, some not. It could take forever to guess what forever is doing. Some names are similar but serve different purpose, like pad-left and lpad. Can you guess without clicking?

JavaScript developers pictured trying to find their way around in node_modules directory :(

So, we see — there’s a lot of JavaScript third party code that you can use in your code. And it’s going to be more and more of that. And people will need to find new names. Programmers are not necessairly language teachers. Well, at least human language teachers. Well, umm, okay, this guy is. So, he can name his library as he likes, because he’s entitled to do that.

Rest of us instead of finding well-suited names, often take random words and use it as name for our code. We, the programmers, like certain words more than the others. For example, wrapper (bin-wrapper, do-wrapper, word-wrapper, events-wrapper, circuit-breaker-wrapper). There’s even a rapper. But it’s not normal rapper like Eminem, it’s more like:

Construct wrappers around api RESTful endpoints (Browser/Angular/Node)

So basically rapper will give you wrapper.

It’s not the kind of rapper you’d expect from rapper

The problem

As we know JavaScript is a popular language. There might be more than 100 000 people who use it on daily basis. Whether they use it in their job or just to make coffee (coffee-maker). It has a place in daily developer (and computer user) life.

So, JavaScript and its earlier version — Java are already becoming mature enough to use it for more than just programmatically finding good place to eat burrito.

There’s this game — think of any random word from English language — if there’s such JavaScript library — you drink. If you don’t want to get drunk too fast, stay at home.

There’s going to be more and more libraries and we’ll sooner or later run out of names for them. I believe it could hit us earlier than year 2038 problem. Why? We know JavaScript is state of mind. Programmers have kids. It’s a fact, you can’t argue. Kids usually acquire state of mind from their parents. Which means population of JavaScript developers can grow very fast.

JavaScript is more than a language, it’s a drug

The Maths

Today there are 100k JavaScript developers. They’ve managed to produce almost 500 000 node modules in 21 years (JavaScript was born in 1995, shit, older than me). We’ll take 20 for simpler maths (I’ve finished only high school, don’t require more from me). There’s like 200 000 words in English. According to maths we’re already doomed (500k > 200k === true). But let’s assume you can build sentences from words — this gives us more options.

Example: take stupid and other words and it’ll make your library name. Like: stupid + dictionary = stupid-dictionary. Yeah, dictionary can totally be stupid. What’s also stupid or frustrating. Maybe delay. Yeah, why not, waiting and delays definitely suck. Let’s combine stupid + delay. Here we go, stupid-delay! Oh, no, both already taken! Time is running away. Pardon, names are running away!

We need to be quick! Back to maths! 100k developers, 500k modules, 20 years, 200k words. If, on average, every developer has 2 kids. This means that in 20 another years, in 2037 (year before 2038 year problem!!!) these kids will become new JavaScript developers. This means that we’ll have 100k developers + 200k new-born developers = 300k JavaScript developers. Also, according to maths, before 2037, current 100k developers will produce another 500k modules (like they did 1995–2017). This means we will have already 1 million modules, 300k JavaScript developers, and still only 200k English words. In another 20 years (2037–2057) 300k developers will produce 3 times more modules — 1.5 million. Wrapping ( ͡° ͜ʖ ͡°) it up we’ll have following numbers in 2057:

300 thousand JavaScript developers

2.5 million node modules

200 thousand English words (insufficient)

1 big problem with names

I hope that you agree with me now that we need to take care of this problem before our kids have to! We can’t leave them with this ultra-hard-to-solve problem!

Potential solutions

We can start generating hashes and uuids for new JavaScript frameworks. Imagine 2 developers talking to each other:

- Hey, I’m new to programming, which framework is the best for creating single page applications?

- Hello, I believe 77c29bcb-6422–462b-bb0f-1ba9fb1430cb is the best, but at work we use e778a475–7009–4fbd-9d83–16ebe6ef713d for its speed and flexibility. Other popular choices are b63e83ce-c6e5–4569-a8dc-b4ad34ffbb7e, c5b8999c-999f-4c8a-811a-d93f77ef5687 and d33df2b9–9325–434a-a507–988cce172cde. Hope I’ve helped!

- That’s great! Thanks a lot!





2. We can use QR codes, images, author’s voice sample, something unique and put it instead of name in our package.json.

Libraries could be identified by their authors rapping

3. We can try to unify everything as Romans tried or Esperanto. Merging every module out there to Node API or browser API seems like a good idea for a start. We could get rid of all dependencies!

4. Humanity will repent, abandon all modules, go back to Vanilla JS and salvation to JavaScript will be granted through minimalism.

The choice is yours.