Browsers never learned gRPC, so most Arrow Flight deployments flatten columnar data into JSON before a chart can touch it. sparrowJS closes that gap — the missing browser client for Apache Arrow Flight: Flight over gRPC-web, with Apache Arrow's JavaScript library decoding streaming record batches directly into typed arrays. No JSON, no REST gateway, no copies.

sparrowJS exists because every path from a Flight server to a browser used to end the same way: an expensive REST gateway turning Arrow back into JSON.

JavaScript Flight clients already exist — for Node.js, riding native gRPC that browsers cannot speak. Browser dashboards still rely on REST+JSON gateways. sparrowJS is a browser implementation of Flight over gRPC-web, validated against four independent Flight servers.

This isn't a mock-up. The demo on this site is sparrowJS running in your browser, querying a 136-million-row production server. Forty years of WTI stream directly from Arrow Flight and render in the browser in about half a second. The timings are on screen.

We even built the control group: the same lake behind a typical REST+JSON backend (DuckDB → array-of-objects → gzip, same snapshot, same nginx), raceable button-against-button on the demo. The result isn't a landslide. It's a crossover — and that's exactly what we'd expect.

Why it flips: for a small query, latency dominates — REST pays one HTTP round trip; Flight SQL pays two (GetFlightInfo, then DoGet) — and gzip'd JSON is compact while JSON.parse of 10k rows costs almost nothing. The second row shows the counter: pull() sends a client-constructed ticket straight to DoGet — on servers that accept them (this one does), Flight pays one round trip too, and the "REST wins small pulls" rule dissolves. The third row makes it the default: the server advertises its ticket contract in-band (a GetSqlInfo vendor code), and since v0.4.0 query() routes any statement through it automatically — the 2-RTT row survives only as the portable baseline. As the data grows, the economics reverse: the backend must manufacture JSON — serialize, compress, and the browser re-materializes it as objects — a tax that scales with every row, while Arrow record batches stream through untranslated into typed arrays. The crossover sits around one chart's worth of data; everything a real desk pulls is past it.

But 1.4× on one polite query was never the argument. Here's where the difference actually compounds:

So the honest pitch, straight from our own benchmark: for one small chart, JSON is fine — we show you so ourselves. It's everything after the first chart where Arrow compounds: server cost, scale, types, streaming, and never building a backend again.

Published on npm, running in production on this site. Everything above ships today: connect() with fail-fast auth and automatic Bearer adoption, a QueryStream you can async-iterate or await, pull() — the Direct Pull, one round trip for a known series, same verb as the CLI's sparrow pull — wire stats on every result, a typed query builder, capabilities() / tables() metadata, and an int64 policy that never silently loses precision. 53 tests run against three public Flight SQL dialects on every push — and the live demo streams the 136-million-row production instance through this exact code.

It also decodes what Arrow JS can't yet. Modern DataFusion servers ship strings as Utf8View, a type no released Arrow JS can read — sparrowJS transcodes View types to classic Arrow at the IPC layer, client-side, so those servers work in the browser as-is. Details in the Flight reference. The code is public — Apache-2.0, on GitHub — and on npm: npm install @sparrowflight/js (44 kB gzipped, ESM, TypeScript types; apache-arrow as peer).