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.
> Or because the DOM is a piece of technology designed for rendering documents and not web apps
IDK, it seems to have been pretty successful at it to me, being of the most popular GUI frameworks currently, probably the most popular by a wide margin.
Being designed for documents it should exceed at rendering documents.
The problem isn’t on the DOM itself, it’s in mapping other frameworks to it. Of course it‘d be hard to port LibreOffice‘s rendering to the web, it‘d be a crazy amount of work to reach parity.
And it’s fine to argue that it doesn’t make sense at all to use the DOM for non-web document editing: OnlyOffice doesn’t do it either, as far as I’m aware.
It’s just a bummer to me since documents are exactly what the web was made for.
The fact that there are so many alternative languages for the JVM or which transpile to Javascript suggests that (at least to many people) that neither were ideal choices for their current uses.
That is like saying the existence of cargo trucks, pick-ups, minivans, campers, and rv's shows that the underlying 'internal combustion engine' technology is flawed.
I think it rather shows that the technology is so useful that it is able to spawn different implementations aimed at slightly different use cases.
They're much harder to "disassemble" and applications written in them are much harder to modify and a relatively open DOM + JS model. Looks like a very promising technology for an ad company that's been pushing to make ad blockers significantly less effective, and has never let you install an adblocker into the most popular browser on the most popular platform in the world.
In the case of Google Docs kt might be because it is really convenient to use canvas because then it gets much harder for clients to do things Google don't like, i.e. interoperability.
In other cases, like in IE^h^hChrome and large Google products like Calendar and YouTube there have been some interesting cases I think.
A div element is a node in a tree which will be rendered by a very opiniated rendering engine adhering to a fairly strict set of standards, and which can be manipulated using a limited subset of technologies which are themselves fairly opinionated.
A class Rectangle can be pretty much whatever you want.
> A class Rectangle can be pretty much whatever you want
In what way can an `HTMLDivElement` not emulate a `class Rectangle`?
- Both are rectilinear
- Both have width, height
- Both can have borders, backgrounds
- Both can be positioned in various grid/layout systems
- Both can contain child instances
- Both can contain a variety of child nodes like `Text`
- Both can be clipped and masked
- Both can be layered
What can you do with a `class Rectangle` from a GUI perspective that you can't do with an `HTMLDivElement`?
A class Rectangle can be whatever you want. You can overload it. You can change everything including how it’s rendered. It doesn’t have to be any of the things you list.
A div element is a node in a tree which will be rendered by your browser in the way specified by the spec. You absolutely can’t freely do most of the actions you list to a div. There are severe limitations.
A div doesn’t at all emulate a class. Its semantically something completely different.
> A Rectangle component is a node in a component tree which will be rendered by your OS graphics library in the way specified by the spec. You absolutely can’t freely do most of the actions you list to a div. There are severe limitations.
No?
It seems like you're just talking about a `Rectangle` in the abstract rather than the real limitation that even `class Rectangle` is subject to the rules of the runtime engine that renders said `Rectangle`...in a component tree...with the restrictions of the OS/GUI framework...
Rendering outside of a web browser gives you a lot more freedom when it comes to how you layout and render. Rendering engines don’t necessarily use components tree by the way.
Even gui frameworks (which is what I think you are talking about with OS graphic library) have layout engines which are a lot more powerful than css. Flexbox is a step in the right direction but still inferior to what some frameworks could do 20 years ago.
So instead of standardized element that works pretty much the same on every browser, that can be inspected and controlled by virtually every tool that works with web I, as a user, get a binary blob, correct?
> And you can’t even control zoom/scale on desktop.
I must note (in the interest of factual accuracy, though as you see I loathe the approach) that this is not a fundamental limitation, just something that Flutter and probably ZetaOffice have chosen not to support. You can block such things in a DOM world too, and it’s stupidly common for app-like things to try to do so.
Google Docs' Writer (or whatever they call it) is a terrible child's toy, just like Word of Office 365.
Functionality is severely limited compared to traditional word processors like LibreOffice.
> 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.
And as a side effect, of course if you require the canvas, you will also be able to abuse the canvas, to fingerprint users. It is strange, how those things seemingly always coincide when it comes to Google products.
> Google Docs' Writer (or whatever they call it) is a terrible child's toy, just like Word of Office 365
I'd believe the vast majority of the user base has never noticed anything off with these applications. I have noticed one or two things missing in the in-browser PowerPoint and that's about it. If you want to do precise publication layout, Word (and Writer) are not the appropriate tools - you'll need something like InDesign.
For the vast majority of what I do, a toy is all I need.
This is the nasty catch-22. It is preferable to have a single tool that handles both simple and complex cases. But sometimes, you just can't make one tool that does both well. If you optimize for the hard cases, then most users will use only a tiny minority of the features.
Microsoft tried to work around that with the "ribbon", which tried to learn which features each individual uses. Users hated it.
So I keep around LibreOffice for the hard stuff, which I write perhaps once a year. And I use Google Docs every day.
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”.
Of course. You're living in a world of your own imagined requirements. The practical reality is that there are plenty of use cases for this stuff, whether you like it or not. This stuff is fit for purpose for many purposes.
What about screen readers and mobile users? There's all these useful accessibility tools that would also have to be reinvented for canvas based apps.
Text selection and getting it to bring up a keyboard is iffy on the canvas-based things you linked to (I'm looking at them on Firefox for Android on a Pixel 6). Sure, the VB one is a desktop app. But the original (non canvas) version of that app likely worked with windows screen readers, and that is lost in this reincarnation onto the web. Good old fashioned DOM already has pretty good native accessibility support for mobile phone UI.
There's a lot of things that have been thought about when it comes to usability and accessibility, in both the web, and traditional desktop/mobile UI frameworks.
Reimplementing those UI frameworks in canvas in a browser environment requires mapping the a11y bits too, not just keyboard+mouse input and rendering to screen.
Not to mention Qt and Gtk and the older Android framework apps all use forms of markup and styling which are inspired by XHTML and CSS and document object models......
> 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).
Yours is a common sort of objection, but somewhere between largely and completely irrelevant and/or wrong. Somehow I fail to convey my point and what my objections are, and people assume I mean certain things that I don’t mean and didn’t think I necessarily implied.
When I say “targeting real DOM”, that doesn’t mean you have to be subject to the browser’s layout implementations, though preferably you would still use its text shaping. You can still do all the layout yourself, if you want, and position everything absolutely. In practice you’ll tend to want to do at least a little of that, if you want to be able to support editing large documents; and much more if you’re aiming for consistent-across-devices layout. (… which my sister, who actually uses Word for work, reports Microsoft has been hugely slipping on—and Word never was intended as a desktop publishing platform.)
View DOM as more a rendering target; I don’t mind at all. So long as you’re using real DOM for input and output, most of the problems I’m complaining about will go away. Selection, editing, context menus, text rendering, all these things will be done properly.
If you take this approach, it is possible for you to run into some incompatibilities in advanced shaping, if your layout/text shaping engine and the browser’s behave differently, but in practice that will practically never happen any more in shaping, and in other areas you can control it.
I would also clarify what I thought was clear enough from my initial comment’s context: when I speak of “decent results”, I refer to the editing experience, not document layout fidelity.
"Release early, release often", isn't that the often touted wisdom?
Of course that has the problem is that you can make the "first impression" only once and when that said "first impression" is terrible it can be really hard to convince anyone to try the software again for the second time.
I guess releasing, almost like everything else, is a balancing game between two early or too late and both extremes have costs.
On the flip side, this is extremely fast and works pretty well on my M1 Pro Macbook running Chrome. The only downside is that it's a little blurry (as it's rendering at 1x pixel scale).
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.
MS Teams is among the worst pieces of software, that people have to deal with on a daily basis, because it gets shoved down their throat at their jobs. If something is even worse than that, even if "barely", then it is a complete disaster. A little "polish" will not be able to make it right.
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.
Similarly I don't think canvas is the bottleneck here.
Oh, and abuse is the name of the game. Almost exclusively the only thing the browser deals with is abuse. Logical consequence when the users are the one paying for it.
Do you test as much on FF as on Chromium based browsers, during development, as well as in quality assurance steps? I could imagine, that some devs are looking at it in Chromium (or even Chrome shudder) all day, while implementing things, and then just having to tick a checkbox for FF "Yep, seems to work.". Which would of course lead to a Chromium-centric code.
Being one of the ZetaOffice (and LibreOffice) hackers, I use Firefox as my primary browser. And I really don't like using software only Google knows how to support (=> Chromium). Sometimes I even think about migrating to SeaMonkey
But for example, you unfortunately can't properly debug multi threaded WASM code in Firefox.
Have a look at the Firefox developer tools' debug tab with this page opened. And it will list the threads (web workers) named with some randomized UUID. Impossible as a daily development driver :-/
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).
> 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.
I've run Nextcloud for years primarily for webdav file sync and calendar+contacts. It pretty much just works. That's not to say there isn't any jank, but it's mostly if you try the more obscure apps e.g. I've set up the phone track feature and it worked for a while, but I've had trouble with it recently. Probably fixable, but I just haven't spent the time.
I would say it is the core component of my self-(vps)-hosted setup and easily the most valuable.
What are its cons? I used it years back and worked fine; did it transition to the dark side or it's a matter of bugs? I'd use it only self hosted of course. Alternatives?
Last time I checked it (a few years ago), it was quite buggy and crashed often for me (self-hosted).
For example, what I remember, there was a module to move photos from Google Photos, but it always stopped at 10% photos without any errors. Then there was also some document suite module and it would hang my entire machine regularly, for some reason (had to restart it).
I disagree, it's useful to be able to click a document link and quickly preview it in your browser. At work, I have native apps for Word, Excel, PowerPoint, etc. and I still find myself using the browser version for quickly responding to a comment left in a document.
It's also useful to be able to quickly send someone a link to collaborate on the document without needing them to install anything. Installing a separate app may not be possible for aging parents, people using shared computers (e.g., library or school computer), or organizations with restricted IT systems.
Previews are different from native apps though, and when you click on a link to a document, you only have to click "Open" to open a native app. How is this an issue? For quick edits I can see the appeal, however.
> Installing a separate app may not be possible for aging parents, people using shared computers (e.g., library or school computer), or organizations with restricted IT systems
This seems like a non-issue, too. If my grandma were to use the PC, I would be the one installing programs (or the OS) on it, and if I knew she wanted to open and edit documents, I would install LibreOffice. It is one of the programs I install on my parent's computer. You (or the IT staff) ensure tools are available; you install LibreOffice, similarly to how you would install a browser to begin with. For example IT staff are already responsible for installing and maintaining browsers. Adding productivity software to their responsibilities is a standard practice in professional environments.
Browser-based tools are a complement, not a replacement, and the push toward browser dependence should consider the trade-offs in performance, user experience and so forth. Using browsers for productivity tools may feel more convenient in very specific edge cases, but for most users and workplaces, the effort involved in installing and using native applications is negligible in comparison.
(I remember the old days when I used https://gobby.github.io with my friend to edit code together. It is a native program for editing documents (incl. code) together. Today you would probably use an extension to VS Code unless it supports it natively (no clue).)
I am pretty sure there are people on here who would be able to explain it better than I do.
If "the browser" != [Chromium], but [Chromium, Firefox, Safari, Ladybird, ...], then I'm pretty happy with that. I consider it's much better then having Windows, iOS or GApps-Libraries-For-Android as de facto standard OS.
Surely, my beloved Debian would be the much more perfect OS for everyone ;-)
simple - performance is often garbage. web apps use more cpu and memory than a native app. people should not need an M1 MacBook or better just to edit a document. (see top comment)
The only reason people build “apps” in the browser to begin with is because it simplifies the development for the engineering team. Easier to ship, easier to update, write once, etc. Sometimes the user benefits, but rarely.
The other problem I have is it blurs the lines between data on your machine (private) and data that is in the cloud. not everybody wants all their data in the cloud. When you’re working with a “app” in the web browser it’s not always clear.
> The only reason people build “apps” in the browser to begin with is because it simplifies the development for the engineering team. Easier to ship, easier to update, write once, etc. Sometimes the user benefits, but rarely.
Interesting take. Usually web apps lower friction for users.
- no installations
- no large binaries
- collaborative
- easy to adopt
I can't think of any (desktop) app that came out in recent years that specifically pitched "because native, we are better" and won. Sketch is a glaring example of a web app (figma) killing native (sketch)
searching on the ios or mac app store, or sharing a link to the app download page, is not exactly hard to adopt most of the time.
Gen Z might think so but that’s because we’ve conditioned them to expect everything in a browser IMO, not because it’s actually complicated.
“no large binaries”, i agree browsers have an advantage here - somewhat. Most apps have large binaries because software development today is lazy. Companies typically use huge libraries for EVERYTHING and then their final binary gets bloated. For example 90% of apps (excluding games) could be 30mb or less. Stuff like analytics and user tracking, advertising libs, the list goes on.
Who says a native app can’t be collaborative? You can use http or websockets in a native app to push/pull data. That’s like saying social media apps aren’t collaborative.
I do agree some web apps are well executed. Figma is pretty good. Google docs and google maps are excellent. I have a few more that i genuinely enjoy using. That’s the _exception_ though.
The browser is for browsing the Internet, it is a tool specialized for that, it has nothing to do with being an operating system. Being able to boot an OS within it does not make it an OS either. It just adds an unnecessary and potentially detrimental (to both performance and security) layer: OS -> browser -> OS, which is just silly. If you do not see the absurdity, let us consider this: OS -> browser -> OS -> browser -> OS, ad infinitum. :P
Agreed. Shoving things into the browser is utterly stupid. Native apps are just plain better, stop ruining things by putting them in the browser please.
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).
Same here and at several other people who asked me for alternatives over the years. I installed LO (formerly also OO) both on Linux and Windows and they became productive almost immediately. However when I install it on other people PCs I always set the default save formats as Word/Excel/Powerpoint 97-2003 so that nobody will complain when they send files to other people who presumably will be running mostly MS Office.
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.
(same thought here; just didn't want to sound harsh)
The idea of LOOL (LibreOffice OnLine) is to be an embeddable component; we have used it before on a Moodle site. And this is the same for COOL (Collabora Office OnLine), which is used by Nextcloud Office (as components called COOLWSD, and LOKit).
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.
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.
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.
From what I understand, Collabora basically runs LibreOffice on the server side and relays the resulting image to the client. This looks like it has similar approach. And I'm sad to say it but Collabora is near unusable compared to Google Docs.
Humanity really does need an online self-hosted office suite that natively uses OpenDocument format, but I'm afraid that to achieve that it'll be easier to start from scratch with browser version as a first platform in mind.
Collabora office uses a custom web ui for controls, dialogs, etc. The document body is rendered by the server and streamed in raster tiles over a web socket.
Is it easy to turn it into a read only mode? Just for viewing? Basically I looked forward for such a solution for a long time, but everything I’ve seen is either too heavy or nearly impossible to scale.
I did not know that it is possible to wasm build lo!
I'm excited for stuff like this, but the stock image of 'who we are' is a long way different then the pictures you get when you follow the link to who they are.
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.