Google Sheets ported its calculation worker from JavaScript to WasmGC

Original Article ↗ Hacker News Discussion ↗

Google Sheets has migrated its calculation engine from JavaScript to WebAssembly with garbage collection (WasmGC), ultimately achieving about twice the calculation speed of its previous JS-based approach after substantial tooling and VM optimizations. Commenters probe how this works in practice—compiling a long‑standing Java codebase to both JS and WasmGC, trade‑offs versus native Excel, limits like browser memory caps, and reliance on optimized browser APIs—while also highlighting broader implications for GC‑language support in the browser and future WebAssembly‑based apps. There is parallel scrutiny of article transparency (missing publish dates, framing of performance claims) and of ongoing pain points in Sheets such as UI sluggishness and offline/browser restrictions.

Performance and results

  • Initial WasmGC port of the Sheets calculation engine ran about 2× slower than the existing JS-targeted version.
  • After substantial optimization (devirtualization, speculative inlining, better data structures, and using native browser APIs like RegExp), the WasmGC version is about 4× faster than that prototype and roughly 2× faster than the JS version.
  • Java-on-WasmGC is said to be ~2× slower than Java on the JVM, so there is still a gap to native JVM performance.

Java, JavaScript, and what’s actually being compared

  • The engine is written in Java and compiled either to JS (via J2CL/GWT) or to WasmGC (via J2Wasm).
  • Some argue the article blurs the distinction by talking about “JavaScript vs Java,” when it is really comparing compilation targets for the same Java code.
  • Others counter that the “JS version” is a real JS bundle delivered to the browser and historically replaced a handwritten JS implementation, so comparing “JS vs WasmGC” is fair from a web-performance perspective.

Why WasmGC matters

  • Without WasmGC, GC’d languages must ship their own collectors in Wasm, inflating binary size and complicating cross-module and host integration.
  • WasmGC lets languages reuse the browser’s GC, improves interop (e.g., sharing heap objects across modules/host), and avoids tricky “hybrid” GC schemes.
  • Limitations remain: GC arrays lack some low-level ops (e.g., efficient reinterpretation of bytes as ints), and sharing packed GC arrays efficiently with WebGL/WebGPU/Web Audio is still awkward.

Browser support and fallbacks

  • Chromium-based browsers and Firefox support WasmGC; Safari/WebKit work is ongoing but incomplete.
  • Sheets can still serve a JS-compiled version where WasmGC is unavailable.

Comparisons to Excel and scalability

  • Native Excel (C++) is expected to remain faster, with no 4 GB Wasm memory cap and real shared-memory threads.
  • Users report Sheets becoming slow or hanging with large, complex models, while Excel handles similar workloads better; others mainly notice UI sluggishness, not raw calculation speed.

Offline, native, and platform lock-in

  • Some want a true offline/standalone Sheets app; today’s offline mode requires Chrome/Edge and an extension.
  • This raises complaints about browser lock-in and potential antitrust concerns; others note limited incentive to support more browsers.

Meta: publication dates and credibility

  • Several comments criticize the article’s lack of a clear original publication date and describe a broader trend of hiding dates for SEO/engagement, which they see as harmful to trust and technical context.