I just tried the demo on my very capable laptop (ASUS Zephyrus G15 2021, Linux, Sway; Firefox, also tried Chromium).
Performance is execrable. Text rendering is awful. Input is simply broken (e.g. my Compose key just doesn’t work). Double clicking highlighted the entire canvas thing, as well as the word under the cursor. Right clicking did nothing. Scrolling isn’t captured. The first menu thing I happened to try in the full-UI https://zetaoffice.net/demos/simple-examples/rainbow_writer.... example (Format → Theme, maybe I just picked unfortunately) crashed the whole app (which means that it just stops working mysteriously, leaving the UI in the last state it was in).
And you can’t even get started until it’s downloaded 50MB. (Though I’m actually mildly impressed it’s only that size.)
Seriously, this is completely unusable. It’s “cool tech demo”, but I would hate to actually have to use it.
And I’m pretty sure, based on my rather accurate understanding of how all these things work (comprehensive on the web side, good on the native side, not so much specific about LibreOffice itself), that a lot of this is going to be completely unfixable—though a couple of the things I identified are fairly straightforward to fix, which is if anything a further indictment.
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.
> 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.
Flutter and Google Docs gave up on the DOM because they couldn't get it working well enough, consistently enough across browsers. When you draw to canvas you get more consistent results because you control all the drawing.
> Just so that a couple of snowflakes can use their fad of the day or can stay in their comfort zone.
Or because the DOM is a piece of technology designed for rendering documents and not web apps and with limitations which has been severely gimping proper rendering of web apps for the past decade despite a slew of libraries trying to fill the cracks with various amount of success. Whichever you prefer.
Google Docs isn’t pure-canvas: they only switched their document area to use it for layout. Text rendering is still browser (necessary to keep performance even close), and all the rest of the UI is still DOM. Having thought extensively about it, I cannot come up with any advantage to the approach they’ve taken—neither the performance¹ nor the consistency² angles make any sense, and the product is actively worse because of it³. I’ve written more about it on HN at times, skim https://hn.algolia.com/?query=chrismorgan%20google%20docs&ty... for more. Seriously, having thought about it very carefully and reviewed the matter several times over the years, I honestly believe that they lied in their justifications.
Flutter… ugh, Flutter on the web is awful awful awful awful awful AWFUL AWFUL and I will hate you if you decide with open eyes to use it when you’re deliberately targeting the web.⁴ I lack energy to express my vitriolic loathing. Just go through https://hn.algolia.com/?query=chrismorgan%20flutter&type=com..., there’s lots of detailed explanation of specifically what’s bad, if you need it.
Avalonia Visual Basic 6? It’s the kind of thing where the limitations will show least, because of how limited it is. And also because it’s imitating (not quite the right word, but close enough) ancient software which itself wouldn’t work fully properly if run on current machines. Its text handling is dodgy, doesn’t do composition properly, scrolling is non-native, context menus are non-native which stops some things from working properly… but honestly that’s kinda the vibe they’re going for, so it’s not particularly upsetting.
Pure-canvas is irredeemably bad. With difficulty you can make some things decent even with it, but excellence is impossible with pure canvas.
Flutter and Google Docs did not give up on DOM for the reasons you cite. Google Docs, I honestly don’t understand why they gave up on DOM, the reasons they cited publicly genuinely don’t make sense. Flutter, it was because they don’t actually care about the web, it’s a third-class target, and too much of the way they design their API doesn’t port to DOM directly, so that making DOM a first-class citizen would have required compromises in their APIs that they were unwilling to make. But it was emphatically not about cross-browser consistency.
—⁂—
¹ Seriously, Google Docs is slower than it used to be, especially with higher latency and jitter.
² The parts they replaced had no consistency problems in any realistic browsers. Seriously. Their layout requirements are, in practice, really basic. The area where consistency can actually be a problem is text shaping and rendering, but they haven’t replaced that since it would tank performance.
³ My favourite example is keyboard navigation. It doesn’t match platform conventions, and that’s really irritating. Since we’re in this thread, LibreOffice also flouts platform conventions in this area, and it’s really irritating.
⁴ If you’re focusing on mobile and make a mobile app with Flutter and also put it on the web with Flutter because why not, better than nothing, I won’t like you very much, but I’ll at least understand. But if you’re saying “we need a web thing, how about we use Flutter”… no.
Please look over my comments on HN about Flutter and pure-canvas and such. There are big problems. There is plenty special about the DOM that you lose and cannot gain back if you go pure-canvas. Links. Scrolling. Text handling. Composition. And various more.
Use DOM. Please use DOM.
Use canvas for an actual drawing canvas, but for the UI and anything else that’s largely text, use DOM.
There aren't "big problems" because it works. When you put yourself in the corner of claiming "pure-canvas is irredeemably bad" when it's plainly not, then there's nothing practical on offer.
“It works” is a terrible defence, because of the different degrees of working.
I’m describing various specific ways in which it doesn’t work properly, in ways that stop users from doing things they may legitimately want to do, or which will frustrate some users, and you’re just disregarding them. I’m not being vague in most of my complaints, I’m being very specific.
It’s like you have a screw, and it’s worn enough that sometimes it makes the screwdriver slip, but you’re saying “just be careful, maybe apply a little more pressure, and it still works”.
OnlyOffice has decent performance and is pure canvas. However, they have (or had) issues with respect to accessibility, as screen readers don't read canvas.
Barely worse than Teams or your typical web app. Needs polish for sure but the bar for web apps aren't exactly high.
Canvas usually breaks text selections etc. and accessibility. But what they do seem to perform much better than trying to get the DOM to do something it wasn't designed for.
When you delve into badly-performing web apps, DOM is almost never the actual performance bottleneck. It’s other things they’re doing. And in the rare cases where DOM is the bottleneck, it’s always that they were abusing it.
As for this case, I have never encountered a web app with performance (throughput and latency) problems like this. Not anywhere near it.
> ZetaOffice is also available as a native Desktop application for Linux and Windows. Download the Beta here.
Why is a desktop application being developed and provided if this is compatible with LibreOffice (since the latter already has desktop applications)? Is it just to have the same name and recognition?
Is the desktop application kept on par with the latest LibreOffice release or does it only guarantee document format compatibility up to a specific version?
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.
That's excellent! You guys should interact with Nextcloud or someone should try their hand at a Nextcloud App [1]. Nextcloud's solution to Google Docs & friends is via the integration of OnlyOffice[2], which requires a DocumentServer [3] to function in the context of Nextcloud. Even without the collaboration aspect, having LibreOffice work off WASM, without any extra infrastructure requirement would be an excellent edition to that ecosystem I think.
Nextcloud is a steaming pile of barely maintained donkey dung one should not approach with anything other than a 10' pole while wearing a full Hazmat suit.
Zeta.js is such an impressive JavaScript library. I'm blown away. The examples where you can load a document in less than ten lines, amazing. Then, change colors of all cells in less than ten lines, amazing.
I'm also blown away that there is a gulp file in the repository. That's a blast from the past.
I'm still working with stuff using grunt (most certainly not my choice). gulp is not that bad as a generic task runner, though the last thing I'd use it for these days is to build JS artifacts.
While it is an amazing technical feat, there are, expectedly, a bunch of quirks to be ironed out. The font rendering, for example, is very bad. Very excited to see how this goes in the future!
I've used LibreOffice/OpenOffice/StarOffice for two decades now. It's OK, not great. At least it interoperates with Microsoft desktop formats now. Mostly.
LO is contantly updated and improved. The 2 decades observation isn't really useful. Would you compare today's MSO experience to MSO2000 on Windows Millenium?
I use LO exclusively and it's a joy to use. On the rare instances I'm forced to use MSO it feels only marginally better than google docs. YMMV
And, strictly speaking, the reason things break sometimes when switching from LO to MSO is because MSO is broken: LO follows the spec (both .odt and .docx) faithfully, which then breaks when MSO relies on undocumented features or outright bugs for the end-result (i.e. the "works best on Internet Explorer" legacy).
I would love to have something like this in order to provide the office features for documents hosted in nextcloud directly. Yes, there is Nextcloud Office/Collabora Office but this needs separate provider and is not included in hosted Nextcloud (e.g. at Hetzner). The ease of OneDrive + MS365 in comparison is quite attracting. For my current use (sharing documents in a team of 50 - non-commercial but somehow professional approach) the latter is still the tool of choice. Being able to share a link, which allows others to directly edit presentations and spreadsheets in a browser (while the files are available in a local file structure) is just great.
I can remember testing libre office in the browser many years ago, seems like that project was frozen in 2020 as others external projects emerged. The wiki has a guide for docker:
the link you refer to talks about collabora and allotropia. the first is what powers Nextcloud Office/Collabora Office online and mobile apps (using coolwsd). the latter is allotropia, who is behind Zeta that is mentioned here. both have a slightly different approach to how this works. as i understand it, all of this is upstream and not really frozen; perhaps that page needs an update?
Note: "LibreOffice Online is not intended as a standalone software. His goal is, instead, to be integrated with other tools to edit their documents." ... while Zeta and Collabora are standalone.
Keep in mind that Zeta office runs completely in the browser with WASM while the thing you provided runs on a server and just streams back and forth to the client.
It sounds like you might know the answer to this. Would it be straightforward to use this for sandboxed headless file conversion? You can do that already with LibreOffice, but it's a monster amount of unsafe code that's difficult to containerize securely
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.
Oh whoa a 5 minute video for exactly this :) Apologies for making you be my Google. Yep, everything in wasm makes things much easier to work with, especially if you want to run it on a client device
I just containerized LibreOffice to do docx->pdf conversation, but now I'm wondering - what parts seem particularly gnarly to you? My naive strategy is to mount an external volume to put/collect files, then call `soffice` inside the container to process them. We generate all source docx files so I'm not worried about an injection from that angle.
Joke aside, the source code isn't featured on the web page, despite LibreOffice (unlike Apache OpenOffice) being copylefted. They mention self hosting, but it says to contact them. It seems it runs on WebAssembly either directly or through a VM on top of WebAssembly like https://copy.sh/v86/ . The screen seems to be simulated with a canvas. I think perhaps they didn't change the code of LibreOffice much, but have a custom setup of something like https://copy.sh/v86/ or even are running it on actual WebAssembly with a virtual screen. So they have a virtual computer that it's running on, and they consider that separate when it comes to copyleft obligations. Plus it's possible to make something open source but inconvenient, and charge to make it convenient.
That's nice. AFAICT nobody has yet figured out how to run the rust compiler in WebAssembly directly, but it runs in v86. That's why I wondered if they were taking that shortcut for another complex program.
It says it uses Qt/VCL. Maybe those can talk to canvas in a fairly straightforward way, or maybe ZetaOffice chose a different backend to get a proof of concept out faster.
(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.
I just tried the demo on my very capable laptop (ASUS Zephyrus G15 2021, Linux, Sway; Firefox, also tried Chromium).
Performance is execrable. Text rendering is awful. Input is simply broken (e.g. my Compose key just doesn’t work). Double clicking highlighted the entire canvas thing, as well as the word under the cursor. Right clicking did nothing. Scrolling isn’t captured. The first menu thing I happened to try in the full-UI https://zetaoffice.net/demos/simple-examples/rainbow_writer.... example (Format → Theme, maybe I just picked unfortunately) crashed the whole app (which means that it just stops working mysteriously, leaving the UI in the last state it was in).
And you can’t even get started until it’s downloaded 50MB. (Though I’m actually mildly impressed it’s only that size.)
Seriously, this is completely unusable. It’s “cool tech demo”, but I would hate to actually have to use it.
And I’m pretty sure, based on my rather accurate understanding of how all these things work (comprehensive on the web side, good on the native side, not so much specific about LibreOffice itself), that a lot of this is going to be completely unfixable—though a couple of the things I identified are fairly straightforward to fix, which is if anything a further indictment.
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.
> 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.
Sure you can. Google Docs switched to canvas three years ago: https://workspaceupdates.googleblog.com/2021/05/Google-Docs-...
This wasm application renders to canvas and works fine for me: https://bandysc.github.io/AvaloniaVisualBasic6/
This one too: https://flutterweb-wasm.web.app/
Flutter and Google Docs gave up on the DOM because they couldn't get it working well enough, consistently enough across browsers. When you draw to canvas you get more consistent results because you control all the drawing.
> Sure you can. Google Docs switched to canvas three years ago: https://workspaceupdates.g
You just need to be one of the critical projects for BigTech. Easy peasy, compared to <editor_command> index.html.
> This wasm application renders to canvas and works fine for me: https://bandysc.github.io/AvaloniaVisualBasic6/
Trying to select text on mobile Safari just selects whole canvas. Same for your Flutter example.
What a regression for web. Just so that a couple of snowflakes can use their fad of the day or can stay in their comfort zone.
> Just so that a couple of snowflakes can use their fad of the day or can stay in their comfort zone.
Or because the DOM is a piece of technology designed for rendering documents and not web apps and with limitations which has been severely gimping proper rendering of web apps for the past decade despite a slew of libraries trying to fill the cracks with various amount of success. Whichever you prefer.
Or because Google doesn't like open web technologies, standards and interoperability now that they are the king of the hill?
How are WebAssembly and canvas not open web technologies?
> Trying to select text on mobile Safari just selects whole canvas. Same for your Flutter example.
Ah, so yet again Safari is the problem. The new Internet Explorer unfortunately.
> Google Docs switched to canvas three years ago:
And broke CJK and emoji input. They only fixed emoji input recently. CJK is still broken.
> CJK
"The shorthand collective name for the Chinese, Japanese, and Korean writing systems."?
Google Docs isn’t pure-canvas: they only switched their document area to use it for layout. Text rendering is still browser (necessary to keep performance even close), and all the rest of the UI is still DOM. Having thought extensively about it, I cannot come up with any advantage to the approach they’ve taken—neither the performance¹ nor the consistency² angles make any sense, and the product is actively worse because of it³. I’ve written more about it on HN at times, skim https://hn.algolia.com/?query=chrismorgan%20google%20docs&ty... for more. Seriously, having thought about it very carefully and reviewed the matter several times over the years, I honestly believe that they lied in their justifications.
Flutter… ugh, Flutter on the web is awful awful awful awful awful AWFUL AWFUL and I will hate you if you decide with open eyes to use it when you’re deliberately targeting the web.⁴ I lack energy to express my vitriolic loathing. Just go through https://hn.algolia.com/?query=chrismorgan%20flutter&type=com..., there’s lots of detailed explanation of specifically what’s bad, if you need it.
Avalonia Visual Basic 6? It’s the kind of thing where the limitations will show least, because of how limited it is. And also because it’s imitating (not quite the right word, but close enough) ancient software which itself wouldn’t work fully properly if run on current machines. Its text handling is dodgy, doesn’t do composition properly, scrolling is non-native, context menus are non-native which stops some things from working properly… but honestly that’s kinda the vibe they’re going for, so it’s not particularly upsetting.
Pure-canvas is irredeemably bad. With difficulty you can make some things decent even with it, but excellence is impossible with pure canvas.
Flutter and Google Docs did not give up on DOM for the reasons you cite. Google Docs, I honestly don’t understand why they gave up on DOM, the reasons they cited publicly genuinely don’t make sense. Flutter, it was because they don’t actually care about the web, it’s a third-class target, and too much of the way they design their API doesn’t port to DOM directly, so that making DOM a first-class citizen would have required compromises in their APIs that they were unwilling to make. But it was emphatically not about cross-browser consistency.
—⁂—
¹ Seriously, Google Docs is slower than it used to be, especially with higher latency and jitter.
² The parts they replaced had no consistency problems in any realistic browsers. Seriously. Their layout requirements are, in practice, really basic. The area where consistency can actually be a problem is text shaping and rendering, but they haven’t replaced that since it would tank performance.
³ My favourite example is keyboard navigation. It doesn’t match platform conventions, and that’s really irritating. Since we’re in this thread, LibreOffice also flouts platform conventions in this area, and it’s really irritating.
⁴ If you’re focusing on mobile and make a mobile app with Flutter and also put it on the web with Flutter because why not, better than nothing, I won’t like you very much, but I’ll at least understand. But if you’re saying “we need a web thing, how about we use Flutter”… no.
> But if you’re saying “we need a web thing, how about we use Flutter”… no.
If you're making an application, there's really nothing special about the DOM.
You might as well control your drawing. That way you don't need to figure out cross browser incompatibilities all day.
And here's what someone who used to work on Google Docs has to say about it:
https://news.ycombinator.com/item?id=27133929
Please look over my comments on HN about Flutter and pure-canvas and such. There are big problems. There is plenty special about the DOM that you lose and cannot gain back if you go pure-canvas. Links. Scrolling. Text handling. Composition. And various more.
Use DOM. Please use DOM.
Use canvas for an actual drawing canvas, but for the UI and anything else that’s largely text, use DOM.
There aren't "big problems" because it works. When you put yourself in the corner of claiming "pure-canvas is irredeemably bad" when it's plainly not, then there's nothing practical on offer.
“It works” is a terrible defence, because of the different degrees of working.
I’m describing various specific ways in which it doesn’t work properly, in ways that stop users from doing things they may legitimately want to do, or which will frustrate some users, and you’re just disregarding them. I’m not being vague in most of my complaints, I’m being very specific.
It’s like you have a screw, and it’s worn enough that sometimes it makes the screwdriver slip, but you’re saying “just be careful, maybe apply a little more pressure, and it still works”.
How the hell you can claim “it works” if you can’t even select text out of the box, lmao?
OnlyOffice has decent performance and is pure canvas. However, they have (or had) issues with respect to accessibility, as screen readers don't read canvas.
Barely worse than Teams or your typical web app. Needs polish for sure but the bar for web apps aren't exactly high.
Canvas usually breaks text selections etc. and accessibility. But what they do seem to perform much better than trying to get the DOM to do something it wasn't designed for.
When you delve into badly-performing web apps, DOM is almost never the actual performance bottleneck. It’s other things they’re doing. And in the rare cases where DOM is the bottleneck, it’s always that they were abusing it.
As for this case, I have never encountered a web app with performance (throughput and latency) problems like this. Not anywhere near it.
interesting, on my 2019 ipad pro, after initial loading that took a bit of time, editing was quite quick and fast for me*
i wonder if there is some parts that remain unaccelerated or hitting performance bottlenecks on linux/firefox?
* admittedly a bit low-res/ugly and hard to use on touchscreen
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).
> ZetaOffice is also available as a native Desktop application for Linux and Windows. Download the Beta here.
Why is a desktop application being developed and provided if this is compatible with LibreOffice (since the latter already has desktop applications)? Is it just to have the same name and recognition?
Is the desktop application kept on par with the latest LibreOffice release or does it only guarantee document format compatibility up to a specific version?
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.
Looks like anything that can be snapflatpacked will be snapflatpacked.
That's excellent! You guys should interact with Nextcloud or someone should try their hand at a Nextcloud App [1]. Nextcloud's solution to Google Docs & friends is via the integration of OnlyOffice[2], which requires a DocumentServer [3] to function in the context of Nextcloud. Even without the collaboration aspect, having LibreOffice work off WASM, without any extra infrastructure requirement would be an excellent edition to that ecosystem I think.
[1] https://apps.nextcloud.com/
[2] https://www.onlyoffice.com/
[3] https://github.com/ONLYOFFICE/DocumentServer
Nextcloud is a steaming pile of barely maintained donkey dung one should not approach with anything other than a 10' pole while wearing a full Hazmat suit.
I use it at home just fine. Granted, I only use it for files and I’m not using the office apps from it.
Nextcloud is terrible and will eat your data, silently and without remorse. Avoid it at all costs.
What does "Nextcloud will eat your data" mean, specifically?
Do you mean the applications of the suit are buggy, or are they somehow hackable / leaking private information?
"Eating your data" seems to refer to very serious bugs rather than leaking or vulns.
Zeta.js is such an impressive JavaScript library. I'm blown away. The examples where you can load a document in less than ten lines, amazing. Then, change colors of all cells in less than ten lines, amazing.
I'm also blown away that there is a gulp file in the repository. That's a blast from the past.
I'm still working with stuff using grunt (most certainly not my choice). gulp is not that bad as a generic task runner, though the last thing I'd use it for these days is to build JS artifacts.
While it is an amazing technical feat, there are, expectedly, a bunch of quirks to be ironed out. The font rendering, for example, is very bad. Very excited to see how this goes in the future!
That animated ad is a total turn-off.
I've used LibreOffice/OpenOffice/StarOffice for two decades now. It's OK, not great. At least it interoperates with Microsoft desktop formats now. Mostly.
LO is contantly updated and improved. The 2 decades observation isn't really useful. Would you compare today's MSO experience to MSO2000 on Windows Millenium?
I use LO exclusively and it's a joy to use. On the rare instances I'm forced to use MSO it feels only marginally better than google docs. YMMV
And, strictly speaking, the reason things break sometimes when switching from LO to MSO is because MSO is broken: LO follows the spec (both .odt and .docx) faithfully, which then breaks when MSO relies on undocumented features or outright bugs for the end-result (i.e. the "works best on Internet Explorer" legacy).
I would love to have something like this in order to provide the office features for documents hosted in nextcloud directly. Yes, there is Nextcloud Office/Collabora Office but this needs separate provider and is not included in hosted Nextcloud (e.g. at Hetzner). The ease of OneDrive + MS365 in comparison is quite attracting. For my current use (sharing documents in a team of 50 - non-commercial but somehow professional approach) the latter is still the tool of choice. Being able to share a link, which allows others to directly edit presentations and spreadsheets in a browser (while the files are available in a local file structure) is just great.
Cryptpad, which includes a bundled copy of onlyoffice, works quite nicely.
I can remember testing libre office in the browser many years ago, seems like that project was frozen in 2020 as others external projects emerged. The wiki has a guide for docker:
https://wiki.documentfoundation.org/Development/LibreOffice_...
the link you refer to talks about collabora and allotropia. the first is what powers Nextcloud Office/Collabora Office online and mobile apps (using coolwsd). the latter is allotropia, who is behind Zeta that is mentioned here. both have a slightly different approach to how this works. as i understand it, all of this is upstream and not really frozen; perhaps that page needs an update?
Note: "LibreOffice Online is not intended as a standalone software. His goal is, instead, to be integrated with other tools to edit their documents." ... while Zeta and Collabora are standalone.
It wasn't frozen, Collabora were the ones doing the work and so they have largely hosted and developed LibreOffice Online.
There is also https://fleet.linuxserver.io/image?name=linuxserver/libreoff...
Keep in mind that Zeta office runs completely in the browser with WASM while the thing you provided runs on a server and just streams back and forth to the client.
Looks interesting. What is it?
how is this different from http://www.collaboraoffice.com/ ?
Collabora works on mobile devices and integrates with Nextcloud
note: they use WASM, so the load is on the client. Collabora relies on a server part, though easy to host.
How does this work? Is it WASM-based or what?
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.
It sounds like you might know the answer to this. Would it be straightforward to use this for sandboxed headless file conversion? You can do that already with LibreOffice, but it's a monster amount of unsafe code that's difficult to containerize securely
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.
Oh whoa a 5 minute video for exactly this :) Apologies for making you be my Google. Yep, everything in wasm makes things much easier to work with, especially if you want to run it on a client device
I just containerized LibreOffice to do docx->pdf conversation, but now I'm wondering - what parts seem particularly gnarly to you? My naive strategy is to mount an external volume to put/collect files, then call `soffice` inside the container to process them. We generate all source docx files so I'm not worried about an injection from that angle.
It runs on ProseMirror and AG Grid.
Joke aside, the source code isn't featured on the web page, despite LibreOffice (unlike Apache OpenOffice) being copylefted. They mention self hosting, but it says to contact them. It seems it runs on WebAssembly either directly or through a VM on top of WebAssembly like https://copy.sh/v86/ . The screen seems to be simulated with a canvas. I think perhaps they didn't change the code of LibreOffice much, but have a custom setup of something like https://copy.sh/v86/ or even are running it on actual WebAssembly with a virtual screen. So they have a virtual computer that it's running on, and they consider that separate when it comes to copyleft obligations. Plus it's possible to make something open source but inconvenient, and charge to make it convenient.
From the description here[1], it sounds like they're using WASM builds of LO.
I'm not quite interested enough to spend the CPU cycles it'd take to build and see whether that is really the whole story.
[1](https://github.com/allotropia/zetajs?tab=readme-ov-file)
That's nice. AFAICT nobody has yet figured out how to run the rust compiler in WebAssembly directly, but it runs in v86. That's why I wondered if they were taking that shortcut for another complex program.
Here's their page about WASM: https://wiki.documentfoundation.org/Development/WASM
It says it uses Qt/VCL. Maybe those can talk to canvas in a fairly straightforward way, or maybe ZetaOffice chose a different backend to get a proof of concept out faster.
Side question: did GTK3's HTML renderer get anywhere? I remember a calculator application running in a browser as a demo from a long time back.
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.
It looks like they've developed a javascript library that interacts with a WASM build of LibreOffice:
https://github.com/allotropia/zetajs?tab=readme-ov-file
I might do documents in the browser if LyX was ported to WASM and performance is good.
Love the Deep Space 9 Easter egg!