Point0 benchmarks

Reproducible, parity-gated benchmarks: Point0 vs Next.js vs TanStack Start vs React Router — the same app built four times, each in its framework's native idiom: a small blog (post list, post page, create-post mutation, about) plus a SaaS-style dashboard, all rendering the same content from the same deterministic in-memory store. A 22-assertion-per-app Playwright parity gate must be green before any number counts.

There is no single "×N faster" headline here. The suite measures two things: DX velocity (dev start, HMR, build, type-check at scale) and runtime tax over the bare platform (every load number sits next to a bare Bun.serve / node:http floor). Each framework runs on its own supported runtime — Point0 on Bun, Next, TanStack and React Router on Node — and every row is labeled, so runtime and framework stay separable.

New to Point0? It's a fullstack TypeScript framework on Bun — the whole app, pages to endpoints, from one typed building block. Start at the Point0 repo or the docs; scaffold an app with bun create point0-app.

Reproduce: bun run setup, bun run parity, bun run bench:all, bun run render. The numbers below come from that flow on the machine in the Manifest; raw per-run JSON is committed in results/. How the repo works and how to extend it: dev/README.md.

Summary

	Point0	Next.js	TanStack Start	React Router
Runtime (as shipped)	Bun	Node	Node	Node
Prod build, S ↓	4.11 s	5.10 s _+24%	4.49 s _+9%	1.64 s _-60%
Prod build, L (+500 pages) ↓	7.49 s	10.87 s _+45%	18.20 s _+143%	4.47 s _-40%
HMR, edit → DOM ↓	20 ms	54 ms _+170%	175 ms _8.8×	157 ms _7.8×
Dev start, cold / warm ↓	2,467 / 972 ms	1,988 / 1,924 ms	2,048 / 2,015 ms	1,273 / 1,263 ms
Editor re-check, L ↓	1.06s	0.82s _-23%	1.07s _+1%	0.96s _-9%
Cold type-check (CI), L · TS7 ↓	6.85s	0.23s _-97%	0.58s _-92%	1.12s _-84%
First-load JS, /post (gzip) ↓	150.0 kB	135.9 kB _-9%	104.1 kB _-31%	103.0 kB _-31%
Nav data payload, dashboard → dashboard (gzip) ↓ **	470 B	1,335 B _+184%	274 B _-42%	254 B _-46%
Time-to-shell, /slow (stream) ↓	7 ms	10 ms _+43%	5 ms _-29%	5 ms _-29%
SSR /post, req/s c64 ↑ *	1,548	882 _-43%	3,284 _+112%	1,156 _-25%
Prod cold start ↓	448 ms	721 ms _+61%	100 ms _-78%	612 ms _+37%

↓ lower is better · ↑ higher is better. Each competitor cell carries a small delta vs Point0 (<sub> superscript): (value − Point0) ÷ Point0, mechanical sign — the ↓/↑ arrow already says which direction wins; a value ≥ 3× Point0 shows as a multiplier. * Point0's SSR row is its warmed build (.onPrefetchPage, 0 re-renders) — the peer of Next/TanStack's eager loaders; the default lazy build does 1,200 req/s (see the appendix). ** The nav row is the data payload for one navigation, captured by replaying the framework's own request with a uniform identity fetch and gzipping it here (see Wire size) — not bytes-at-click. Frameworks that prefetch visible links (Next prefetches every <Link> in the viewport) move those bytes before the click, so bytes-at-click credits them for work already done; the client section reports that figure separately. Full method and raw JSON below.

Overall. Point0's advantage is concentrated in the edit loop: HMR lands in 20 ms — 2.7× ahead of Next and roughly 8× ahead of TanStack and React Router — and it is the only one of the four with a warm dev start under a second (972 ms). Its costs are equally specific: the heaviest cold whole-project type-check by a wide margin (6.85 s at 500 pages on native TS7, against Next's 0.23 s), the heaviest first-load JS (150 kB), the slowest cold dev start, and ~230 MB of idle RSS above its own bare-Bun floor. On raw SSR with in-memory data TanStack is far ahead of everyone; Point0 sits second. Much of the rest of the table does not separate the four at all — per-edit type re-checks stay within a third of a second of each other, post→post and dashboard→dashboard clicks all land in 27–33 ms, and once a request touches a database the SSR spread disappears entirely. Every number here is reproducible, and the ones that go against Point0 are in the same tables as the ones that don't.

Method (the short version)

Same app, four idioms, gated by a Playwright parity test — all four apps must render the same content before any measurement counts.
No DB — a deterministic in-memory store, so we benchmark frameworks, not Prisma. Where a DB would matter, we simulate its latency and show the effect.
No single runs — medians with spread; warmup discarded.
Each framework on its default runtime, labeled per row. Runtime numbers ship next to bare-platform baselines.
Runtime is the officially supported one — Point0 on Bun; Next.js, TanStack Start and React Router on Node. We did check the competitors under Bun: TanStack Start gains ~10% req/s and Next.js ~7% (both unsupported configurations), while React Router fails to boot under Bun at all (react-dom's server.bun entry has no renderToPipeableStream). No ranking would change, so each ships on the runtime it supports.
Deltas are relative to Point0 — every competitor cell shows (value − Point0) ÷ Point0 (mechanical sign; the ↓/↑ arrow says which direction is better), switching to a multiplier once the value reaches 3× Point0. Point0 is the subject of this repo, so it is the reference; its own cells stay clean.
Pinned toolchain and framework versions (see Manifest).

1. DX

Production build (cold, caches wiped each run) ↓

App size	Point0	Next.js	TanStack Start	React Router
S — base	4.11 s	5.10 s _+24%	4.49 s _+9%	1.64 s _-60%
L — +500 pages	7.49 s	10.87 s _+45%	18.20 s _+143%	4.47 s _-40%

HMR latency ↓ (file write → DOM updated, median / p95)

	Point0	Next.js	TanStack Start	React Router
client edit → DOM	20 / 44 ms	54 / 63 ms _+170%	175 / 187 ms _8.8×	157 / 169 ms _7.8×

Dev start ↓ (spawn → first 200 with content)

	Point0	Next.js	TanStack Start	React Router
dev cold start (first run ever: caches wiped)	2,467 ms	1,988 ms _-19%	2,048 ms _-17%	1,273 ms _-48%
dev warm start (every start after)	972 ms	1,924 ms _+98%	2,015 ms _+107%	1,263 ms _+30%

Point0 runs its default point0 dev --hot.

Takeaway. Two rows separate the frameworks here, and both are ones you hit constantly. HMR: 20 ms edit-to-DOM for Point0 against Next's 54 ms and TanStack's and React Router's ~160 ms — a gap you feel directly, since this is the loop that runs on every keystroke-to-save. Warm dev start: 972 ms, the only sub-second start of the four (React Router 1.26 s, Next 1.92 s, TanStack 2.02 s). The build rows go the other way: React Router's lean Vite pipeline is the fastest at both sizes (1.64 s / 4.47 s), with Point0 second at scale (7.49 s for 500 pages, ahead of Next's 10.87 s and TanStack's 18.20 s). Cold dev start is Point0's slowest row at 2.47 s — that is the first run of a project ever, when the compiler's first pass fills a persistent disk cache; every start after it is the warm row.

2. Type-scale

Two different questions live here, and conflating them is the usual mistake:

Cold whole-project tsc (CI / tsc --build) — grows with the app. That's the Instantiations and wall-clock tables.
Editor responsiveness — what a language server does per keystroke: re-check the one file you edited against cached types. That's the "editor re-check" table.

The first is a build-time cost you pay in CI. The second is the lag you feel while typing.

Editor re-check ↓ (incremental `tsc` after a one-page edit — the per-keystroke proxy)

App size	Point0	Next.js	TanStack Start	React Router
S	0.94s	0.61s _-35%	0.91s _-3%	0.61s _-35%
M	1.02s	0.69s _-32%	0.92s _-10%	0.70s _-31%
L	1.06s	0.82s _-23%	1.07s _+1%	0.96s _-9%

Instantiations ↓ (deterministic — cold whole-project `tsc`)

Instantiations from tsc --noEmit --extendedDiagnostics (TS6) — deterministic and hardware-independent, the same on any machine. Point0 measured after point0 generate, TanStack after route-tree generation — codegen types included. Next measured on its app source (its route types need a full build, so they're excluded — which if anything undercounts Next).

App size	Point0	Next.js	TanStack Start	React Router
S — base (4 pages)	78,623	5,691 _-93%	51,829 _-34%	10,386 _-87%
M — +100 pages	509,677	13,691 _-97%	258,818 _-49%	237,409 _-53%
L — +500 pages	2,233,677	45,691 _-98%	1,086,018 _-51%	4,345,409 _+95%
growth S→L (4 → 504 pages)	28.4×	8.0×	21.0×	418.4×

Cold whole-project check ↓ (wall-clock; TS6 = JS tsc, TS7 = native)

Pages	Point0 TS6	Point0 TS7	Next TS6	Next TS7	TanStack TS6	TanStack TS7	React Router TS6	React Router TS7
S	0.83s	0.26s	0.29s _-65%	0.14s _-46%	0.51s _-39%	0.18s _-28%	0.32s _-61%	0.13s _-51%
M	3.03s	0.96s	0.63s _-79%	0.15s _-84%	1.42s _-53%	0.26s _-73%	0.88s _-71%	0.19s _-81%
L	17.45s	6.85s	1.77s _-90%	0.23s _-97%	5.37s _-69%	0.58s _-92%	3.92s _-78%	1.12s _-84%

Takeaway. These are two different questions and only one of them separates the field. The cold whole-project check is Point0's clear cost: inferring everything end-to-end with zero annotations runs to 2.23M type instantiations at 500 pages — 6.85 s on native TS7, 17.45 s on the JS tsc — against Next's 0.23 s and TanStack's 0.58 s. That is a CI bill, and it is a real one. The per-edit re-check — the lag you actually feel while typing — does not separate anyone: every framework re-checks a one-page edit in 0.61–1.07 s at every size, and all four stay flat from 4 pages to 504. Point0 moves from 0.94 s to 1.06 s across that range, and at any given size the four are never more than a third of a second apart — which is another way of saying this metric does not tell you anything about which framework to pick. The one structural outlier is React Router's cold check: its typed routes grow combinatorially — 10k instantiations at 4 pages to 4.35M at 504, the largest count of the four — though the native TS7 checker still clears it in 1.12 s.

3. Client

First-load JS is gzip-normalized uniformly (each JS chunk gzipped the same way regardless of how the server serves it), so it's comparable across frameworks. The bytes/click columns below are different: they are the raw bytes observed on the wire during a click, as each framework actually serves them — useful for what a click costs in flight, but not a like-for-like payload comparison. The normalized per-navigation payload lives in Wire size.

First-load JS ↓ (gzip, transferred to render the page)

	Point0	Next.js	TanStack Start	React Router
/ (home)	149.9 kB	135.9 kB _-9%	104.1 kB _-31%	102.9 kB _-31%
/post/50	150.0 kB	135.9 kB _-9%	104.1 kB _-31%	103.0 kB _-31%

Navigation: home → post ↓ (median / p95, and bytes per click)

Setup	click → content	bytes/click
Point0 · pageDehydratedStateAndClientQuery	74 / 84 ms	1,457
Point0 · serverAndClientQuery	57 / 84 ms	1,456
Point0 · no prefetch	77 / 86 ms	1,456
Next.js · default	76 / 77 ms _+3%	1,139 _-22%
TanStack · default	60 / 84 ms _-19%	1,018 _-30%
React Router · default	75 / 84 ms _+1%	1,099 _-25%

Navigation: post → post (steady state) ↓

Setup	click → content	bytes/click
Point0 · pageDehydratedStateAndClientQuery	31 / 51 ms	845
Point0 · serverAndClientQuery	33 / 43 ms	844
Point0 · no prefetch	29 / 50 ms	844
Next.js · default	29 / 37 ms _-6%	478 _-43%
TanStack · default	32 / 45 ms _+3%	632 _-25%
React Router · default	27 / 45 ms _-13%	924 _+9%

Navigation: dashboard → dashboard (SaaS case — rich markup, tiny data) ↓

A markup-heavy, data-light page. A data-loader SPA ships only the metrics; an RSC framework re-sends the rendered markup as its flight payload.

Read bytes/click carefully — it is not the payload size. It counts what crosses the wire during the click, so a framework that prefetches visible links has already paid for most of it (Next prefetches every <Link> in the viewport, which is why its figure here is small while its actual dashboard payload is the largest of the four), and a framework that fires an extra request on click is charged for it (React Router's /__manifest). For the controlled per-navigation payload — each framework's own request, replayed with a uniform identity fetch and gzipped identically — see Wire size.

Setup	click → content	bytes/click
Point0	33 / 58 ms	474
Next.js	30 / 38 ms _-9%	245 _-48%
TanStack Start	30 / 34 ms _-9%	275 _-42%
React Router	30 / 34 ms _-9%	552 _+16%

Takeaway. Felt latency does not differentiate: a post→post click resolves in 27–32 ms and a dashboard→dashboard click in 30–33 ms on all four, on a local server. Bytes are where they differ, and the ledger cuts both ways. First-load JS is Point0's heaviest row — 150 kB gzipped against Next's 136 kB and TanStack's and React Router's ~103 kB. Per navigation, Point0 ships query data and never HTML, but so do TanStack and React Router, and on the dashboard case the three land close together (see the wire-size table: 254–470 B gzipped). Next is the outlier there at 1,335 B, because its RSC flight payload re-sends the rendered markup — with the caveat that Next prefetches every visible link, so those bytes move before the click rather than during it, which is why its measured bytes-per-click is small. Point0's one clearly differentiated client row is prefetch tuning: serverAndClientQuery cuts a home→post click from 74 ms to 57 ms.

4. Streaming & progressive delivery

A page with one slow data block (a 1.5 s query) either ships its shell immediately and streams the block into the same response when it settles, or holds the whole document until the block is ready. This section measures that split per request (bench:progressive, BENCH_SLOW_MS=1500), then weighs the data payload a client-side navigation actually pulls (bench:wire).

Progressive delivery ↓ (/slow, one 1.5 s block — time-to-shell / time-to-fill, median / p95)

Setup	TTFB ↓	time-to-shell ↓	time-to-fill ↓
Point0 · defer/suspend (stream)	7 ms	7 / 9 ms	1,511 / 1,515 ms
Point0 · blocking	1,515 ms	1,515 / 1,520 ms	1,515 / 1,520 ms
Next.js (Suspense/RSC)	10 ms _+43%	10 / 17 ms _+43%	1,510 / 1,514 ms
TanStack Start (Await)	5 ms _-29%	5 / 10 ms _-29%	1,508 / 1,511 ms
React Router (Await)	5 ms _-29%	5 / 9 ms _-29%	1,507 / 1,511 ms

Point0 runs twice: stream (suspend:'server' — the block streams after the shell) and blocking (suspend:'auto' — the discover loop waits and the whole HTML ships at once, so shell == fill). The two Point0 rows stay bare; each competitor cell carries a delta vs the Point0 stream row.

Takeaway. Opt into streaming and all four deliver the shell in single-digit milliseconds — 5 to 10 ms to first paintable markup — while the slow block fills at the data's own pace (~1.5 s, the injected delay) inside the same response. Those shell deltas are noise on a local server, not a ranking. The row that earns its place is Point0 blocking: with suspend:'auto' the render-to-discover loop waits for the query and the whole document ships at once, so nothing appears until ~1,515 ms — the full cost of the slow block, paid by the entire page. That is what opting in buys back, and what you forgo if you don't.

Wire size of the navigation payload ↓ (deterministic — raw / gzip bytes)

The data a client-side navigation fetches instead of a fresh HTML document: Point0's dehydrated-state / query fetch, Next's RSC flight, TanStack's server-fn call, React Router's single-fetch .data. Content is deterministic, so raw and gzip are identical on any machine. Delta is on the gzip column.

Framework	/slow raw	/slow gzip	/dashboard/1 raw	/dashboard/1 gzip
Point0	6,390 B	2,200 B	865 B	470 B
Next.js	2,539 B	889 B _-60%	5,779 B	1,335 B _+184%
TanStack Start	6,797 B	2,039 B _-7%	667 B	274 B _-42%
React Router	5,870 B	2,133 B _-3%	351 B	254 B _-46%

Takeaway. Two payload shapes, two outcomes. On /slow — data-heavy — the three data-loaders serialize the same content into 2.0–2.2 kB gzipped (Point0 2.2, React Router 2.1, TanStack 2.0), while Next's RSC flight is the compact one at 0.9 kB. The dashboard — markup-heavy, data-light — reverses it: React Router 254 B, TanStack 274 B, Point0 470 B, all of them a few hundred bytes and none meaningfully apart at that scale; Next re-sends the rendered markup as its flight payload at 1,335 B, roughly 3× the data-loaders. The rule behind both rows: a data-loader's per-navigation weight tracks the data, an RSC payload's tracks the markup — so which one is lighter depends entirely on which of the two your page is mostly made of.

5. Runtime (production builds)

Load via oha. Every app row is meant to be read against its own platform baseline (Bun rows vs the bare-Bun floor, Node rows vs the bare-node floor) — that delta is the framework tax, separated from the runtime difference.

SSR `/post/50` with data

Server	Runtime	req/s (c64) ↑	p50 c1 (ms) ↓	p99 c64 (ms) ↓	wire bytes/resp
bare Bun.serve, static string	Bun	63,754	0.04	2.0	1,197
bare Bun + React renderToString	Bun	24,392	0.07	5.1	1,197
Point0 (warmed, 0 re-render) — fair peer	Bun	1,548	0.90	48.3	6,474
Point0 (default, lazy discover loop)	Bun	1,200	1.12	63.0	6,474
bare node:http, static string	Node	47,323	0.05	2.7	1,197
bare node:http + React renderToString	Node	10,847	0.12	15.8	1,197
TanStack Start	Node	3,284	0.38	37.7	3,798
Next.js (force-dynamic)	Node	882	1.81	98.2	2,839
React Router	Node	1,156	1.13	67.4	2,082

"wire bytes/resp" is the response body as each server ships it: Next compresses on the fly, Point0 and TanStack serve identity — so those cells are transfer sizes, not document sizes. Documents are compared apples-to-apples below.

Takeaway. Read each app row against its own floor — that gap is framework tax, with Bun-vs-Node separated out. On /post with in-memory data, TanStack is far ahead at 3,284 req/s; warmed Point0 follows at 1,548, then default Point0 at 1,200, React Router at 1,156 and Next at 882. TanStack's lead here is real and large. The two Point0 rows price one specific convenience: the default build never asks you to declare what a page loads — it renders to discover — which none of the other three offer. That costs ~22% (1,200 vs 1,548 req/s), and one opt-in hook removes it. The /home row inverts for a reason worth naming: Point0 is slowest at 564 req/s, and it is also serving the largest document of the four there (33.2 kB against Next's RSC-compacted 20.8 kB). And the caveat that governs this whole section: with a trivial in-memory loader this measures framework overhead in a vacuum — the DB-latency table shows what survives contact with a real query.

SSR document size ↓ (uncompressed / gzip-normalized, bytes)

Delta is on the uncompressed (first) number; the gzip gaps are smaller.

	/post/50	/ (home)
Point0	6,474 / 2,190	33,154 / 8,353
Next.js	8,891 / 2,436 _+37%	20,827 / 3,800 _-37%
TanStack Start	3,798 / 1,681 _-41%	29,986 / 8,064 _-10%
React Router	6,165 / 1,970 _-5%	32,712 / 8,672 _-1%

Reading the document sizes. Point0's SSR document carries the page's data twice — once as rendered markup, once as the dehydrated React Query cache in <head> that makes every piece of it a live, cacheable query on the client. On this text-heavy post that is 6.5 kB raw against TanStack's 3.8 kB. Gzip closes most of the gap — 2.19 kB vs 1.68 kB — because repeated text is exactly what compression eats, and Next's document is the largest of the four at 8.9 kB raw / 2.44 kB gzipped, since RSC inlines its flight payload in a less compressible format. The duplication touches only the first document; every navigation after it ships data, never HTML. A no-duplication HTML mode for content-heavy pages is planned and does not exist yet.

Cold start, memory, home list

	Point0	Next.js	TanStack Start	React Router
prod cold start ↓	448 ms	721 ms _+61%	100 ms _-78%	612 ms _+37%
RSS idle (MB) ↓	348	363 _+4%	173 _-50%	251 _-28%
RSS after load (MB) ↓	417	420 _+1%	218 _-48%	340 _-18%
home list req/s c64 ↑	564	741 _+31%	1,714 _3.0×	810 _+44%

Bare-floor RSS, same warm pattern, zero framework code:

	bare Bun + React	bare node:http + React
RSS idle (MB)	118	135
RSS after load (MB)	119	148

Takeaway. Cold start reads straight off the table: TanStack 100 ms, Point0 448 ms, React Router 612 ms, Next 721 ms. Point0's 448 ms buys a deliberate property — it imports the whole app at boot, so a broken page fails the process at deploy time rather than on a user's first request. Memory is the row that cannot be read without its floor: a bare Bun.serve + renderToString server idles at 118 MB and a bare node:http equivalent at 135 MB. Against those, Point0 idles at 348 MB — about 230 MB of framework tax — while TanStack sits ~38 MB above its Node floor and React Router ~116 MB. Point0 is the second-heaviest of the four at idle and holds 417 MB under load. That is a genuine cost, and unlike the SSR rows it does not wash out behind a database.

The DB-latency reality check ↓ (c=1 total latency with a simulated DB delay)

The SSR rows above have a trivial loader, so the framework's CPU overhead is the whole latency. Add a realistic per-request DB delay and watch the frameworks converge — the gap you see with no DB is a microbenchmark artifact. Each cell is total p50 latency; in parentheses, the framework's share of it.

DB delay	Point0	Next.js	TanStack Start	React Router
0 ms	0.90 ms (100%)	2.00 ms (100%) _+122%	0.39 ms (100%) _-57%	1.23 ms (100%) _+37%
5 ms	8.22 ms (39%)	8.26 ms (39%)	8.19 ms (39%)	8.70 ms (43%) _+6%
20 ms	25.14 ms (20%)	25.82 ms (23%) _+3%	25.16 ms (21%)	26.01 ms (23%) _+3%

Takeaway. This is the table that puts the SSR section in proportion. With no DB the loader is trivial, framework CPU is the entire latency, and the spread is wide — 0.39 to 2.00 ms. Add 5 ms of query delay and the four land at 8.19, 8.22, 8.26 and 8.70 ms; add 20 ms and they land at 25.14, 25.16, 25.82 and 26.01 ms. At that point the differences are well inside run-to-run noise — not a small gap, but no gap you could act on. Any app that touches a database is in the second regime, not the first, so the raw-SSR ranking above describes frameworks in a vacuum and stops describing your app the moment a real query enters the loop. That is the reasoning behind where Point0 spends its budget: HMR, dev start and navigation payloads are costs a faster database cannot refund.

6. Appendix — Point0 SSR: convenience vs warmed

Point0's default SSR renders to discover: it renders, sees which queries the page needs, fetches them, re-renders. You declare nothing — no loader wiring, no data-dependency list. Next and TanStack don't offer that; they require you to declare what each route loads. The cost is the extra passes. Warming the page's queries once (.onPrefetchPage(() => q.fetchQuery(...))) collapses the loop to a single render — exactly what the other two force you to do eagerly — so the warmed row is the fair peer in the runtime table above. Against real database latency the discover overhead is a few percent; here, with in-memory data, it's the whole delta — this table is its worst case.

Mode	p50 c1 ↓	req/s c64 ↑
default (lazy discover loop)	1.12 ms	1,200
warmed (.onPrefetchPage → 0 re-renders)	0.90 ms	1,548

Takeaway. The discover loop costs ~22% here (1,200 vs 1,548 req/s) — and this table is its worst case by construction, since an in-memory store makes the extra render passes the entire difference. Put a real query behind the loader and that share shrinks in proportion to the query, exactly as the DB-latency table shows. The trade is explicit: you write no loader wiring and no data-dependency list, and if you want the throughput back, .onPrefetchPage(() => q.fetchQuery(...)) is the one line that does eagerly what the other frameworks require you to do by hand.

Manifest

{
  "date": "2026-08-21",
  "machine": {
    "model": "Apple M1 Pro",
    "cores": 8,
    "arch": "arm64",
    "ramGB": 32,
    "os": "darwin 24.4.0"
  },
  "toolchain": {
    "bun": "1.4.0",
    "node": "22.21.1",
    "typescript6": "6.0.3",
    "typescript7": "7.0.2",
    "oha": "oha 1.14.0",
    "hyperfine": "hyperfine 1.20.0"
  },
  "frameworks": {
    "point0": "0.3.13",
    "next": "16.3.2",
    "tanstackStart": "1.168.27",
    "tanstackRouter": "1.170.17",
    "reactRouter": "8.3.0"
  },
  "react": {
    "point0": "19.2.8",
    "nextjs": "19.2.8",
    "tanstack": "19.2.8",
    "react-router": "19.2.8"
  },
  "load": {
    "tool": "oha",
    "pattern": "12s/cell, warmup discarded",
    "concurrency": [
      1,
      64
    ]
  },
  "commit": "cae9f2b"
}

Generated by bun run render from results/. Every table is data; the italic Takeaways are hand-written interpretation.

About Point0

Point0 is a fullstack TypeScript framework on Bun. Everything that affects a page lives in the page's builder methods — path, loader, markup, head — and the loader is plain react-query under the hood, so pages and components become cacheable queries. Types aren't generated; it all rides on the builder's generics.

Repo: github.com/1gr14/point0
Docs: 1gr14.dev/point0
Scaffold: bun create point0-app
For your AI agent: 1gr14.dev/llms.txt

Community

Questions, bugs, or want to hang with other builders? Join the 1gr14 community — one hub for all our open-source projects, this one included. Get help, share what you built, or just say hi: 1gr14.dev/#community

License

MIT

Made by 1gr14, driven by community

Name		Name	Last commit message	Last commit date
apps		apps
bench		bench
dev		dev
results		results
scripts		scripts
shared		shared
.gitignore		.gitignore
LICENSE		LICENSE
README.md		README.md
bun.lock		bun.lock
package.json		package.json
tsconfig.json		tsconfig.json

Navigation Menu

Uh oh!

Repository files navigation

Point0 benchmarks

Summary

Method (the short version)

1. DX

Production build (cold, caches wiped each run) ↓

HMR latency ↓ (file write → DOM updated, median / p95)

Dev start ↓ (spawn → first 200 with content)

2. Type-scale

Editor re-check ↓ (incremental `tsc` after a one-page edit — the per-keystroke proxy)

Instantiations ↓ (deterministic — cold whole-project `tsc`)

Cold whole-project check ↓ (wall-clock; TS6 = JS tsc, TS7 = native)

3. Client

First-load JS ↓ (gzip, transferred to render the page)

Navigation: home → post ↓ (median / p95, and bytes per click)

Navigation: post → post (steady state) ↓

Navigation: dashboard → dashboard (SaaS case — rich markup, tiny data) ↓

4. Streaming & progressive delivery

Progressive delivery ↓ (/slow, one 1.5 s block — time-to-shell / time-to-fill, median / p95)

Wire size of the navigation payload ↓ (deterministic — raw / gzip bytes)

5. Runtime (production builds)

SSR `/post/50` with data

SSR document size ↓ (uncompressed / gzip-normalized, bytes)

Cold start, memory, home list

The DB-latency reality check ↓ (c=1 total latency with a simulated DB delay)

6. Appendix — Point0 SSR: convenience vs warmed

Manifest

About Point0

Community

License

About

Releases

Packages

Contributors

Languages

Uh oh!

Latest commit

History

Folders and files

Repository files navigation

Point0 benchmarks

Summary

Method (the short version)

1. DX

Production build (cold, caches wiped each run) ↓

HMR latency ↓ (file write → DOM updated, median / p95)

Dev start ↓ (spawn → first 200 with content)

2. Type-scale

Editor re-check ↓ (incremental tsc after a one-page edit — the per-keystroke proxy)

Instantiations ↓ (deterministic — cold whole-project tsc)

Cold whole-project check ↓ (wall-clock; TS6 = JS tsc, TS7 = native)

3. Client

First-load JS ↓ (gzip, transferred to render the page)

Navigation: home → post ↓ (median / p95, and bytes per click)

Navigation: post → post (steady state) ↓

Navigation: dashboard → dashboard (SaaS case — rich markup, tiny data) ↓

4. Streaming & progressive delivery

Progressive delivery ↓ (/slow, one 1.5 s block — time-to-shell / time-to-fill, median / p95)

Wire size of the navigation payload ↓ (deterministic — raw / gzip bytes)

5. Runtime (production builds)

SSR /post/50 with data

SSR document size ↓ (uncompressed / gzip-normalized, bytes)

Cold start, memory, home list

The DB-latency reality check ↓ (c=1 total latency with a simulated DB delay)

6. Appendix — Point0 SSR: convenience vs warmed

Manifest

About Point0

Community

License

About

Resources

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages

Editor re-check ↓ (incremental `tsc` after a one-page edit — the per-keystroke proxy)

Instantiations ↓ (deterministic — cold whole-project `tsc`)

SSR `/post/50` with data