Node's Complexity Problem
Ryan Dahl’s goes over his regrets while building Node that led to its unnecessarily complex state today.
Too much config
Starting a new project in Node.js requires several steps before you can actually start programming. Setup TypeScript. Setup your testing framework. Setup a formatter. A linter. A type checker. Set up your bundler. Add the right plugins. And after selecting your tools, tweak all their config files so they work well together. Some Next.js projects have over 30 config files in them.
Programming should be just that — programming — and not configuring tools before you write a single line of code.
runtime, web standards and interoperability were not the main focus. As a
result, Node.js invented its own set of APIs (e.g.
path, to name a few)
This led to further complexities when using Node.js to build for the web, as
you’re now required to add bundlers, source mappers, transpilers, shims, and
more into your workflow.
Module loading and resolution
node_modules folder and its “vendor-by-default” strategy massively
complicates the module resolution algorithm. Sometimes different packages
require different versions of other packages, leading to complex dependency
trees with circular and peer dependencies requiring a different version of the
same dependency. This results in time spent auditing dependencies as well as
long build times.
The scope of npm’s
package.json expanded over time and today includes too much
details like LICENSE information. If you want to write and share a single file
Deno: a clean start, built for the web
We recognized these deaths-by-a-thousand-paper-cuts with Node.js and re-imagined from the ground up what a modern, productive, and simple approach to building web and cloud software could be.
Deno is a single, simple system — not a myriad of disparate tools like npm, node-gyp, gulp, grunt, jest, etc. — with the development tools you need without any config needed so you can jump right into coding.
Learn more about Deno: