JavaScript is The New Plastic
By: Michael Krasnov
Tags: Coding, Programming, JavaScript, Frontend, Comparison

JavaScript is The New Plastic

Same level of pollution, just different space

JavaScript is an awesome language, it really is. Just like plastic was an awesome invention 100 years ago. But everything comes with consequences, whether it is environmental pollution or computing pollution alike.

Reader discretion advised: this is my personal view, which may or may not align with yours, and this is fine. If you have any constructive criticism to provide, I will be more than happy to reflect on that.

The problem with plastic

While some forms of such synthetic materials existed long before the 20th century, the true breakthrough came when we started making materials from oil. It eventually led to ability of creating durable materials with carefully designed characteristics at the lowest possible price. The economist’s idea of heaven.

It is important to remember that plastic (as a material) is inferior to most other types of materials (metals, carbon fibre, other types of composites) in specific applications. The advantage of plastic was that it was suitable for 90% of massively manufactured goods and this advantage outweighed the obvious superiority of conventional ones.

The fatal consequences of this decision was realized almost half a decade later, when it was a bit too late. All supply chains are centred on oil and plastics, consumers are used to it, alternative materials forgotten or never invented in the first place. “Specialists” in plastic industry deprecated instantly, while scientists and companies working on new types of materials are valued highly. Our ground, water supply, and most of the living organisms on earth are polluted with microplastics and there is no known way for man to filter it our. All thanks to cheapness, convenience, and reusability.

The problem with JavaScript

When JavaScript was invented, its sole purpose was to add a bit more interactivity to the web page. This resulted in a very simple language with many crucial features and practices overlooked. Then, bit by bit we started adding features to it, until it became a giant monolith that is able to run anything anywhere.

When I say a giant monolith, I mean the size of the runtime required to run it. Electron apps are shipped with a whole Chromium installation even for the simplest of apps (like a calculator). While there is an argument that we have all this computing power, might as well use it. Yes. We could use it to cure cancer, to sequence DNA genes, explore the stars. Instead, we use it to draw buttons.

JavaScript, much like plastics, had tied itself deeply in our everyday lives. You will find it in your browser, desktop apps, operating systems, phones, appliances and even rockets. Now, before reading the rest, just suppose that at some point in the future we will have to abandon JavaScript as fast as possible (like we do right now with plastic). Will it be easy?

The similarities with plastic do not end here. Let’s talk about npm packages now. Package-based dependency systems have existed for a long time. It includes both Linux-style package managers ( apt , zypper , packman , ...), ported Linux-style package managers (Homebrew, chocolatey , ...), and language-based managers ( pip , gem , Maven, ...).

Now, if you used any of those, I need not explain why npm is such an abomination to work with. You get tens of thousands of packages in your node_modules that may or may not work with each other, or contain malware, or be simply abandoned. The odds of this happening in a package are minuscule, but when you scale it up exponentially, the situation becomes frightening.

How often did you run rm -r node_modules and npm i again? Does this compare with how often you reinstall your OS? Developers are encouraged to depend on stuff, without thinking of the implications this dependency represents (much like building supply chains). This is all driven by the open-source dogma, saying that since anyone is able to fix the code, someone will. Well, he may or may not.

The last similarity with plastic is that JS is very cheap. Not as in the price for the SDK, like Java, but in terms of manpower. JS, being an overly simple language, allows literally anyone to build an app after watching a 2-week long course.

Not that it is bad as it is, but we use these apps in production. In production in cars, rockets, health systems, private communications and so on. So, JS is a very cheap language, that lets you create very cheap applications. For every use of JavaScript (except websites, for now) there is a more robust language that will be better-suited for the task, but looks like we are not in it for quality.

Do not get me wrong

I love JavaScript. This is the perfect playground, that lets you practice, learn, prototype, and iterate at a backbreaking speed. But I stand on these 3 views that I think are imperative:

JavaScript is not going to be the most popular language. Just because the JavaScript interpreter and the OS that runs the JavaScript interpreter has to be written in something else by definition. In addition, the rise of WebAssembly will bring most of the compiled languages to the browser, creating a very tough competition for JavaScript We should consider the level of responsibility of the system we are building and ask ourselves this question: was the language and framework we are using built using the same level of responsibility? For a lot of apps, this allows the use of JavaScipt and the like. But for systems that human lives depend on, JavaScript is not an answer. For example, if the 9–1–1 call on your phone was implemented in JavaScript, how confident would you be? Or a gas leak detection system? Or your webcam? The situation is getting better both in regards to plastic and JavaScript. You can now see the tree-shaking efforts in popular packages and security audits. But this is only the beginning of our JS detox.

Closing notes

Thank you for reading my rant on JavaScript, I hope we can still be friends. Let me know your views on JavaScript!

Resources