Thoughts, reflections, and ideas

Capitalism and Javascript

Posted on

Capitalism is well known for using itself to solve the problems it creates. Take the climate change issue; they turned slowing it down into another capitalist game by selling an offset carbon package. I feel that phenomenon spans to Javascript too. Javascript was pushed beyond their problem domain, and solving problems outside of that domain created new problems to be solved with more Javascript.

node_modules is a reflection of the capitalist nature of Javascript: layers and layers of problems and solutions that lead to an unmaintainable dependency graph and a vast surface for security attacks. It became so complex that complexity is a new problem domain. New frameworks, dependency managers, and JS runtimes are emerging to tackle that problem. The thing is that no matter how much you compress that complexity, it remains a brittle foundation.

Imagine building a skyscraper on a foundation with wood sticks stitched together with nails. One day the earth shakes, and the building collapses because the foundation was not correct.

In capitalism, many people aspire to become wealthier. Sometimes to the point of obsession. Many never profoundly connect to the problem domain because when they start going deeper, they see other opportunities to increase their wealth faster. The same happens in Javascript land. The consequence is a massive fragmentation of solutions abandoned halfway, and confused people trying to figure out how to combine them in a way that makes sense. Some see it as a modularized approach to build software. I prefer see it as an inability to reach consensus to create solid foundations.

The few solutions that could go more profound than others, like NextJS, do so by convincing FOMOed VCs that it is a good idea to motivate developers with money. And when money enters the game, you can throw some of it at bringing talent and marketing your solution to the point that people forget about the web standards and the problems they’d like to solve. We work so high up in the abstractions stack, that's easy to disregard the evolution of the standards, and thus the need for removing some of the abstractions no longer make sense.

There's surely an upside to all of this, innovation. But the cost you have to pay for that is huge, specially if you are running a business upon it. If comparisons help, does Peloton innovate in the area of fitness? It does. Whether that innovation is necessary for you is another question. Some people including myself waste our energy figuring out the right tool to workout while we could grab our classic bike or put on our shoes and go cycling/running across the forest. Do you see my point? Choosing for Javascript feels like adopting a costly solution like Peloton and not doing anything in the end with it.

The above is why I have a hard time betting on and embracing Javascript and any of its supersets (e.g. Typescript). Every time I play with it, I get to a point when I realize most of the abstractions, tools, and layers of indirection are unnecessary and sources of future headaches in my projects. I go back to Ruby, Rails, and Jekyll when that happens. They are close to the standards, their mental models are easy to grasp, and built upon a well-supported and thought foundation. It’s a safe bet and, more importantly, and FOMO-free environment. It’s easy to focus on building and not on figuring out the best solution to cache state client-side that comes from a GraphQL CDN-cached API to build a TODO app.

In 2022, I’ll remain open-minded about Javascript's direction and focus on solutions that are close to the standards like Ruby, Rails, and Sass. There needs to be all different roles in this world, and the one I'd like to take is pushing for open technologies that remain close to the standards.