The Node.js Ecosystem Is Chaotic and Insecure
The &quot;modern&quot; JS ecosystem:<p>1. Over-reliance on tooling. JS was made as a scripting language, if you can&#x27;t use it as such, its purpose is lost. And that tooling works against betterment of the ecosystem - lib authors rely on tooling to fix issues of the platform, rather than seeking a definite solution.<p>2. Any serious JS project is a long term maintenance burden. The prevalence of &quot;single line libraries&quot; makes future-proofing of the code impossible. You don&#x27;t only have to version-freeze your immediate dependencies, but dependencies of your dependencies. You will have to manage their version manually, it all becomes your own problem.<p>3. Authors of JS VMs swear on their firstborns that JS performance has been greatly improved, yet, it sucks. For practical purposes, JS code is barely as quick as perl or python.<p>4. Too much evals in 3rd party code everywhere. The only way you can secure your front-end is to ensure no third party code policy on your page. When it comes to the back-end, things become more grave. On the back-end, you can say that there is no universal solution.<p>5. Zoo of standards on the front-end, browser APIs changing on a whim.<p>6. Zoo of sublanguages: Coffeescript, LiveScript ClojureScript, MoonScript, AtScript, TypeScript. Having to mix anymuch of them in a single project is, you can guess, a supernightmare.<p>Yet, I don&#x27;t completely hate people who want to move JS forward. TC39 may well be too heavy on being staffed by theoreticians, but they have right priorities: standardization, having whatever going into the standard being highly dry before even approaching the pre-standard status, enforcing a semblance of synchronicity to the ecosystem.<p>What JS needs in my opinion:<p>1. HARD VERSIONING<p>2. Compliance certification through testing with a hard version<p>3. An even harder enforced decoupling of the paper standard and implementation. While the majority of modern JS implementations are VM based, this should not make the standard to accommodate design decisions dictated by a VM implementation.<p>4. Readiness to do breaking changes in between major hard versions, and no reservations for backward compatibility.<p>5. Many browser APIs are de-facto parts of the standard library as such. They need to be managed as a part of the standard.