ZetaOffice: LibreOffice in the Browser

Original Article ↗ Hacker News Discussion ↗

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.