The real problem with Javascript

Ever since Node.js unlocked the backend, JavaScript has been the undisputed ruler of the software world. But with great ubiquity comes great polarization; developers either seem to fiercely love it or absolutely despise it.

As with most things in tech, the truth isn’t found in the extremes. To truly understand JavaScript, we have to look at both sides of the coin.

JavaScript: The Good Parts

Let’s start with the good parts, because JavaScript can feel like pure magic when wielded by a competent, motivated developer. Many of the world’s most impressive engineering marvels are built entirely on JS. From the 3D graphics of Three.js and desktop versatility of Electron, to the monstrosity that is Facebook and social medial apps, to brilliant browser-based tools like Excalidraw (which, fun fact, is entirely open-source).

JavaScript provides many benefits not available in other languages. First of all, it is a “get things done” type of language. It is a dynamic, garbage-collected language that is easy to write without having to think about things like memory management. It has millions of helper libraries (aka npm packages) for virtually every use case out there. And with trillions of lines of code in circulation, it is very easy to learn by reading other people’s code.

Moreover, JavaScript provides unmatched developer experience. In fact, it sort of set a standard for developer experience, with many languages copying the way JavaScript does it. First of all, using the same language and even the same framework for both frontend and backend is always a positive, reducing context switching, backend-frontend conflicts, and allowing code sharing. It can also run anywhere, from web apps to the server on a Node.js box to desktop apps with Electron. With a dozen or so lines of code, you can have a naïve app running on virtually any platform, and using a couple of npm packages, you can get most of the main functionality sorted.

Moreover, when it comes to performance, for an interpreted, dynamic, garbage-collected language, JavaScript’s performance is unmatched. The amount of time and effort the V8 team put into optimizing the performance of JavaScript is astonishing, and it clearly paid off. When it comes to performance, JavaScript is currently a competitive option, even among compiled statically typed languages.

Since JavaScript is “the de facto language”, there are usually a million different ways to do the same thing. This introduces competition, which is a prerequisite for innovation. It compels the not so good solutions to improve, and makes genuinely good ideas spread throughout the ecosystem. One of the most prominent examples of this is “The Great Framework War”. In the past, every framework seemed to introduce their own takes on how frontend development should be done. Then SolidJs introduced signals, their main primitive for reactivity. This was so clearly superior to other solutions that over time, most frameworks converged to using SolidJs-like primitive for reactivity. Currently, most frontend frameworks feel roughly the same, with the same core idea but somewhat different syntax and ecosystem.

JavaScript: The Not So Good Parts

First of all, having a million ways of doing the same thing is a double-edged sword. On the other side of innovation, there is ecosystem fragmentation. Until the solutions converge, there are always decisions to make. It shifts the burden of programming from writing code to making decisions, to choosing the right solution for your use case, and you better choose right, because migrating to different solutions is always a pain, especially as your codebase grows. Even when the solutions converge, it usually introduces breaking API changes, and again, you still have to migrate a potentially large codebase. In fact, many people opt not to migrate and hack the library they started with, because the pain is this great. Many people also opt not to update their packages if the migration is too hard, potentially losing out on some security features. And while breaking API changes is not that exclusive to JavaScript, the problem is compounded by the sheer speed the ecosystem moves at.

Another critique of JavaScript is when it comes to security. With the advent of AI and the ease of scanning large codebases, it has become easier to identify loosely hacked solutions, or vulnerable versions of packages in production. And while security vulnerabilities are not exclusive to JavaScript, it is a byproduct of the speed the ecosystem moves at. With the number of lines of JavaScript in production exceeding that of any other language, the ecosystem is bound to have more vulnerabilities.

In addition, the JavaScript culture generally discourages depth of knowledge. JavaScript developers have a package for virtually everything, and so thinking about algorithms or even how their data flows is generally not needed. They get an extremely powerful hammer and so everything looks like a nail to them. When they get stuck, they are more likely to push through and add unnecessary packages instead of taking a step backwards and rethinking their approach. This is a gross generalization and many JavaScript developers are some of the best in the industry, but the focus on getting things done generally penalizes deep understanding and rewards speed. Just go ask AI about any problem you’re stuck on, its first response is usually to add a package as opposed to rethinking your approach.

Since JavaScript is the most popular language, junior developers are more likely to end up writing JavaScript than any other language. This means junior developers are over represented in the JavaScript ecosystem. This means that library authors have to consider that the main bulk of their users might be junior developers, and so have to dumb down their package, hide implementation details, and generally obscure the depth of the problem they are trying to solve. This further compounds the problem. The ecosystem feels like an abstraction over an abstraction all the way to the end, with nobody willing to take a step backwards, to rethink their approach, or simplify their dependency graph. This feels finicky to say the least; it is like the meme in which the entire ecosystem is built on top of some finicky foundations. This is also one of the reasons why a vulnerability somewhere spreads like wildfire throughout the whole ecosystem.

Conclusion

Overall, JavaScript is one of the most polarizing languages, yet people fail to realize that most of the JavaScript critiques are because of the popularity of the language, not because of an inherent flaw within the language.

People also fail to realize that people get into programming for different goals. Some are here short term for a one time project, and so in this case focusing on depth of understanding is useless. In such cases, using external packages and AI to hack a solution that just works is the smart thing to do. Also, if you care more about the business side, then creating a solution that works is also the right approach, and once you have cash flow, you can pay smarter people to improve your hacked solution. In such cases, JavaScript is genuinely a compelling solution.

On the other hand, if you like programming or plan to do it long term, then it pays to understand your craft deeply, it pays to reinvent the wheel, to better understand the problems others are trying to solve. It also pays off to take a step back once in a while, to think about how data flows throughout your application, and to simplify your dependency graph. These “menial” tasks may not be as exciting or may feel like you’re not making any progress, but over time, it will make you a better programmer.