JavaScript Gom Jabbar
The article was fine until this part near the end:<p>&gt; engines prominently lists node. And while you hate it with the depth of your soul, you are not going to Bun or Deno because you know this will not stop the pain. This will only make the pain worse.<p>Deno will make the pain worse?<p>Nearly every complaint in the article could have been solved by using Deno.<p>- Package.json, no such thing for Deno (not unless you go out of your way to infect Deno with it)<p>- main, browser, and fs don&#x27;t matter in Deno since Deno&#x27;s APIs are based on browser APIs.<p>- type, module, requires, and imports doesn&#x27;t matter in Deno since it shares the same import API as browsers.<p>- scripts, doesn&#x27;t matter since all Deno projects have the same tools built-in (benchmarker, bundler, compiler, formatted, linter, task runner, test runner, etc...)<p>- watchman doesn&#x27;t matter since deno has watch support built in<p>- dependencies doesn&#x27;t matter anywhere near as much because Deno comes with a standard library<p>- left-pad doesn&#x27;t matter because it&#x27;s part of the language<p>- moment.js doesn&#x27;t matter since you can just use the browsers built-in Temporal api<p>- resolutions, dev-dependencies don&#x27;t matter for the same reason that dependencies doesn&#x27;t matter<p>- eslint doesn&#x27;t matter since deno has a linter<p>- postcss matters less because modern css is great<p>- jest doesn&#x27;t matter because deno includes a test runner<p>- no need to work out typescript installation with your dependencies because deno includes typescript and has less dependencies<p>The only things not solved by using deno is version and name, which are universal concerns amongst all projects, not just the js ecosystem.