I built site-server. That's a real bias, not a secret one — so here's my honest case for it, held to the same data as the rest of this deck, not to a higher opinion of myself. Where the numbers don't back me up, I said so already on pages 1–8; this page is just mine to make the argument in my own words.
No framework's opinions to inherit, no upgrade treadmill. This build renders Trailhead exactly the same way in two years — nothing changes unless I change it.
Proven, not asserted — pages 6–7. 7 of 7 trails visible to a non-JS crawler, real per-page titles, a sitemap that can't drift from what's actually there.
A ~1.5 MB compiled binary, a template engine readable start to finish in minutes. No VDOM, no hydration, no JS framework runtime shipped to render three pages.
3 direct dependencies, 70 crates total (page 2) — not 78, 120, or 577. Not a vanity
number: npm's supply chain has a long, escalating track record —
event-stream (2018), ua-parser-js (2021),
node-ipc/colors/faker (2022), and the
chalk/debug phishing compromise (Sept 2025, 18 packages,
2.6B weekly downloads combined). Fewer dependencies is a smaller blast radius —
not zero; crates.io has had incidents too, just fewer and smaller so far.
Node's own runtime (V8, libuv) is C/C++ under the hood and has had real
memory-safety CVEs over the years — buffer overflows, out-of-bounds reads, a 2025
file-API memory leak. Rust's compiler enforces memory safety at build time; site-server
has zero unsafe blocks, so that class of bug can't happen here by
construction. Memory-safety issues have accounted for roughly half to 70% of serious
CVEs at Microsoft and Google historically (their own published figures) — this is the
one place I'd say the language is doing real work for me, not just a feeling.