thorstenb

Most devs here use FF as their daily driver - that said, if you need to debug an emscripten-compiled c++ WASM application in the browser, then it's either printf-debugging, or Chrome + the C/C++ DevTools extension. Additionally, the overall QoI for running WASM binaries appears quite a bit better for Chrome. Both issues tip the scales currently, in favour of Chrome (sadly).

> It’s going to be extremely hard to get even decent results without targeting real DOM instead of going pure-canvas, and you can’t get excellent results without doing so.

One of the ZetaOffice (and LibreOffice) hackers here - and I have to disagree.

For something like an office suite, the canvas is literally the only way to achieve the document layout fidelity that users expect. The DOM does not provide enough knobs & dials to get all of MSO (and OOo) bug-for-bug layout compatibility onto the screen (and it's not even close). Don't take my word for it, see e.g. here: https://news.ycombinator.com/item?id=42100660 (and that only deals with the text layout parts).

ZetaOffice is focusing on developers wanting to integrate it (be that a web app, or a desktop line-of-business application, e.g. via Eclipse RCP) - having the exact same code built across all platforms should make for excellent consistency (document rendering, and API compatibility). We can also offer LTS support & security updates, beyond the normal LibreOffice 1-year lifetime.

Firefox is indeed a bit of a hit-and-miss these days (though we absolutely want to support it). Best experience currently is on Chrome(ium).

Indeed can be done, proof of concept shown in this talk: https://www.youtube.com/watch?v=X8LwaDjcr7M

Regarding sandboxing - everything WebAssembly is heavily sandboxed already, and requires cross-origin isolation in the browser, so we can use SharedArrayBuffers.

So that's likely no worse than running LibreOffice containerized on a server.

That still seems to be there, even for gtk4: https://docs.gtk.org/gtk4/broadway.html

(but it says, between the lines, mostly stale I guess)

As an aside: one of the very first demos of LibreOffice in a browser (from the Collabora people) was using the broadway backend. But they've moved on, using their own tiled rendering server backend, plus custom, javascript gui on the client.

Yup, and it's all fully upstreamed in LibreOffice, see our blog (https://blog.allotropia.de/category/libreoffice/), and the upstream wiki page: https://wiki.documentfoundation.org/Development/WASM

For an even more obvious demo of that, c.f. the hidden gem https://zetaoffice.net/demos/simple-examples/rainbow_writer.... ;)

Current source version powering the demos is https://git.libreoffice.org/core/+/0d9eb8245e1a1345ed9526ad8... - we should make that more prominent, indeed.

If you could file an issue please, at https://github.com/allotropia/zetajs/issues (with os version & hardware, if relevant)?

ZetaJS is a browser-based version (using LibreOffice WebAssembly) - that should work (tm) on all reasonably modern browsers, including iOS. But see compat matrix for details: https://webassembly.org/features/

We already use cairo/freetype/skia to do essentially all the document rendering in software (not for the Qt prototype though), so that's not a big leap to get that blitted out.

Incrementally then using more of html canvas to speed things up might be next.

Most of the work is going to be having the GUI (toolbar/notebook bar, menues, sidebar, dialogs) browser-native of course.

Qt clearly deserves the credit for having a WASM runtime that gets us a working GUI toolkit. But this was still a gigaton of work to pull off inside LibreOffice (starting many years ago, actually natively using Qt as one of the GUI toolkits in the code, over to porting the build system, how the mainloop runs etc etc).

Also note that using Qt here is mostly a shortcut to get a demo out, longer-term we'd want to use native browser gui.

Yep

With LibreOffice, the nice thing is you can chose. if you want all of the above - install the native version.

Longer-term, we need to move to browser-native GUI, yep. The nice bits though - the entire document loading, rendering & editing works in the browser now.

Caching is a prob, due to the current size - what works here is:

* FF: set browser.cache.disk.capacity to something >300MB, then set browser.cache.disk.max_entry_size to at least 150MB

* Chrom{e|ium}: start browser from cmdline, via `chromium --disk-cache-dir=/var/tmp/foo --disk-cache-size=2147483647`

(I'd not recommend this for production setups, obvsly .. ;))