About JS Ledger

A technical publication is easy to judge on what it covers and hard to judge on how it was made: who picked the subject, where the numbers came from, whether a language model wrote a sentence of it. JS Ledger covers JavaScript, TypeScript, and the systems that run them. It is written by Jonah Vail, and the rest of this page answers the harder question.

Why this site exists

A ledger records what happened. It is not a place for impressions, and a good one can be audited by someone who was not there. That is the standard this site holds itself to, and the reason it is named the way it is.

Most writing about JavaScript describes how an API is meant to behave. This site is interested in the gap between that description and what the machine actually does: why a function that looks identical to another one runs four times slower, why a type narrowed in one branch and stopped narrowing in the next, why a build that works on one machine produces a different bundle on another. Answering those questions means going one layer down — into an engine’s optimization pipeline, into a bundler’s module graph, into specification text nobody reads. The answers are usually less mysterious than the folklore around them, and they are almost always more useful.

The aim is a body of work that outlives the version it describes. An article whose method is visible can be re-run and disproved years later, which is more than can be said for an opinion. Independence is part of the same design: no advertising, no sponsored content, no affiliate link, and no arrangement under which anyone pays for coverage. The site is static HTML with no cookies and no tracking, so there is no audience metric here to shape a subject against.

Who writes this

Jonah Vail writes about JavaScript, TypeScript, and the systems behind modern web applications. His work sits beneath runtimes, frameworks, and tooling: ECMAScript semantics and the exact specification wording that decides an edge case, TypeScript’s inference and the points where it gives up, V8’s optimization and deoptimization paths, the event loop and memory behavior under load, module resolution and the graphs bundlers build out of it, and the class of failure that only appears once something is deployed.

He prefers source code, reproducible experiments, and measurable behavior to received wisdom. In practice that means reading the specification paragraph rather than a summary of it, running the case on a named version rather than recalling how it behaved, and saying plainly when something has not been checked. Most of what appears here started as something that broke or measured wrong in a production system he was working on, which is why the examples tend to be awkward in the way real code is. His profile at Cognate Press, the imprint this publication belongs to, lists the rest of his work.

What gets published, and what does not

Articles fall into five areas and belong to exactly one. Language internals: ECMAScript semantics and TypeScript’s type system, as the specification requires rather than as a tutorial claims. Frameworks: reactivity models, rendering strategies, and the machinery under React, Solid, Svelte and Vue, covered as mechanisms rather than as recommendations. Tooling and build: bundlers, dev servers, transpilers, and module resolution, the part of the stack that is invisible until it breaks. Runtime and performance: V8, the event loop, memory, and the methodology of measuring any of it honestly. Ecosystem and production: npm, the supply chain, Node and its alternatives, and the behavior that shows up only after deployment.

Whatever the subject, an article here is written to be checked. Versions are pinned to the patch, “Node 24.18.0, V8 13.6, TypeScript 5.9.3” rather than “a recent version”, because engine behavior changes and an unversioned claim has no way to be verified later. Every number appears beside the command that produced it; a number without a method is an anecdote wearing a lab coat. Sources are primary — engine source, the specification, the changelog, the pull request, in preference to another article about them, this one included. Claims that are only inferred say so in the prose, which is what makes the measured ones worth believing. When an article turns out to be wrong it is corrected in place with a dated note saying what changed, and nothing is silently rewritten.

That standard rules a great deal out. No framework rankings, no top-ten lists, no article whose real subject is a product, and no beginner tutorials: there are excellent ones elsewhere, and writing another would mean covering ground where nothing needs checking. Nothing is written to a keyword brief, and nothing is published because a release happened and the moment seemed right. Guest posts and sponsored articles are declined. Articles are long when the subject is and short when it is not, with a floor of six hundred words of prose; the real constraint is that a paragraph which only restates the last one gets deleted rather than padded.

How an article gets made

Every piece on this site goes through the same three steps, in this order.

1. The author chooses the subject and writes the draft. The subject comes out of work rather than out of a keyword tool: something that failed in production, a measurement that did not match the documentation, a behavior that survived a version bump when it should not have. Jonah Vail writes the first draft from that material, with the real code, the real output and the real version numbers in it.

2. A language model anonymizes and copy-edits that draft. It strips identifying detail out of the production material: client and employer names, internal service and repository names, anything that would identify a system this site has no standing to expose. It also fixes spelling, grammar, and the awkward constructions every first draft carries, and returns text that is ready to publish. The model works on language. It does not choose the subject, supply facts, produce numbers, or reach conclusions, and nothing it writes is treated as evidence.

3. The author audits the result and signs it off. Before anything is published, Jonah Vail reads the edited draft against the original: every claim, number, version and identifier is checked back against what was actually run, and anything the edit rounded up into a stronger statement than the evidence supports is put back where it was. The final wording is his. An article ships when he is willing to answer for it, which is what a byline means.

Two things follow. The prose here has been machine-edited and the claims in it have not been machine-made: no measurement, version number or conclusion on this site originates with a model. And when something here is wrong, one person is answerable for it. Corrections go to the address on the contact page, and one that turns out to be right is published with credit unless you would rather it were not.