node fire

Internal Server Error

The server encountered an internal error or misconfiguration and was unable to complete your request.

Please contact the server administrator, nodejs@tirefi.re and inform them of the time the error occurred, and anything you might have done that may have caused the error.

More information about this error may be available in the server error log, unless you are using node.js

node fires are small but there are so many they will consume all your inodes


Apache/2.2.3 (CentOS) Server at tirefi.re Port 80

The node_modules Problem

The "JavaScript everywhere" pitch from 2009 was genuine: one language on the client and the server, shared libraries, reduced context-switching for developers. The part that wasn't in the pitch was node_modules. A typical Node.js project's node_modules directory contains between 500 and 1,500 packages. Most of them were not choices you made. They are the inevitable output of the dependency graph resolving, each package pulling in the packages it needs, which pull in the packages they need, until you have a directory structure containing more JavaScript files than lines of code in your actual application.

In March 2016, a developer unpublished 273 npm packages over a naming dispute. One of them was left-pad — eleven lines of code that padded a string on the left. The internet broke. React broke. Babel broke. The build pipelines of a significant portion of the JavaScript ecosystem ground to a halt because of a transitive dependency on a function that could have been replaced with ''.padStart(), which became standard JavaScript in 2017, possibly in direct response to this exact incident. This was technically an npm failure, not a Node.js failure. npm is Node.js's package ecosystem. The distinction is accurate and operationally irrelevant.

The callback hell that preceded Promises was a specific kind of pain: deeply nested asynchronous operations that were impossible to reason about when they failed, with error handling scattered across function boundaries in ways that made the stack trace useless. Promises improved this. async/await improved it further. The underlying problem — that the event loop is single-threaded and one blocking operation stops everything — did not go away. It became easier to accidentally introduce. The synchronous JSON.parse of a large payload, the fs.readFileSync someone added as a quick fix, the npm package doing synchronous crypto because it was written in 2013: these still bring the event loop to a standstill, they're just harder to find now.

More information about this error may be available in the server error log, unless you are using node.js.
— Apache/2.2.3 (CentOS) Server at tirefi.re Port 80