LibreOffice running natively in the browser via WebAssembly | Hacker News Reader

LibreOffice running natively in the browser via WebAssembly

lab.allotropia.de

571 pointssyrusakbary208 comments

Note that it will download around ~300Mb of data directly to your browser, so it might take a bit to load from slow connections.

Here's the related video from FOSDEM: https://fosdem.org/2022/schedule/event/lotech_lowa/

Appreciate the warning for those of us on non-wired connections!

Even with a fast connection, it takes a very long time. I'm guessing the site is overloaded as the peak was a few tens of Mb/s, and generally much slower.

Makes me wonder if it is possible/usefull to make the download a two step process, first download a small wasm bittorrent client, then use it to download (and share) the 300mb file.

Webtorrent already exists, and does not require wasm.

https://github.com/webtorrent/webtorrent

Could WebRTC be used directly here?

Or it could apply gzip/brotli + optionally wasm-opt and cut the size ~5-6x: https://twitter.com/RReverser/status/1494435774003093515

It took about 20s for me, with the fans spinning up around halfway through. Once loaded it feels fairly usable, considering...

Does make you wonder what other optimization can be done. Maybe the whole thing doesn't have to be loaded in immediately.

Such lazy loading might be difficult to retrofit into an application designed for an environment where it can load a lot from disk to RAM quickly and has never (IME) been well design in terms of such resource use.

Some lazy loading could probably be done relatively easily where OO does on-demand load libraries, but that would significantly resource apparent in-use performance if truly done live so you'd want to background load the optional parts once the immediately needed ones are done.

I'm guessing that this is a straight compile to WASM with the minimal changes needed to things that would otherwise break completely in the different environment.

Autodesk has shared some information about how they solved this when building AutoCAD Web, which is a wasm app derived from their desktop codebase.

Video: https://www.infoq.com/presentations/autocad-webassembly/

Might be worth changing the link from the direct link to this video, given that 300 megs question.

And it's throttled too, took me ~8 min on a 400mbps connection to download those 300mb of data.

And it doesn't cache the download either, so refreshing the page forces you to download the entire thing again.

took me < 35s on a 300mbps connection from europe.

300 MiB. & … "a bit" — it takes nearly 20 seconds on "Gigabit" fiber. (312 MiB in 19.22s, or 136 Mbps.)

Runs shockingly smoothly once it starts, though.

Funny, it took me approximately triple the time on a 60 Mbps connection. Makes me wonder if its throttled from source due to a network overload.

yeah, 300mb is not nothing but also not that much. Using full speed it shouldn't take that long.

Progress bar would be nice, without these comments I would have no idea whether to wait or not thinking that maybe it got stuck in a loop downloading the same thing over and over again or something.

when i built my webapp with tons of packages, i tried to figure out if we could hook into the browser, but theres really no way that i found, my solutioj was to just make webpack split the bundles into chunks then have them announce themselves and a loading screen would tally

Haven't explored higher-up pages. Eventually, would be nice if there were a way to download everything to one directory and run offline. Is this only a demo for now?

> Runs shockingly smoothly once it starts, though.

On what hardware? I've got a 2019 MacBook Pro with i9 and 32 GB of RAM, and there's a noticable delay (I'd guess 200~400-ish miliseconds) when clicking any elements with Firefox or Chrome.

Works fine on my current work windows laptop, 16gb ram with some budget low electricity use processor.

Probably just apple not supporting anything web related as usual.

> Probably just apple not supporting anything web related as usual.

The comment you’re replying to specifically mentioned Firefox and Chrome, no mention of Safari.

Same on a very beefy desktop Windows system.

It runs smoothly for me when zoomed out but when you zoom in on a page it starts to lag. Nevertheless its quite amazing to see LibreOffice running in the browser.

"its quite amazing to see LibreOffice running in the browser"

You should see jslinux:

https://bellard.org/jslinux/

Running on an M1 Max and getting 5-10 fps. Not what i'd call smooth.

took me 2 hours to load... LOL

The sad part is, it could be cut very easily cut down to ~60MB with basic optimization & compression (heck, even gzip/brotli compression alone would go a long way): https://twitter.com/RReverser/status/1494435774003093515

Impressive feat, but I'm worried this small detail ruins the first impression for way too many.

Damn, you are 100% on point. I assumed it already had the optimizations applied and it was big just because of the nature of the app.

Once they get their server bill perhaps they will reconsider optimizing it!

I remember when LibreOffice was called Star Office and would run like molasses on a Celeron 300A OC to 450mhz machine. The office suite would take up most of the ram and eventually crash due to system resource exhaustion.

Now we can run the whole thing in a browser like it's Minesweeper. Wow.

> Now we can run the whole thing in a browser like it's Minesweeper. Wow.

I don't know what you're trying to say with this. I'm currently asking myself if it is really slow to compile/load, of if uBlock Origin broke something. I'm patiently waiting.

Update: It's kind of amazing to see what can run inside a browser.

I just downloaded and ran it on a galaxy note 10, took about 30 secs over LTE.

Mind blown.

You could already do that in 2011, just had to install Flash with CrossBridge, use Chrome with PNaCL, Silverlight,....

It also had its own desktop/file manager back then. Good thing they removed it, although I often thought it could have been a nice optional feature to make small dedicated office machines that would load a very light OS image with the bare minimum necessary to run it without an underlying desktop manager.

I remember it as well -- found it astonishing that it took up half the CPU just idling. Star Office was just a truly awful product. Literally the only interesting thing about it was that it was free.

I can always remember thinking 10+ years ago that browsers would never be able to run 'proper' applications like Photoshop and Office, and would just be limited to CRUD style apps (around the times of IE6 when even basic CSS was buggy and hard to get right on multiple browsers).

Now I only use Figma - and never open Photoshop (for UI design). I rarely open MS Office, use google docs without thinking.

Data is still a problem for audio and video apps, because there can be so much of it.

... and it's as slow as on the Celeron! I guess it doesn't crash my entire machine, but that's an implementation detail which we'll surely workaround next.

Yeah, just because hardware got incredibly fast doesn't mean slow software is fast now, it just expands tothr available circumstances again

If minesweeper was a 300mb binary. Yes.

I wonder if I can run Office 2000 on my current machine. Would require so much less RAM and CPU.

I started experimenting with Go-WASM recently and learnt that writing non-blocking code is very crucial, Timer even inside a Goroutine blocks & crashes WASM. Leading me to use unreliable JS timers(albeit mitigating it with a worker) and performing only non-blocking compute on WASM.

Is this just a consequence of using Go for WASM(i.e. lack of WASM threads), What are people who built LibreOffice in WASM or Doom3 using? Can Go-level concurrency be achieved with WASM threads when programmed with other languages?

WebAssembly is having/going to have threads

https://github.com/WebAssembly/threads

Go hasn't enabled it since it's still in proposal stages[1], Hence my question was regarding it's implementation using other languages and general experience of it.

[1] https://github.com/golang/go/issues/28631

This doesn't sound right to me, are you running your WASM in a worker so it doesn't block the main UI thread?

I require a Go UI library(ebiten) so wasm cannot be initialized and run purely via a worker, But I've tried executing the timer inside a Goroutine with a handler as recommended by Go team but no dice[1].

There are others who have complained the same on SO.

[1] https://github.com/golang/go/issues/41310

You may want to file a bug on Go - I believe goroutines should work, including swapping between them. The code is emitted in a form that allows that (switch-in-a-loop pattern).

Another thing you can try is TinyGo, whch uses Asyncify (a general wasm transformation to allow blocking) for goroutines,

https://twitter.com/TinyGolang/status/1461364896197578759

Doom3 uses Asyncify in some parts of the event loop, for similar reasons (blocking code). I'm not sure if LibreOffice does as well, but it might.

You're right, I think I should file a bug.

The Go library I need(ebiten) isn't compatible with TinyGo, I did try it for the reason you mentioned and to reduce size.

> Doom3 uses Asyncify in some parts of the event loop, for similar reasons (blocking code). I'm not sure if LibreOffice does as well, but it might.

Thanks! That's what I wanted to know, So it's certainly possible to write asynchronous code using C++ and Rust.

Yes, async code in wasm is definitely possible. See for example here:

https://web.dev/asyncify/

It does have some overhead atm, which a new spec (stack switching) will remove eventually.

What the hell. This feels basically native?!

I had no idea WebAssembly was this far developed. This feels like electron in reverse, and GOOD.

It's completely frozen for me (after downloading), but it's very cool for sure

What's your environment? It feels like incredibly poor performance for me (Firefox on macOS)

Firefox 97 on Ubuntu 20.04.

It took a while to load, but the site is probably seeing heavy loads. But afterwards it feels like a native application.

Smooth for me in Firefox on linux too. Maybe check about:support to see if there's any graphics driver issue?

Is Electron the baseline to compare to these days, instead of an actual native app?

I meant Electron brought webapps to the Desktop. Now Web Assembly seems to bring native apps to the browser.

So the next step would be to write "electron-browserify.js" which emulates a JS runtime in browser so you can run Electron apps remote.

I'm sure there's a relevant XKCD somewhere.

I can’t really remember who but some months ago a coding scratchpad website launched full virtualized Linux environments in the browser through WASM, you could run Node on it.

Well someone has already got WebKit to run in WASM[1] so hey, maybe it’s not that far off :D

[1]: https://github.com/trevorlinton/webkit.js

Next step is bring native apps to the desktop. Then we'll be cookin'

Define "this far".

The toolchains for webassembly are still not trivial to use.

I wish more work was done to support WASM, but it requires a lot of work from compiler developers, for each language backend, so it's still a lot of work.

Not to mention that I have almost no clue how to debug a WASM build.

WASM is clearly the future, but I don't think there is any company really spending money to write better WASM tools, and you can be sure WASM is against the interests of google, apple, microsoft etc.

Why is it against the interests of large tech companies? I get Apple, but Google is always pretty eager about the advancement of the web platform, see Chrome and Chrome OS.

Microsoft was once super scared of Java because it could have filled the role that WASM and desktop browser apps now try to break into. Microsoft tried EEE, but Sun bit back.

Google is happy with most anything you do on the internet, as long as you do it in Chrome so they can watch.

I’d say it’s more about Google search being the front door of the internet to most people, so while internet usage is high so is Googles revenue.

> Not to mention that I have almost no clue how to debug a WASM build.

I've got you covered: https://developer.chrome.com/blog/wasm-debugging-2020/ (TL;DR use Chrome DevTools with the official DWARF integration)

Wow, things have come full circle. I built and launched a browser-based office suite in about 1998 called Office Wherever that used a Java Applet.

VCs laughed us out of every meeting.. "No-one will put their private documents on the Internet! You're mad!"

WHO'S MAD NOW, HUH? Huh? Huh...

You still got the source?

No. I wouldn't want to inflict that upon anyone. I'm more bummed that I let the domains expire, especially the short one which was o-w.com.

> I'm more bummed that I let the domains expire, especially the short one which was o-w.com.

It's ironic that you could've made more money than you would have gotten from VCs with that domain name. You probably didn't know that back then.

Ha, no. 3 letter dotcoms were still worthless in 1998, I don't think they were quite all used up. Especially ones with a hyphen in them. Going back to 1994 I owned a whole bunch of domains that later got sold for 7 digits. All dotcoms were free in 1994. It was later they started charging for them, so I let them all expire.

I'd have been a millionaire many times over if I could have read the future. All those Bitcoins I mined in early 2010 and lost all the keys/wallet.

Sure thing. I meant you could have sold it later, in the 2000s. I remember finding many 3-letter .com domains in 1996/97 but didn't want to shell out ~$100/year or whatever netsol was asking for those days.

That sounds interesting. Your concept was ahead of its time.

Do you have screenshots or a video demo to share?

> "No-one will put their private documents on the Internet! You're mad!"

I miss the days when people had this much common sense.

Indeed, people have got used to running their stuff on other people's machines.

TBH, "In a browser" (like here) is pretty different from "on the Internet" (like google docs). Except that if someone was to make slight changes to the hosted application, it could leak everything.

In other words, a distinction without a difference.

> "No-one will put their private documents on the Internet! You're mad!"

They were essentially right, but unfortunately people have gotten used to having almost no private documents. Or rather, redefining privacy as "just me and the government and the large international corporations".

Something like this was tried before. The year was ~1995 and the trough of disillusionment for Java applets was far in the future. WordPerfect decided that the future was the web and they wanted in. They ported WordPerfect to Java and and published an applet. The applet was huge (at least 10's of MB), particularly so when fast internet access for most meant a 28.8k modem.

After the excruciating wait for it to load, it crashed. I would have been happier if it would have at least flashed a message "don't forget to drink your Ovaltine."

A quarter of a century later, this attempt works much better.

Not really the same. WASM is part of the browser and an open web standard. It can be emulated entirely in JavaScript which comes with serious security guarantees.

Java applets are in the same category as ActiveX controls, which is basically hosting native code (with all the security issues that entails) in a DOM element.

Going to "Open..." a file seems to show a whole Android filesystem. Is this actually running some minimal version of Android in WASM?

I believe it's been compiled with Emscripten under the hood. So it's using the Virtual FS provided there.

Yep

A hundred plus comments and not a single mention of GIMP?

I think we are close. After COVID, we should be releasing a lot of the emotional attachment to the C programming tools. And by 2025, we should be able to have the Windows version of GIMP running inside Mac versions of Chrome, on top of Wine, X Windows, CC and WASM in Chrome. And since Chrome can be compiled to WASM, we could have GIMP running on Chrome and Chrome running inside Firefox.......

And the story ( or history ) continues in the link below.

https://www.destroyallsoftware.com/talks/the-birth-and-death...

Wait... Isn't LO a Java application? Have we created a new way to shove Java into a browser, but this time with the JVM itself inside the browser?

I think you're confusing it with OpenOffice. IIRC LibreOffice is mostly C/C++.

LibreOffice is almost entirely C++, except that there are some extensions written in Java (and some written in python)

I say almost, because we still have some QA code used for unit tests that is Java.

LibreOffice is a fork of OpenOffice, which has been dead for nearly a decade. I doubt they rewrote all of the core functionality.

OpenOffice wasn't written in Java either. They did have a few small Java components (for example, HSQL) but it it was predominantly C++.

It's mostly written in C++, and the bulk of the effort which made this possible should probably be credited to Qt: https://wiki.qt.io/Qt_for_WebAssembly

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.

Side note: is there a way to get that Qt version of libreoffice somewhere on the desktop ? It's one of the only non-Qt apps I sometimes use :)

> Qt clearly deserves the credit for having a WASM runtime that gets us a working GUI toolkit.

You're welcome. :) What version of Qt did you use for this demo? Also, for local system file access dialog on Qt wasm, you can use https://doc.qt.io/qt-6/qfiledialog.html#getOpenFileContent

Answered my own question by reading the README.wasm.md "We're using Qt 5.15.2 with Emscripten 2.0.31. "

You don't need a JVM to run Java code in the browser since there's a VM already. There's TeaVM which compiles Java bytecode to WASM.

It's true, but it is a Java subset - not a complete Java SE.

True, but most of the time you don't need a full Java SE stack. Android still has only a Java subset and that hasn't stopped people from writing apps for it.

Now make firefox run inside my edge browser using wasm

You joke but imagine every website bundling its preferred browser. Web developers can just bundle Chrome 123 with their website in lieu of testing in other browsers. Every website will be a 50 MB download. Poly fill on steroids.

I wonder if title should say "in Chromium-based browsers" rather than "in the browser". Especially when it doesn't run in Firefox or Safari.

It's working OK in Firefox for me on 97.0 (64-bit) in Win10

It runs relatively well in Firefox on Android, though the UI latency is a bit higher than using the Chromium engine. If Firefox fails, you should check your privacy/scripting settings, because it's working fine for me even with privacy-preserving addons installed.

Of note is that if you're on iOS, all browsers must use Safari as a rendering engine by Apple's decree, so any browser you try is actually just Safari with a skin (no Gecko/Blink). This means you can't run this on iOS, due to Apple's WASM size restrictions, regardless of the browser you try.

> Apple's WASM size restrictions

What are those? I searched for that and I got no relevant results

> This means you can't run this on iOS, due to Apple's WASM size restrictions, regardless of the browser you try.

What is this? I paid for x GB of RAM and now Apple prevents me from using it?

Edit: abstracted away actual memory size.

128GB of RAM on iOS?

The most expensive iPhone 13 models ship with 6GB of RAM.

It also works for me in firefox 96 Debian, Linux but it needs some time for downloading...

You can't open local files or save to local files. Open/Save remote crashes...

Pretty impressive though.

I haven't tried much yet, but it seems to work fine for me in FF97 on W10 and a modern but not extremely fancy laptop.

In Firefox 97 on Windows, I repeatedly got "this page is slowing down your browser"; but in Firefox Nightly (99) it's amazingly smooth.

Running in Firefox 96 on an M1 Mac pretty nicely indeed :)

Scrolling feels a little big laggy but entering text and moving things around all feels snappy.

The fact that it runs at all is an amazing achievement. Kudos to the team that managed to shoehorn it in.

What is likely to be seen as a bug by others, is actually the thing that gives me hope. There's no way for a WebAssembly program to access the host file system. I hope it stays that way.

If the Wasm host can, in a foolproof and easy to verify way, offer the user dialog boxes to read/write single files... we'd have the "PowerBox" that is required to make a modern capability based operating system.

Preventing a process from deciding itself which files to access disables so many attack vectors.

Sounds like the upcoming File Access API is exactly what you have in mind

https://developer.mozilla.org/en-US/docs/Web/API/File_System...

That's not a bug, that's a very deliberate design decision. WASM programs run entirely sandboxed.

> Preventing a process from deciding itself which files to access disables so many attack vectors.

It also disables a lot of existing use cases and file types (basically any multi-file file format):

Multi-part archives, multi-part video files, playlists, videos with separate subtitle files, HTML documents containing links to other local HTML documents or referencing various sub-resources (images/videos/audio/style sheets/scripts/...), Audacity projects, images with metadata in external sidecar files, ditto for georeferenced images, QGIS projects, AutoCAD's lock file implementation, DWG files as such, …

Edit: And since we're talking about Office software: Spreadsheets referencing data from other spreadsheets stored in separate files…

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

In this particular instance yes, of course – this was more with reference to the dreams of some people who want everything to work like that.

It would work differently. Libre office would think it was accessing a local file, but really it would be whatever the JavaScript tells it exists. So you might be able to implement a rudimentary online doc and storage system using this if your users could suffer tab sizes of 300MiB for every open doc.

FYI: Safari does not work because of Safari's binary size limitations.

So much for write once run anywhere

I'm not too sad if my browser vendor decides they don't want to support someone foisting multi gig executables on me via their webpage. Doesn't even need to be my browser vendor, anyone with enough market share will do. I'm pretty sure you could write a much better office suite¹ than LibreOffice is with a footprint that's closer to 10MiB than 300MiB, and I suspect we're more likely to see such software if browser vendors impose some artificial limits on bloat.

¹Not with full blown internationalization support for languages with very complex text rendering requirements etc., but most people don't need that.

I can't find it anymore, but related and interesting is office 365.

To have a quick online version of office, they ran the eve/dll's in the cloud and send it back to the end user.

While it most definitely worked, it was definitely expensive as a first version. But it was too stop Google with their online office suite, as they didn't had an online response yet.

( Searched for the source, but can't find it. If anyone has it, please share. It's pretty old news by now).

They still do, the Excel engine is the native one.

https://www.microsoft.com/en-us/research/podcast/advancing-e...

In Safari on iPadOS and MacOS, after a minute or two of downloading, I got the following message:

Application exit (TypeError: Cannot convert "undefined" to int)

The page did finish loading and compiling in Chrome on my Mac. Menus, text input, etc. seemed to work but were sluggish, just as the standalone LibreOffice was for me on my ten-year-old MacBook Pro. (It works fine on my M1 Mac mini.)

Same here. Safari, Intel Mac Pro, Monterey 12.2 .

M1 Mac in Firefox, it was very sluggish when it ran (dragging a window around was about 1FPS), but it did run.

Safari sadly does not support the required WebAssembly module sizes.

I think LibreOffice on the desktop loads faster. I use LibreOffice under Ubuntu and Windows 10 for writing books and documentation.

Lately I checked Libre Writer on Windows 10 it had problem with kerning (not equal distance between letters) which made text looking quite bad. Did they fixed it?

- natively

- in the browser

Are there any non-native thing that runs in a browser?

Anything that uses a plugin. WebEx comes to mind, in the past I would have thought flash, Java applets, or ActiveX.

"Notebooks" like Jupyter, or Github Spaces and VS Code for the web, where a lot of the processing runs on a remote server, and the result is displayed in the browser.

Jupyter runs natively in the browser now with JupyterLite: https://github.com/jupyterlite/jupyterlite It can use a native browser JS kernel, or some languages that have been converted to run in the browser with WASM (including a full python environment called pyodide). Nothing is run on a server.

VS Code also runs natively in the browser now: https://code.visualstudio.com/blogs/2021/10/20/vscode-dev This uses a Chrome only (for now) filesystem access API to give the browser access to your native files--you can edit them entirely in the browser with nothing happening on a server.

I believe recently Safari added some support for the File System Access API. https://caniuse.com/native-filesystem-api

So we call it "locally" then.

Impressive, although much slower compared to the native one, at least on this (admittedly not stellar) 4300GE machine: the about window takes like 5 seconds to display, and page scrolling is a lot slower. Also caching doesn't seem to work: if I close it and load it again it seems to start the download/compilation process again, which is both a network and resources hog. Didn't wait for it to complete though, so I can't be 100% sure. Nonetheless an impressive result; I believe we still have to find a killer application for the technology; simply porting native apps to the web, to me beyond the technical accomplishment is the least interesting one, and also dangerous if misused because it encourages the transition to remote applications, which would take away from the users any control on which software they run.

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 .. ;))

Had to try Bromite to get it working well, but I'm seriously impressed by how fast this is on mobile (Snapdragon 855). Everything just seems to work, except the mobile keyboard because the browser doesn't know what to do with it or when to show it. If it works on my phone, this should run great on most modern flagships to the point of it almost being usable!

Quite an impressive feat to compile a complex program like this into WASM, this could be very useful for things like automatically scanning documents with macros for suspicious behaviour inside companies that run LibreOffice because of the near-perfect sandbox WASM provides.

The 300MB download can seriously use a progress indicator, though.

> Had to try Bromite to get it working well, but I'm seriously impressed by how fast this is on mobile (Snapdragon 855).

This is so interesting. I tried on my phone, oneplus 8 pro, snapdragon 865 so a little bit above and on a scale that does 1-10 where 1 is "not even in dreams" and 10 is "more-or-less tolerable" I'd rate it a 2 or 3. There's an ostensible slowness when just selecting text for instance. If for you this is fast I don't think you have any idea of how fast an actually fast computer can be and that makes me super sad for you !

I don't have time to do a more complete check, but am I wrong in assuming that all of these demos still have basically non-existant accessibility? Last time I looked Qt was still trying to pretend that was the browser's fault. As far as I can tell this seems to still be pushing out blobs of pixels to the canvas.

Seems really laggy for me on a 2015 Mac, to the point where I got a few unresponsive page warnings, but resizing at least works, so that's starting to get better. WASM continues to be very impressive/promising, and there's a lot of potential here. I just wish more of these frameworks would leverage the rest of the browser properly.

It works, amazing and congrats. On the other hand it lags so much when doing any real editing. It is the best proof that for these type of apps browser as an application platform is that bridge in Brooklyn someone wants to sell me.

So... I still use Apache OpenOffice, but it takes about 30 seconds to Rosetta itself every time I launch it on an M1 Mac. For some reason it never caches. The load time on this was actually about the same. I'd try it again from my desktop, but it pains me to think of whoever's paying for the bandwidth on it today.

Why in the world don't you switch to Libre Office?

I tried it awhile back, but it's also extremely slow on an M1 and I found the UI issues even more annoying than the ones I was used to in OpenOffice.

As far as I understand, apache open office is not really in active developement, unlike libre office. So maybe try it again at some point.

(the main developers left open office to fork it as libre office, after oracle aquired sun and open office with it, but destroyed it and after it was burned and pretty much without contributers, donated the name to the apache foundation, who for reasons unknown to me, do not want to merge again)

About the reaons of the not happening merger between open office and libre office, it might be because of license issues. LibreOffice is with copyleft and OpenOffice switched to dual licence

https://mobile.twitter.com/ApacheOO/status/13164228292026040...

Frustrating.

Please file bugs about these issues at: https://bugs.documentfoundation.org/

(but first search for pre-existing reports about them.)

Also consider donating to the project, and writing relevant people (e.g. Engineering Steering Council?), petitioning them to work on the quality of M1 support.

I'll give it another go and file what I see. I can't recall exactly what problems I ran into, but I remember having trouble with choppy scrolling and some UI elements appearing blurred. But I'll need to play with it again. It was awhile ago. I'm always happy to support a project if I end up using it ;)

I've filed something like... well, probably over 60 bugs related to RTL, Hebrew, and Arabic support (in addition to many others). In my experience, something like... maybe half or so have gotten some traction on them within a year of filing, and many have been completely resolved. Sometimes even quickly.

> Why in the world don't you switch to Libre Office?

As someone who uses LibreOffice to the point that it has displaced MS Office (which is no longer installed on any of my private devices, only work ones), i have to agree that it's the better option of the two.

However, one could make the argument for OpenOffice that it's pretty much stable/finished/dead at this point which also means that it's unlikely to have unexpected breaking changes, or even changes to the UI or anything else: which would be horrible for software like OpenSSL that needs to deal with security related issues and patches, but might be more passable for an office suite, given that the OpenDocument formats aren't changing that much. Of course, since OpenOffice does get some updates, the most severe problems would probably get addressed anyways: https://cwiki.apache.org/confluence/display/OOOUSERS/Release...

Thus, it can be a viable package to just install and forget about, hence it's widespread in some universities that don't have awfully lot of resources to keep LibreOffice installs up to date (and if users learn it, then they'll probably be able to keep those skills relevant for the rest of its lifetime). Of course, one can also make an argument that you can just run an old version of LibreOffice, since the changes aren't that severe.

But its not stable/finished - only dead. The devs just left the project. OO has only been getting sparse bug and security fixes for half a decade now. Security issues stay open for years.

I'd hate to be receiving the bandwidth bill for this... appears to be on Google Cloud, too; ouch.

Extremely cool project and execution but it (hardly) runs on my MBP M1 Pro, 16 GB with FF and a 350mbit/s up-down connection and no other tabs open. Actions (clicking, dragging scrolling) takes a full two seconds to happen... Would have loved to play around with it!

I have the same hardware and was also using Firefox, and I got decent performance (only briefly tried it out though). Maybe it is a settings/extension thing?

For me it gives me this Application exit (TypeError: Cannot convert "undefined" to int)

I think openoffice did something like this before Microsoft did

https://www.zdnet.com/article/browser-based-openoffice-org-r...

Firefox "about:performance" tab shows only 714 KB used by the soffice tab.

How is this possible?

Interesting, since it makes me wonder if it could actually be usable if you stripped out Qt and flattened things "down" to a simpler widget set and rendering engine, but completely unusable on all my machines.

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.

What that means though? A VCL backend that targets HMTL5 instead of Qt?

Can you elaborate?

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.

I’ve been seriously impressed with Tokamak for Swift. Is this what you mean for browser native GUI?

https://github.com/TokamakUI/Tokamak

One small detail I can see which already seems like something that some of us would consider signposts to the insanity of this sort of thing: the version in the browser has no access to your system installed fonts.

UI is really slow. I wish that anyone takes QT or GTK backends for DOM+wasm seriously. More work should be delegated to the UI components. X-Windows was ugly... but there was a clean separation that was useful.

I typed in two words, then tried to copy/paste:

Application exit (RuntimeError: Aborted(Assertion failed: pTrans, at: /home/libo/src/core/vcl/qt5/QtClipboard.cxx,104,getContents))

I had low expectations but that's actually a really nice error message! Well done WASM. No sarcasm.

I got a similar error when I clicked "Print":

Application exit (RuntimeError: Aborted(native code called abort()))

Spell check doesn't seem to work. When I manually trigger one, the Dictionary dropdown doesn't have any options to choose from.

Does LibreOffice expect the OS or Desktop to provide a dict?

Not from OS, it uses opensource library.

Oh man.. Incredible. eBPF, WebAssembly are going to change the software landscape significantly.

Question - if whole office suite can be loaded, I suppose Figma would already be doing WebAssembly?

> Figma would already be doing WebAssembly

Yes, they have been for a while.

This is their article from 2017 talking about it. I can't find any recent ones.

https://www.figma.com/blog/webassembly-cut-figmas-load-time-...

Yes, Figma is mostly C++ compiled to WASM with a bit of react on the side for things like the menu. Basically, all the bits that matter are C++.

> if whole office suite can be loaded, I suppose Figma would already be doing WebAssembly?

Sorry, but out of the loop here. What is the relationship between Figma and WebAssembly? Why would Figma already being doing it?

Application exit (Runtime error: The application has corrupted its heap memory area (address zero)!)

After I opened the file open dialog and then clicked cancel.

This doesn't seem to be working for me in Firefox or Safari on an M1 mac. Has anyone else had any success or is it only working on Chrome?

I'm having intermittent success in Firefox on Linux. It loaded successfully once, but most of the time fails with "Module.instantiateWasm callback failed with error: out of memory" in the console.

I've just tried again in Firefox it it worked surprisingly well this time.

I'm hoping someone will port Firefox or Safari to WebAssembly. For fun, but also it could be useful as a double or triple (etc) sandbox.

Would also be useful for easier compatibility testing.

I don't think Safari and its heavy dependency on macOS will show up on any other platform any time soon.

Firefox and the various WebKit browsers though, those should work. Theoretically they already work, as you can run them in JSLinux (the RISCV version or the Windows 2000 compatible versions), but that's a terribly slow method of running the software.

Qt for WebAssembly: soffice Application exit (TypeError: Cannot convert "undefined" to int)

Safari (current) on MacOS (current) on a Apple M1

Same on iPad. Maybe it has issues with ARM?

I had a similar crash on Intel Mac in Firefox, when clicking File>Save Remote

Safari sadly does not support the required WebAssembly module sizes.

This is a really good technology demonstration. I must admit I still think JSLinux is more impressive.

I wonder how Fabrice Bellard's JSLinux demo would perform if he wrote it on top of WebAssembly.

I pressed the "print" button to see what happens and it crashed :(

My copy/paste stopped working after trying this out.

WASM is not going to happen. Stop pushing it. Also Google Docs, Microsoft and several others have been doing this via JS, since ages.

This also runs in Brave for Android.

Wow, it even has a window manager

Crashes sometimes but works well

I don't like the trend of SAAS apps via webassembly, nor that my browser runs something like an office suite.

It doesn’t work on iPhones…

Didn't work on my Mac using the latest Safari either.

This should be redone in WebGL1 and WASM to be system independent and working on all devices including iOS and Mac.

Sadly saving doesn’t work.

Why? LibreOffice is Free Software and can be run natively on everything.

Cloud software is part of a rental model.

ISTR there used to be an emscripten asm.js version. It'd be lovely to see a comparison how setting them up differs, what kind of glue each required, and how they compare in performance. But I'd only really expect that if the same people were behind both, which ia probably not the case.

isn't libreoffice/star office written in java?

so now we have come full circle with a jvm (via wasm) in browsers again

No, it's written in C++

A great reason not to have Web Assembly.

I agree. Before you know it they'll be creating browsers to run in the browser to run browsers to run browsers in the browsers in the browsers.

On a more serious note, Flatpak and other sandboxing solutions make 100% more sense than using something that already leaks way too much in order to sandbox apps.

How do I run flatpak on iPhone?

You encourage Apple to implement a sandboxing API and a Linux compatibility layer. Even Windows has made progress with WSL.

Fuggedabout it. That would undermine their whole business model. Knowing Apple, I wouldn't be surprised if they remove WASM support from mobile Safari on the grounds that it's "bad for battery life".

I am seriously thinking about creating a silly webpage running Firefox another browser (preferably Firefox). But, my experience with C++ is limited, anyone want to pair up?

Reply on news.ycombinator.com