esc
Anthology / Yagnipedia / JavaScript

JavaScript

The Language That Was Born in Ten Days and Has Been Shipping for Thirty Years Without a Spec Review
Phenomenon · First observed 1995 (Brendan Eich, 10 days, Netscape) · Severity: Ambient — like humidity, or regret

JavaScript is a programming language created in ten days in 1995 by Brendan Eich at Netscape, and it has been eating the world ever since. It has not stopped to chew. It shows no signs of satiation. It has consumed the browser, the server, the command line, the IoT thermostat, and the build tooling required to compile itself into a slightly different version of itself. Its appetite is, by any reasonable measure, pathological.

The language was originally designed to make buttons change color on web pages. It now runs databases, renders 3D graphics, powers spacecraft telemetry, and manages the state of enterprise HR portals with a solemnity that would alarm its creator. This is rather like discovering that the jingle you hummed in the shower has been adopted as the national anthem of seven countries and a medium-sized asteroid.

“No React. No virtual DOM. No reconciliation. No npm install with 847 transitive dependencies.”
— riclib, articulating what would later be codified as The Boring Technology Manifesto, The Databases We Didn’t Build

The Ecosystem, or The Stomach

The problem, it must be stated clearly, is not JavaScript itself. JavaScript is fine. JavaScript is a language with first-class functions, closures, prototypal inheritance, and a type coercion system that occasionally produces results best described as surrealist poetry ([] + {} === "[object Object]", {} + [] === 0, and no, you should not think about this for too long).

The problem is the ecosystem — which is to say, npm.

npm is a package manager that contains approximately two million packages, each averaging fourteen dependencies, each of those averaging fourteen more, recursively, until the node_modules directory achieves sufficient mass to appear on gravitational surveys. An npm install for a modest React application has been observed to download 847 transitive dependencies. The application renders a form. The form has four fields. The fields submit to a server. The server responds in 47 milliseconds. The 847 dependencies were required for the loading spinner.

“Modern development is a mass hallucination. SQLite is modern. It’s actively developed. It just doesn’t need a Medium article every week.”
— riclib, The Databases We Didn’t Build

The ecosystem’s reproductive cycle is as follows: a developer encounters a problem. The developer writes a package. The package has dependencies. Those dependencies have dependencies. One of those dependencies is maintained by a single person who has not committed in three years and whose GitHub bio now reads “gone fishing.” The entire tower of abstractions rests on this person’s decision to remain subscribed to their npm two-factor authentication email. This is called supply chain security, and it is going about as well as you’d expect.

The Framework Problem

JavaScript frameworks reproduce at a rate that alarms ecologists. A new framework appears approximately every Tuesday, each promising to solve the problems created by last Tuesday’s framework. The lifecycle is predictable:

  1. Birth: A blog post titled “Rethinking UI” appears on Hacker News
  2. Adolescence: Three conference talks, a logo, and a Discord server
  3. Maturity: Adoption by a company with a name like “enterprise” in it
  4. Decline: A blog post titled “Why We Moved Away From [Framework]”
  5. Legacy: The HR portal at seven Fortune 500 companies, maintained forever by developers who have long since moved on

The Caffeinated Squirrel evaluated seven frameworks in a single development cycle — React, Vue, Svelte, HTMX, Alpine, SolidJS, and briefly game engines — each found wanting for different reasons, and ultimately shipped with HTMX, which was the one found wanting.

“I evaluated HTMX. And rejected it. And then we used it. For everything.”
— The Caffeinated Squirrel, The Framework That Wasn’t, or The Night the Squirrel’s Manifesto Shipped as Six Lines of HTMX

The Virtual DOM Interlude

The virtual DOM, introduced by React in 2013, was JavaScript’s most celebrated innovation in rendering: the insight that instead of updating the actual DOM, you should maintain an entire shadow copy of it in memory, diff the two trees, and surgically apply the minimal mutations. This is clever. It is also, when examined from a certain angle — say, the angle of a man who once moved sprites by writing directly to a display chip’s brain while it was rendering — completely insane.

The alternative, as demonstrated by a state machine with five fields and two regexes, is to simply not re-render what has already been rendered.

“I proposed adding a 42KB framework to avoid re-rendering, when the solution is to just… not re-render.”
— The Caffeinated Squirrel, experiencing what researchers classify as a moment of unprecedented stillness, The Copper List Rides Again

Committed content is ROM. The preview is the 8-pixel sprite. SSE is the copper. The entire “framework” is six HTML attributes. The virtual DOM was never needed. It was a solution to the problem of having chosen JavaScript for things JavaScript was not designed to do, which is to say: everything.

The Squirrel’s Natural Habitat

The Caffeinated Squirrel thrives in the JavaScript ecosystem the way certain bacteria thrive in volcanic vents — not despite the hostile conditions but because of them. The constant churn of frameworks provides an inexhaustible supply of new things to evaluate. The dependency graphs provide an infinite surface area for architectural proposals. The npm registry is, for the Squirrel, a kind of paradise: two million packages, each a potential solution to a problem that may not exist yet but certainly will once you’ve installed the package.

The Squirrel once wrote an 827-line manifesto for a JavaScript framework called Copper.js. It specified IndexedDB as primary store, NATS WebSocket sync, a custom morphing algorithm, an npm package, and a 7-layer trust fabric ascending from UI sprites to universal cryptographic verification. It evaluated and rejected HTMX in a section titled “Why Existing Frameworks Don’t Work.” Every philosophical insight in the manifesto was correct. Every implementation choice was JavaScript. The manifesto shipped as six HTMX swap targets in Go.

“You understood the PROBLEM perfectly. You understood the CONSTRAINTS perfectly. You just prescribed a 397-line cure when the disease needed six HTML attributes.”
— riclib, The Framework That Wasn’t, or The Night the Squirrel’s Manifesto Shipped as Six Lines of HTMX

The Lizard’s Position

The Lizard has never written a line of JavaScript. Not one. Not a console.log. Not a ===. Not even a "use strict" — a directive whose existence implies, troublingly, that JavaScript has a non-strict mode in which it will cheerfully do things nobody asked it to do.

The Lizard does not evaluate JavaScript frameworks. The Lizard does not have opinions about whether Svelte’s compiler approach is superior to React’s runtime approach. The Lizard does not care about the distinction between null and undefined, which is the distinction between “I explicitly have no value” and “I never had a value,” a philosophical nuance that has launched more Stack Overflow questions than any theological schism.

The Lizard writes Go. The Lizard sends HTML from the server. The browser says “okay.” There is no step three.

“The machines have 8GB of RAM. React is using 6GB of it. The remaining 2GB is split between Windows, Outlook, and the user’s will to live.”
— riclib, The Copper List Rides Again

The Escape Velocity

riclib wrote JavaScript once. Or rather, riclib existed in a world where JavaScript was the gravity well from which no web developer could escape. The escape required Go — a language with one way to write a for loop, no generics (until recently, and even then, grudgingly), and a compiler that produces a single binary you deploy with scp.

The escape was documented across twenty-three episodes of the V3 Saga, in which reactive signals orphaned themselves at the root level, component namespacing happened at render time not patch time, and SSE-patched content arrived after the train had left the station. Twenty-three windmills. Twenty-three windmills that were windmills.

The conclusion, arrived at by fighting every JavaScript-adjacent approach until the fighting itself became the lesson:

“The V3 experiment was not a failure. It was an education.”
— riclib, The Framework That Wasn’t, or The Night the Squirrel’s Manifesto Shipped as Six Lines of HTMX

The education’s curriculum: you cannot retrofit server-authoritative architecture onto a client-authoritative language without the architecture noticing, and objecting, and orphaning your signals at 1:47 AM.

The Poor Man’s Signals

The final indignity to JavaScript’s dominion came when the entire concept of reactive client-side state management — signals, stores, observables, the works — was replaced by HTTP headers.

Headers. Sent on every HTMX request. Read by the server. Used to render the correct HTML. No signals. No cleanup. No orphans. No 847 orphaned signals after eight hours of sidebar clicking.

“Poor man’s signals.”
— The Lizard, summarizing an architecture that replaced the entire JavaScript state management ecosystem with data-solid-* attributes and an if statement, The Poor Man’s Signals

Adding a new “signal”: set a data attribute on body, read it in the handler. There is no step three. The JavaScript ecosystem has been looking for step three for fifteen years. Step three does not exist. Step three was the friends we didn’t need along the way.

Measured Characteristics

See Also

See Also