ZetaOffice: LibreOffice in the Browser

Original Article ↗ Hacker News Discussion ↗

LibreOffice is being brought to the browser via ZetaOffice, a WebAssembly-based build paired with a JavaScript API (zeta.js) that renders the full office suite into an HTML canvas and can also be embedded or used for headless document conversion. Commenters are intrigued by the prospect of fully client-side, self-hostable office editing—especially as an alternative to server-heavy solutions like Collabora or OnlyOffice, and for integration into platforms like Nextcloud—but report serious performance, font-rendering, input, and accessibility issues in the current demos. Much of the debate centers on whether a pure-canvas architecture can ever match the usability and text handling of DOM-based UIs, even if it offers better layout fidelity and cross-browser consistency.

Implementation & Architecture

  • Runs LibreOffice compiled to WebAssembly, with a JavaScript library (Zeta.js) mediating between browser and LO.
  • Rendering is canvas-based via LibreOffice’s Qt/VCL backend; likely uses SharedArrayBuffer and cross‑origin isolation.
  • All core changes are reportedly upstreamed into LibreOffice; Zeta.js examples show loading and manipulating documents in a few JS calls.
  • There is also a native desktop build (Linux/Windows) using the same codebase for consistent rendering and a basis for long‑term support.

Open Source & Licensing

  • Initial concern that source wasn’t clearly linked on the landing page despite LibreOffice’s copyleft license.
  • Later clarified that the WASM work is upstream, with specific LibreOffice git revisions and Zeta.js GitHub repo referenced.
  • Self‑hosting is mentioned but appears to require contacting the vendor; some users see this as a friction point.

Use Cases & Integration

  • Suggested for sandboxed, headless document conversion, with a referenced proof‑of‑concept talk; WASM sandboxing considered robust.
  • Interest in using it as a Nextcloud app to avoid running a separate document server, especially on low‑end home hardware.
  • Read‑only/demo modes exist and are highlighted as potential lightweight document viewers.

Performance & UX Feedback

  • Experiences diverge sharply:
    • Some report “unusable” performance: laggy, poor text rendering/kerning, broken input (compose/CJK/emoji), bad selection, crashes on certain menus, heavy initial download (~50 MB+).
    • Others find it “fast enough” on modern hardware (iPad Pro, M1 Mac) but note blurry/low‑DPI rendering and a 90s‑style UI.
  • HiDPI support, font quality, and Firefox behavior are recurring issues; Chromium currently gives better WASM debugging and runtime quality.

Canvas vs DOM Debate

  • One camp: pure‑canvas UIs are fundamentally limited—worse text selection, composition, keyboard navigation, accessibility, mobile behavior, and interoperability; examples like Google Docs and Flutter Web are cited negatively.
  • Other camp: DOM layout is too constrained/inconsistent for high‑fidelity office document rendering; canvas gives full control and is the only practical way to match LibreOffice/MS Office layout bugs and features exactly.
  • Some suggest a hybrid: use DOM for input/accessibility and custom layout, but this is acknowledged as significantly more complex.

Comparisons with Other Office Solutions

  • Collabora Online:
    • Uses server‑side LibreOffice with tiled raster streaming and custom JS UI; powers Nextcloud Office.
    • Criticized by some as slow and clunky vs Google Docs; others say it’s “perfectly fine.”
    • Requires extra infrastructure (COOLWSD) and more server resources.
  • OnlyOffice and CryptPad mentioned as alternatives; OnlyOffice also pure‑canvas and has/had accessibility issues.
  • WebODF noted as a past pure‑web OpenDocument effort that stalled due to lack of funding.

Broader Web vs Native Discussion

  • Some enthusiasm for browser‑based office: no installation, easy sharing and collaboration, works on locked‑down or shared machines.
  • Strong counter‑view: browsers as “the new OS” is seen as performance‑wasting, privacy‑blurring, and driven more by developer convenience than user benefit; preference for native apps and clearer local/cloud boundaries.
  • Concerns that large WASM payloads and heavy web runtimes erode the “quick preview” advantage.

Miscellaneous

  • Home‑page animation and stock imagery are disliked by some.
  • One demo claims “works on any device” but disables mobile, which is noted as contradictory.
  • “Release early, release often” vs. risking a very poor first impression is explicitly debated.