On the tooling in JS land
There are a lot of programming languages out there, but JS is special. JS is the only programming/scripting language natively supported by the web. That has caused it to be the most widely used programming language in the world. A huge amount of software that is written today, happens to be written in JS land.
I entered JS land for the same reason — to build for the web. When I started, the most dominant library/framework was still jQuery. Initially, I used only the simplest forms of JS. I was far away from using anything with a build step. JS tooling did exist then, but a large chunk of the internet was still not using any complex tools. JS frameworks were not mainstream.
The complexity of building JavaScript apps has only increased since then. There are so many transformations and optimizations applied before actually deploying an app to production. Obviously all that is present for a reason. I am happily typing away all this in a web app. This level of interactivity would be difficult to imagine without the tooling. All of you probably use a lot of apps that are actually web interfaces, without realizing. But all the complexity has caused a lot of pushback in the community. The argument is that using JS earlier was shooting yourself in the foot, but now there are frameworks to shoot yourself in the foot with a bazooka. Jokes aside but not exaggeration, when there is a new JS framework every hour, how do you even keep up with them?
The answer to that question, in my humble opinion, is that you don’t. The tooling that you are familiar with is perfectly fine. If you are building small projects, you probably don’t need to use a framework, JavaScript natively has most features that jQuery offered back in the day. You don’t need to keep up with the innovation. You can use the new method when your old method is not enough to solve your problem. If jQuery is sufficient for your frontend, don’t switch to React. Not everything has to use React. However, innovation in the space shouldn’t be stopped. I am very grateful that I am able to write this in a web app. I don’t need to install a text editor on my computer, and I can share my essays with people directly. There is plenty of software on the web which is vital for so many people’s jobs.
But, JS land does need to solve the issues that this ever increasing complexity of tooling brings for developers. A lot of the tooling is just very fragile and complex which inadvertantly results in gate-keeping. Although, now, efforts are being made to simplify this tooling. The people over at Deno are trying to simplify how the tooling is put together by instead bundling everything in the same Deno package. It was still not available on certain platforms (linux x64) the last time I tried to use it for work, but hopefully that would be fixed soon. The roadmap for Deno also includes compatibility for NPM packages. Even other new Node frameworks like Redwood are opting for batteries included approach.
JS land is vast. There certainly are some things that need to be fixed, but there are a lot of good things as well. The malleability of JS is what makes it easy to make good, bad, and horrible things to be written in JS. JS land has come far, and because of the inherent goodness of ideals, would go farther still.
“Always bet on JS — and WASM.” — Brendan Eich
