Spokes.wiki Search About

Synthesis — Developer Tooling

The evolving thesis. Spun out of the hub _inbox on 2026-06-18 from three developer-infrastructure strays that had no home and, between them, sketched a domain: the systems-level tools and libraries that build, version, and move software. This founding synthesis is deliberately about the shape of that domain — three sources, three different layers — rather than a single tight argument; it sharpens as more sources land.

What this spoke owns

The pipeline a programmer's work flows through that isn't the application code itself:

These are distinct topics, so the spoke is broad by construction — closer to ../game-engines-wiki or ../search-marketing-wiki in breadth than to a single-subject spoke. The bet is that they cohere as one practitioner's concern — "the tools under my code" — even though a compiler, a VCS, and a wire format share little machinery.

The one real cross-cutting thread (so far): systems-language rewrites for raw speed

The clearest pattern across all three founding sources is performance won by dropping a layer of overhead, usually via a systems language:

So the unifying move isn't a shared technology; it's a shared strategy: take an established developer-infrastructure layer (typechecking, parsing, revision control) and remove its dominant runtime cost, leaning on Go/Rust/C++ to do it. All three are also big-tech open-source (Microsoft, Yandex, Epic) — infra built for an internal scale problem and released.

The fourth source breaks that pattern — and that's the point. block-monorepo-migration (Block: 450 JVM repos → monorepo) is not a systems-language speed rewrite; it's a structural / developer- experience story — consolidating repos to kill dependency drift, paid for with custom build tooling and a funded platform team. So the systems-language-speed thread was a coincidence of three founding launches, not the spoke's spine. The spine is broader: the infrastructure under the code — built, versioned, and moved — whatever the lever (raw speed, structure, or coordination). It also ties the corners together: monorepo scaling is a VCS problem (lore's territory) and a build problem at once.

A fifth source confirms "the layer, not the lever" inside the compiler corner. v-flat-ast (the V language's compiler moving to a flat-ast) is a second compiler source beside typescript-7-go-compiler — but a different lever again: TS7 won ~10× speed by changing the compiler's host language (TS→Go); V won ~15× memory (self-hosting RAM ~6 GB → 400 MB) by changing the compiler's in-memory data layout (pointer-linked tree → flat index-linked arrays). So the compiler corner now holds two performance stories with no shared lever — language-port vs. data-oriented layout — which is exactly the spine the spoke settled on: it's organized by the layer (here, compilers), not by any one technique. flat-ast also reaches across corners to yaff: dense contiguous storage with indices/offsets instead of pointers is the same memory-layout discipline, applied to an AST in one case and a wire format in the other.

A sixth source adds a new lever — and a new question about who pulls it. clickhouse-rowbinary (ClickHouse's JS library for its RowBinary wire format) lands in the serialization corner beside yaff, but wins performance a fourth way. The levers so far: language-port (typescript-7-go-compiler), data-layout (flat-ast, yaff), and incremental-tuning-of-the-incumbent (git 2.55). RowBinary adds specialization / codegen — monomorphization: generate a parser narrowed to the exact column types so the JIT (V8) can inline it, instead of a generic reader whose megamorphic dispatch it can't. That slots neatly into "the layer, not the lever": same serialization layer as YaFF, different lever (YaFF drops the parse step via zero-copy; RowBinary keeps a compact varint format but drops the dispatch via specialization). The new wrinkle is who does the specializing: not a protoc-style schema compiler but an LLM agent reading densely-commented primitives through a bundled SKILL.md — the "library is the parser compiler" framing. That's the first source where the dev-tool's compilation step is an AI agent, an adjacency to ../agentic-tooling-wiki (the skills machinery) that this spoke should watch: if more "library-as-agent-skill" tooling lands, "who compiles the toolchain" becomes a spine question, not a one-off.

The language corner left this spoke (2026-08-05). Three sources — dart, kotlin (with kotlin-and-android) and jank — built a programming-language corner here between July 15 and 19, and on 2026-08-05 the curator narrowed this spoke's domain and moved those pages to ../programming-languages-wiki, which had spun out the same day. What they were doing here is worth stating once, because half of it stays and half of it goes.

Stays: the compiler-performance thread. Kotlin's K2 frontend rewrite (Kotlin 2.0, 2024; up to 94% faster compilation, 376% faster analysis) is a fourth lever in this spoke's compiler corner beside host-language port (typescript-7-go-compiler), data layout (v-flat-ast) and specialization/codegen (clickhouse-rowbinary). A compiler getting faster is build infrastructure and this spoke's business, whatever language it compiles. So is the dev-vs-ship compilation split (JIT for the iteration loop, AOT for the shipped binary) that Dart and jank both instance — a toolchain design decision this corner keeps meeting.

Goes: what the languages mean. "One source, many backends" (Dart to native/JS/Wasm, Kotlin to JVM/JS/native/Wasm) and jank's host swap — the same Clojure semantics re-hosted from the JVM onto C++ — are claims about language design and about which runtime a language targets. Those belong with clojure and the hosted-language thread next door, and they read better there: jank against Clojure is one language on two hosts, which is the cleanest evidence either spoke has that a language and its runtime are separable.

Two consequences here. The ownership observation survives the move — jeaye-wilkerson funded by community sponsors was this spoke's second commons-shaped maker, and with that page gone openapi-tools and replikativ carry the pattern alone. And jetbrains stays, still opening an IDE/LSP stratum this spoke has never sourced, which is now a growth edge with no language page propping it up.

An eighth source opens a corner the spoke listed as empty — and answers "who compiles the toolchain" with a second, older voice. openapi-generator (a 2018 community fork of Swagger Codegen; 50+ client and 40+ server generators from one OpenAPI spec) is the spoke's first API-contract / codegen source, and it arrives as the exact thing clickhouse-rowbinary was defined against. The RowBinary entry above was filed as "not a protoc-style schema compiler but an LLM agent reading a SKILL.md" — OpenAPI Generator is the protoc-style schema compiler, deterministic and template-driven, 26.5k stars and eight years old. So the "who does the specializing" wrinkle is now a genuine two-sided question rather than a one-off observation, and schema-driven-codegen pages both poles: generator writes the code (reviewable, reproducible in CI, bounded by which templates exist) vs agent writes the code (unbounded targets, no templates to maintain, no determinism). Both start from the same premise — don't hand-write what a machine-readable contract already implies — and disagree only about what reads the contract.

It also lands the lever framing again: OpenAPI Generator isn't a performance story at all (not language-port, not data-layout, not specialization-for-speed). Its lever is drift elimination across N languages — much closer to block-monorepo-migration's structural/coordination play than to any of the speed rewrites. Second confirmation that the spine is the layer, not the lever.

And it breaks the ownership pattern. Every prior source here is big-tech infrastructure released outward (Microsoft, Yandex, Epic, Google, JetBrains). OpenAPI Tools has no corporate parent — it's a contributor body that left one, funded by Open Collective and sponsors, and explicitly not affiliated with the OpenAPI Initiative that owns the spec it implements. The dominant implementation of a standard sitting outside that standard's governance is a new shape on this map, and the spoke's first data point on dev infrastructure as commons rather than vendor output.

A ninth source adds a third stance toward Git — and a new VCS lever: queryability. geschichte (from the replikativ Clojure collective) lands in the now-densest version-control corner, but it neither rewrites the format for speed/assets (lore) nor tunes the incumbent in place (git 2.55). It wraps Git — reads/writes real Git objects, packs, and wire protocols — while storing repo state (refs, history, worktree) in Datahike, a Datalog database, so history becomes something you query rather than walk. That's the corner's fourth lever and a genuinely new one: not language-port, data-layout, specialization, or incremental-tuning, but version-control-as-a-database (queryability). It also stakes a third position on the "what to do about Git" axis the corner keeps circling — replace (Lore's clean-break format) vs tune (Git 2.55's incremental optimization) vs wrap (geschichte's interop-plus-query overlay). And it borrows across corners: its content-defined chunking for binaries is lore's large-asset move, applied inside a queryable store. On ownership it lands with openapi-tools and jank on the commons side, not big-tech — a community collective, the spoke's third non-vendor maker. (jank moved to ../programming-languages-wiki on 2026-08-05; the ownership point stands and the link is now cross-wiki.) Second Clojure data point too (jank was the first): the language now appears in two corners — a runtime and a VCS. Pre-1.0 and self-reported (T1 first-party, formats still moving), so the queryable-VCS claim wants a neutral test.

The reference point arrived last (2026-08-14)

The serialization corner grew backwards. yaff came in June describing itself as a zero-copy layout "for the Protobuf ecosystem" and naming .proto as its authoritative schema; clickhouse-rowbinary came in July as a competing binary wire format measured against JSON; schema-driven-codegen was written with protoc as its declared archetype. All three positioned themselves against protocol-buffers, and none of them could link to it, because the spoke had every reaction to Protobuf and not Protobuf. The curator sent protobuf.dev and grpc.io a minute apart and the negative space filled in.

Two things follow that the reactions alone could not show.

The archetype is the narrower tool. protoc emits message classes for about ten languages and stops; openapi-generator ships 50+ clients, 40+ servers, Postman collections and JMeter plans from one spec. What Protobuf has instead of breadth is a plugin boundary — which is how grpc attaches service stubs to a compiler that does not know what an RPC is. Extension by plugin API versus extension by Mustache template is the real axis under schema-driven-codegen, and the plugin side reaches things its authors never planned for at the cost of making you write a compiler plugin.

Freeze one artifact so you can version the other. protobuf-editions replaces the proto2/proto3 fork with per-field features on a yearly release train with two-year deprecation windows, and it can afford that pace precisely because the wire format does not move. The .proto language is source; the encoding is a contract with every byte anyone ever wrote. The spoke has watched several tools try to change something load-bearing without breaking users (git-2-55, typescript-7-go-compiler, block-monorepo-migration); editions is the tidiest statement of the strategy, and the one most worth stealing.

One asymmetry worth keeping in view rather than resolving: Protobuf's own docs list "situations requiring formal standards compliance" as a reason not to use it, while grpc, built directly on top of it, is a CNCF incubation project. The governed layer sits on the ungoverned one.

Open questions

A spec written after the fact, and where it had to work hardest (2026-09-02)

Every format this spoke holds was designed as a specification and then implemented: protocol-buffers and its wire format, OpenAPI and its generators. commonmark runs the other way. Markdown was released in 2004 as a Perl script plus a page of prose that did not describe it, went universal anyway, and got a grammar ten years later — written by people at GitHub, Reddit, Stack Overflow and Discourse who were each already parsing it differently and needed to stop. The spec is therefore archaeology, not design: its job was to decide which of several shipped behaviours was correct.

Its test suite is a map of where the implementations actually disagreed, and the map is surprising. Of 652 examples in v0.31.2, 132 (20%) are emphasis and strong emphasis and 90 more are links — 34% of the whole conformance surface on inline *, _ and [](), against 48 for list items and 27 for setext headings. Markdown is sold on headings and lists; those needed almost no disambiguation. The expensive part was what a run of asterisks means beside punctuation or inside a word. Where a designed spec's size tracks what the designers thought was important, a retrofitted spec's size tracks where the existing implementations diverged — so the section weights are evidence about the past, and they are the only such evidence this spoke holds.

And the freeze runs the opposite way from Protobuf. protobuf-editions works because the wire format never moves: freeze the artifact everyone depends on, then version the source language yearly on top of it. CommonMark froze the specification — 0.31.2 in January 2024, still 0.x after twelve years, no release since — while cmark and commonmark.js were both pushed the day before this ingest. Stability lives in the document and the churn lives in the code. Both arrangements are called a stable standard by their maintainers, and they put the stability in different places; nothing here yet says which one a downstream consumer should prefer, and that is a real open question rather than a tension.

One smaller thing, consistent with what this spoke keeps finding in first-party pages: the project whose entire purpose is removing ambiguity about which behaviour you get describes its own spec as "quite robust after many years of public feedback" and names no version number anywhere on its homepage.

Growth edges

Ranked; each names the kind of source that would close it (see ../QUALITY.md → Growth edges).

  1. Generator or agent, for codegen. Deterministic template codegen has eight years and 26.5k stars (openapi-generator); agent-driven specialization has one source and a SKILL.md. — needs: a T1/T2 comparison, or a second agent-codegen source with output quality reported.
  2. Whether the VCS corner is the spoke's actual centre. Three sources have now landed in it rather than scattering, which is evidence the spoke coheres. — needs: one more version-control or large-repo-scaling source to settle the cohere-not-junk-drawer question.
  3. Compiler performance, independently measured. typescript-7-go-compiler's 10× is first-party. — needs: a T2 benchmark someone else ran.

Coverage edges (added 2026-08-08, at the curator's request for a wider backlog). These widen what the spoke covers instead of answering an open question above; one ordinary solid source closes any.

  1. Package management. Half closed 2026-09-04 by pnpm (T1, the project's own Motivation page) and the concept page package-manager it anchors. The official-docs half is done, and it supplies a finding the edge did not ask for: pnpm's content-addressable store and symlink tree make an undeclared dependency unimportable, so dependency correctness becomes a property of the installer rather than the manifest — the same put-the-constraint-where-it-cannot-be-bypassed move schema-driven-codegen and protobuf-wire-format make elsewhere in this spoke. — still needs the measured half, and the hunt is the reason it stays open: every migration write-up found (3–5× faster CI installs, 60%+ disk reduction) was a personal blog with no stated baseline, no repetition and no cache-state disclosure. pnpm's own docs claim speed and attach no number at all. So: a benchmark someone outside the project ran, with the cache state stated — which is edge 3's requirement in a second slot, and now looks like a property of this field rather than of one tool. Half close 2026-09-22: package-manager-benchmark-cheezone (T2) is the first outside measurement with cache state stated — pinned fixtures, cold/warm/frozen scenarios, hyperfine in CI. Warm installs show pnpm 11–20× faster than npm, with small spread. But the harness was created that day, cold runs were sampled only twice for npm and pnpm, and disk use is not measured. Residue: edge 4a — the same measurement repeated (another day or another runner, cold runs ≥5 samples) plus a disk-use figure. — needs: a re-run of this harness or an equivalent T1/T2 study.
  2. CI, the place these tools actually run. monorepo and block-monorepo-migration both assume a build farm and no page describes one. — needs: GitHub Actions or Buildkite documentation plus a report on remote caching or build-farm cost.
  3. The lint-and-format layer's rewrite wave. Ruff, Biome and oxlint are the same layer-versus-lever story the spoke already tells with typescript-7-go-compiler, in a different slot. — needs: project docs plus one independently measured benchmark.
  4. The editor. jetbrains sits alone; VS Code, Neovim and Zed have no page, and the editor is where agent integration is being fought over. — needs: release notes or docs per editor. Cross-spoke: the agent harness itself stays in ../agentic-tooling-wiki.
  5. The CommonMark spec's own text. commonmark is built from the homepage, the version index, the test JSON and the GitHub API — so it can say what the suite covers and not what the grammar says. The emphasis-parsing rules are the specific gap, since that is where 20% of the tests went. — needs: the spec document at spec.commonmark.org/0.31.2/, and ideally one implementer's account of what was hard to conform to.
  6. Where a standard puts its stability. Protobuf freezes the wire format and versions the language; CommonMark freezes the spec and lets the parsers move. Two arrangements, no source comparing them. — needs: a downstream consumer's account of which freeze it actually relies on.

The IDE stratum gets its first source, and it is a pricing page (2026-09-14)

jetbrains has stood since 2026-08-05 as the marker for an IDE/LSP layer with nothing under it. rune-pricing is the first source in it, and what it documents is less the editor than the business shape of an open-source editor in 2026: rune is GPLv3, its coding agent is bring-your-own-model, and the only thing unstable-build meters is a network service between the user's machines (2 nodes free, 10 for $10/month, unlimited on contract). The bundle preserves the earlier model — commercial use behind a paid licence, with a perpetual option — next to the current FAQ that says commercial use is free, so the move to "free editor, paid service" happened and is undated. Set against the Cursor model the site itself quotes (plans that include model usage), that is the open question this stratum now has: whether an editor sells model tokens, a network, or nothing. Everything on both Rune pages is first-party, and the terminal benchmarks (Alacritty's vtebench, box plots) were not extracted — a T2 comparison would be the closing source, the same shape as edges 3 and 4.

A compiler that moves Java's decisions to build time (2026-10-04)

graalvm is the spoke's second compiler source after typescript-7-go-compiler, and the same shape: a maker's own page, a performance case in adjectives. Where TS7 at least cites 8.7-11.9x, GraalVM's homepage offers "instantly" and "a fraction" with no figure, so the Native Image claim is untested here. It adds a different lever: ahead-of-time closed-world compilation, which trades run-time flexibility for a build step, as monomorphization trades generality for specialized code. Growth edge 3 widens: an independently measured Native Image vs JVM comparison would close it for a second compiler.

Contradictions / tensions

No fact conflicts yet. One genuine engineering trade-off now recorded (not a contradiction): the monorepo vs polyrepo choice — monorepo trades per-team coordination overhead for a standing platform-team bill (block-monorepo-migration: "if you can't fund a platform team… do polyrepo").

Cross-spoke adjacency

Index — Developer Tooling Wiki

Catalog of every page, grouped by schema.org @type. Spine: synthesis (thesis), log.md (history), this file (catalog). Read this first when answering a query, then drill into the relevant pages. Updated on every ingest.

DefinedTerm (concepts / standards)

SoftwareApplication (tools)

SoftwareSourceCode (tools / libraries)

Person

Organization

TechArticle / BlogPosting (sources)

WebPage (sources)

Dataset (sources)

SocialMediaPosting (sources)

Synthesis

Related pages

Links to

Linked from