Experimental WebAssembly port of LibreOffice released Almost exactly a year after we last covered it, an experimental version of LibreOffice compiled to WebAssembly (nicknamed LOWA) has appeared. Be warned, it's about 300MB, so it takes a while to load, but you can try it here in your browser. It's based on the still-prototype LibreOffice 7.4 codebase and is not yet ready for …
Such a sad sad day when people seriously consider this.
It's grossly inefficient. Modern day web browsers are as large as operating systems in complexity, but with vastly more resource requirements.
Libre office was meant to be written in Java making it portable anyway. But this fails to run in Safari, so I assume I have to use Chrome.
Similarly on FreeBSD in Firefox. First thing I did after it eventually loaded was click on the file menu. Saw the printer setup option and though, Oooh, wonder if it'll find my printer?...and it crashed. But not after sucking up all my available RAM and starting on the swap space while running the CPU at 100%.
Now, this isn't a fast or well endowed laptop I'm using ATM, but I think that's the first time something grabbed ALL RAM and CPU at the same time. I might look at it again when they claim it's production ready.
It's better compared to ignoring the error, letting you work happily, and then doing something horrible five hours later (e.g. crashing without saving) because that ignored error had consequences.
JavaScript's cavalier attitude to casting means that if you make some trivial mistake (e.g. use the wrong variable in an arithmetical operation), the symptom you actually get is something that happens 500 lines of code away, in a block of code that has nothing to do with the actual problem and is only guilty of receiving bad input. That's extremely annoying to debug, and ten times worse if it's someone else's code (so that you have no idea where that bad input actually comes from). I've had instances of that where it took me half a day to track down the real issue.
In most other languages, if you make that class of mistake, the code either won't build, or it will fail at exactly that spot. The time to fix is measured in seconds.
To be fair, it's still experimental according to the article, not even in beta yet. I wouldn't expect a smooth experience.
Safari uses WebKit which is known to be quite far behind Gecko and Chromium when it comes to support for the latest JavaScript functions, which I'd expect WASM to make use of. It will likely take some time to smooth out these issues.
Personally I have no interest in a web-based office suite, or indeed most web apps, but I can how they could be useful for others, so I see this as a good thing overall. I'd also hope it loads quicker on future visits as the components will hopefully be cached.
Just tried it in Firefox on Windows, seems to work.
But it's sloooowwwww. The inefficiency of this approach is blatant. We've had fast WYSIWYG word processors as far back as the mid 1990s. Managing make one this sluggish in 2022 on modern-ish hardware is quite an accomplishment.
I don't suppose the LibreOffice project for one moment imagines this becoming their mainstream. It's an interesting thing to do, and from the bits that don't work I suspect that it's been done largely because it was easy to build. But it is a good example of why apps shouldn't be built this way.
How about the mid 1980's or even earlier? Even the humble Amstrad 8080 powered all in one had a WYSIWYG editor. Maybe this was all from before you were born?
DEC had the WPS-8 (powered by a PDP-8) workstation with twin floppies and had a decent editor.
Otherwise, your comment about 'apps shouldn't be built this way' is perfect.
Shame that it will fall on deaf ears with the power brokers in the USA.
If you want to trace the heritage of LibreOffice it goes StarOffice -> OpenOffice -> LibreOffice. All of them were primarily written in C and C++.
Under Sun/Oracle's stewardship Java was used for chunks of functionality like a database engine and some extensions. But it was criticized for it and there has been a concerted effort ever since to strip it out. I image some day it might actually happen. This isn't a slight on Java btw, it's just that LibreOffice has a larger memory footprint for stuff on the periphery and it is an obvious performance win if it can be removed.
Secondly, and emphatically, WebAssembly is not "grossly inefficient". It's a specification. It describes a binary format & assembly language and how it is packaged. Implementations are capable of compiling and caching that code and running it at near-native speeds, WAY faster and in a more integrated way than any JVM could ever. That isn't to say they *do* that at this time but that potential is there.
Also, need it be pointed out why WebAssembly exists as a thing? Look at efforts like PNaCl and asm.js to understand why all browsers have embraced it.
There is an energy sustainability table for AWS showing each language in terms of performance & memory footprint and extrapolated sustainability. Java is 2x as bad as native code. JavaScript is even worse 4.5x. Ruby & Python are horrifically bad - 70x worse.
So JIT & Hotspot are never going to get near native performance. WebAssembly does have a theoretical performance of "near native" - i.e machine translated machine code with some sandbox checks.
It's not near native at this time simply because wasm is called from JS and that is a bottleneck. Inside of wasm it's 4x the performance of JS in most browsers, give or take, but the JS interop (i.e. how often you call in or out of the wasm) slows it down. I expect future versions of the spec will attempt to allow wasm more direct access to its environment - DOM bindings for example.
"Also, need it be pointed out why WebAssembly exists as a thing? Look at efforts like PNaCl and asm.js to understand why all browsers have embraced it."
Because it's good at forcing advertising on people who have absolutely no interest in the product being advertised, all the while extracting as much personal information from that person as possible?
> Secondly, and emphatically, WebAssembly is not "grossly inefficient"
I can only assume you're trying to be correct by being as narrow and pedantic as possible in the consideration of 'WebAssembly' by itself.
Every single person that's tried this particular example - which ostensibly consists of probably the highest ever ratio of pure WebAssembly to any other kind of code - has observed that it's glacially slow and uses truly stratospheric amounts of RAM.
You're trying to argue that something isn't grossly inefficient, right next to a great demonstration of that thing being, emphatically, grossly inefficient.
@Andrew Hodgkinson
This is an early experiment by the LibreOffice people where I'm sure they haven't rewritten their huge codebase for optimal WebAssembly, but have lifted and shifted the existing code in, with adaptations here and there. Of course it's going to be slow, it's not supposed to be a new ready to go productivity tool. WebAssemby itself is still a work in progress. They are just experimenting.
Ridiculous expectations.
If I code something using rust, specifically for WebAssembly, keeping the bulk of the work inside the process without too much handing over to JS, then it's nothing like "grossly inefficient". It's by far the most efficient way to do it in a browser.The ratio of actual webassembly code to JS code is irrelevant, it's the amount that each of those is called into use that matters.
As as already been explained, WASM currently relies on JS for DOM interaction and has a clunky method to hand over in memory pigeon holes. When this is addressed that bottleneck will be reduced.
I think it's important to realise that WASM and JVM (or .Net) are rather different things. WASM is a type of virtual machine code: it has a limited set of data types and operations that correspond to commonly-available hardware instructions. The JVM has access to the high-level type information and other metadata associated with the source code: this is how frameworks can wire up code to events and do dependency injection (for example). There's no reason you can't do that on top of WASM, but you can't do it with WASM alone.
That said, the LibreOffice demo is quite impressive - once it loads. A lot of the heavy lifting is done by QT for WebAssembly and the general performance of the UI is considerably better than I was expecting.
That said, it raises some interesting questions about WASM - about multi-threading and its relationship to other browser activity, about rendering and about the communication between WASM "components" and other DOM objects. And of course, about GUIs in general: desktop UIs that assume a high-precision pointer and a display that can represent the width of a standard sheet of paper are not a particularly good fit for today's devices.
Its annoying that WASM is even necessary. Netscape (IIRC) offered a Javascript2 with proper classes and inheritance over 20 years ago. I installed it into my browser (god that was a challenge!) and wrote basically a desktop gui in a few hours with SVG on steroids. As I understand it MS and Apple stopped it becoming part of the official standard.
By "javascript 2" I think you mean the original draft of ECMAScript 4 which was basically a kitchen sink spec which included classes. It transformed JS from basically scripting glue into a more general purpose language. It was canned because some committee members including Microsoft were concerned it was too complex to actually implement and stuck to their guns.
Anyway the issue now is not whether JavaScript has classes or not. Either way the runtime performance would still suck. That's simply due to JS being a high level language with garbage collection and dynamic typing. No amount of optimization would make it run at native speeds. Browsers have been down this road trying to get the performance better, even going so far as to produce an optimized asm.js subset.
This is why the browsers (and NodeJS) have gotten behind WebAssembly. It is not encumbered in the same way JS is so it has far more potential to run code close to native speeds.
Lets face it, its all going to use used to run even more annoying adverts, so I would rather it does not even exist.
The more we blur the desktop and web the harder it will be to unpick adverts from daily life infesting everything we look at in the electronic world and also the web is now all about subscriptions in terms of monetisation in the form of repeating cash flows. a.k.a rent seeking, which Adam Smith had pretty negative views on in an economy.
You will own nothing and be happy.
(trying again as forums seem to be broken)
Lets face it, its all going to use used to run even more annoying adverts, so I would rather it does not even exist.
The more we blur the desktop and web the harder it will be to unpick adverts from daily life infesting everything we look at in the electronic world and also the web is now all about subscriptions in terms of monetisation in the form of repeating cash flows. a.k.a rent seeking, which Adam Smith had pretty negative views on in an economy.
You will own nothing and be happy.
After several minutes of "Downloading/Compiling...", it failed with "TypeError: Body has already been consumed."
This is on bone-stock Slackware 14.2-stable ... might try it on Slack 15.0 tomorrow, if I can be arsed. Probably not.
Yes, I know what the error message means.
It is a very nice demonstration of what is possible. Whether it is necessary, that is a different question. Native versions have definitely advantages in speed and versatility, but will therefore also open up for larger security holes. Still very nice.
That said, what I have been missing is a (simple) multi-user online version of libreoffice. An easy collaboration suite that a) does not require third party logins, b) does not send data to the tech overlords for ads or other nefarious/questionable purpose and c) is independent in choosing where the storage is located. Something I can install on my own server and can create my own circle of access. Paramount is the multi-user part, where documents are accessed simultaneously by the users. No need to do too fancy formatting. Final formatting is a one-man job anyway and can be done in a local LO copy.
I'm surprised why they decided to do this, since they have ported the software to the three major desktop operating systems anyway it would be less work just to improve collaboration features and give it the ability to point it to your own server.
Well I guess its been done because MS Office has a web version and if LO is aiming to be a replacement for Microsoft Office then it should have broadly the same features as its proprietary counterpart. As perhaps for an organisation looking to move away from MS office to Libreoffice, the lack of a online LO client might be a deal breaker?
There is Collabora, which works alongside NextCloud. Sort of.
I tried it, and ended up getting a copy of Microsoft Office Online Server to run alongside my NextCloud.
It requires more administration attention than everything else I have put together, and I have a powershell script that uninstalls and re-installs it everytime the server reboots to stop the thing from breaking, but I still find it preferable to Collabora in its current state.
" Paramount is the multi-user part, where documents are accessed simultaneously by the users. No need to do too fancy formatting. Final formatting is a one-man job anyway and can be done in a local LO copy."
I wonder how the practicalities of that work out. If two people want to express the same thing differently somebody's going to have to arbitrate.
Maybe an alternative approach would be to save the working text in a flatter format - maybe .fodt or .md - managed with Git so the final (human) editor does the merging and formatting.
I have one use-case in mind. Classroom projects where you want collaboration on notes and reports. Projects benefit from collaboration if you can structure them consistently (where consistency is a goal in teaching). The advanced formatting is not required while multiple work on the content.
You must see such document as a collective mind and forum for support in collaboration. The final typeset report format is a relatively small part of the actual work. The content and information hierarchy is important.
Using text documents and f.x.git is possible only if you have clear sub-projects and a clear conflict and merge strategy. However, it is a pain embedding pictures/graphs this way. The use-case for (traditional) revision-systems is a programmatic construct in the project (not necessarily a program, but the same development model).
I think an office suite would be the wrong tool. What happens if two people try to edit the same passage at the same time? You'd need to have locks on selections or on the current location of everyone's cursor (think one one person doing character by character deletions while someone else is trying to type there). It would end up more like a transactional database at the back end with an HTML generating front end....
Hold on there. That's a Wiki. That's what you need. Then you can typeset the result.
But, that is exactly what google docs originally solved already. The problem is "google" in the docs!
A wiki is not the right tool. Tried it and failed miserably.
The collaboration factor means instantaneous and multi-user interaction. Like a black-/white-board. The advantage and added value of using a computer in this setting is that you have documentation of work, which can be used to build upon. You use the computer plus software to support (instantaneous) collaborative incremental development of ideas, research, analysis, execution and its documentation. That is what you want to do without google, microsoft, apple or any other corporation. This needs to be done in a safe environment without others peering into your work and try to fuck your bubble-future for what you wrote ages ago.
Yes, Etherpad is a good idea. However, it does not work "out of the box". Installing Etherpad is quite a steep and high mountain. It is a very interesting project but lacks user/sysadmin oriented packaging, configuration and maintenance.
Etherpad, like many projects, suffers from developer installation syndrome. It is assumed that you have the time and interest to do a deep dive into intricate details stemming from development that should not matter for the normal sysadmin and user who just want the functionality. Most documentation and configuration information is available, but it is not accessible for non-developers (I really do not want to read the source code to find out why something does not work [as expected]).
Sounds like the sort of thing you can do with a Synolgy desktop NAS. I think they have a collaboration suite called Office or something which might suit your needs. Docs are stored in a proprietry format but can be exported to ODF/MS formats if needed.
I had a look at it briefly and never really used it in anger, but it looked reasonably good.
"Paramount is the multi-user part, where documents are accessed simultaneously by the users."
Why in all the levels of hell known to the collective psyche of systems administrators world-wide would anyone want a clusterfuck like that for a common office suite? People can't/won't agree to something as simple as when to have a fucking meeting ... do you really think they'll agree on the final format of something as personal as a document or spreadsheet?
Beware of what you ask for ... tinkerers abound.
I think multi-user editing is fine at an /early/ stage, so that the multi-tude can throw in remarks, add paragraphs, subsections, or whatever according to their own interests or responsibilities. The ghastly -- but hopefully fairly complete -- soup could then be cleaned up by one chosen author, with comments (but not editting) by the others.
Although now sometime in the past, I'm still scarred by the time both I and my phd supervisor made significant, in parallel, and notationally incompatible changes to a reasonably advanced latex document. The resulting manual merging process was not very fun. So now, apart from any early "soup" stages that might arise from using (eg) overleaf, I tend to either take control of a manuscript, or stand back and make comments while someone else does.
I'm very picky who I might send any latex files to. I use a system of line breaks and indents to keep it readable (especially for equations), and allow useful diffs between versions. This is frequently mangled by the editors of others, which usually either insist on re-formatting lines so they have similar lengths, or turn each paragraph into one long unbroken line.
How well a human collaboration works depends on who you're working with, and their mindset and intellectual compatibility -- regardless of the tools used.
I once tried collaborating with a good friend on writing program documentation; it was slow, aggravating, and we just gave up. We were doing it verbally in a closed office. When we agreed on wording, he typed the agreed-upon sentence on the electric typewriter. The collaboration (not the typing) was difficult because of our different "views" of the English language (U.S. English was the first language for both of us).
A different, seven-person programming project I was on felt effortless. We collaborated on the design on a chalkboard, each taking turns as needed, and never "butted heads". We were just damn lucky we all naturally synced. The group was five men and two women, all with similar programming skill levels.
Given the popularity and widespread support for WASM, there's a distinct possibility that it may yet supplant the JVM as the standard runtime for cross-platform apps.
Can you imagine the truly great mutually beneficial advantage delivered to both if they even just complemented each other, or is the notion of two together similarly leading in differing common and uncommon directions being better than one pioneering novel paths unilaterally, too unusual to realise is much more difficult to obstruct and hinder/prevent and oppose with a disengaging competition or newly created foe.
Took about 5 seconds on a FTH connection, after which I was greeted by a User Interface that looked like it had been designed by a 5 year old with crayons.
I internally screamed in pain at the sight of it.
It took me less than 5 seconds to close it, hoping to erase its image from my mind.
Fired up the URL, inspected the network and watched just how slowly 300MB "streamed" in - I say "streamed" as somewhat of a joke.
After 3 minutes of watching, on a connection that gets 60mbps, seeing it had loaded just 80MB ... this is ... ridiculous.
This is a concept trying to find a problem that isn't actually there.
Sure, we all know using Google docs etc., means you are paying the price with your privacy to some extent, but it loads pretty much instantly and is exceptionally powerful.
This, on the other hand, is DOA - it's a stupid idea for anything other than some kind of weird "can we do this?" reasoning - totally stupid.
""Can we do this" is the starting point for a lot of good things that less inquisitive folk would never find."
It's also the start of many a trip to the ER (A&E, CD, CW ... ). Or the Morgue.
"Can we?" should always be paired with "Should we?".
Cost/benefit analysis isn't just for Finance.
Can I jump The Strid? Hold my beer!
1) And the concept is flawed.
2) Shotgun shells will become so cheap, we'll all use them for swatting mosquitoes!
3) Theoretically, assuming infinite cache size that never gets flushed.
Yes, I'm thinking about how small MY resources are when compared to those of a multi-billion dollar global advertising company.
Just clicked the link from the Reg article, and it span up an apparently working program in rather less than a minute. With caching, I expect subsequent loads to be rather quicker.
I'm not suggesting that this is good or even acceptable, just that my experience has been, so far, rather different from some others reported here. It probably helps that I'm on a 300Mbps fibre link, but that's standard fayre here in Andorra. Could pay a little more and have 700Mbps.
I fear that some of the BTL contributors might be suffering from BT taking the piss.
-A.
I'm getting a message in FF that this page is slowing down FF. to speed up your browser, stop this page! Brave choked on it and closed the window... Safari immediately threw an error that the page had to be reloaded? Even after closing the windows and tabs my system is still groggy, like me on Sunday morning!
Disclaimer, this is an old macmini with only 4 gigs of ram running the aging Catalina.
I can only think of one use case: let's run LO in the browser because we can. For any use case involving editing a file on a remote server there are better solutions,
If only port 80 is open on the firewall Own/NextCloud will let you edit locally and manually upload through the browser. You can cut out the browser by using the O/NC desktop client to sync selected local directories with the remote. If you don't want to have the file local at all both LibreOffice and, AFAIK, MS Office have Open Remote available through WebDav. It's a while since I tried this on LO and memory says it was a bit of a faff; that might be because I didn't use it enough but no doubt it would be easier to make it a bit slicker than to get this idea working.
If SSH is also available use X over SSH to run an X-server locally and LO on the remote. An X server was the first use case I had for Windows? Is it still possible to get one?
Being a glutton for punishment I just tried this on my newly created Acer ES 15 Frankenbook. Really slow!! Was hoping I could install it similar to a PWA but it downloads / compiles at each use even when "installed" as a Shortcut, so not remotely practical. Looks pretty horrible compared to a native LibreOffice. Oh well...
I hope we can all agree that running LibreOffice in a browser with WASM doesn't even serve a ephemeral purpose like climbing Mount Everest which at least gives you an amazing view and experiences to (fondly) look back on.
Running desktop apps in browsers via WASM is an unarguably worse experience than just installing and running the desktop version. I know people like to use e.g. Google's online 'office suite', but that is also a good example of the compromises it takes to make it a half-way appetising experience.
Yeah, pretty sure I'm happy enough just running LO 7.x natively :)
It took about 20 seconds to load, and it "just worked". There was a slight delay. Enough to be noticeable, but not enough to get in the way of using it. As a bit of a showpiece, I thought it was rather impressive. Although I'd still pick Collabora Online, perhaps unsurprisingly.
Anyone else thinking that WASM is starting to look like the new ActiveX? I'm just waiting for the security holes to all be found, followed by the panicked mass of "how to disable webassembly" posts, Vivaldi and Brave disabling it by default, and Norton releasing a wasm blocker*...
(Devil icon because I'm being part serious, part sarcastic)
* one that doesn't block their own crypto miner, natch...
From above---
"600/12/0
A 600 MB "word processor" with 12 years worth of bugs, and zero Office compatibility. Fantastic.
"Experimental WebAssembly port of LibreOffice released"
"TRY IT IN YOUR BROWSER"
No.
2 thumbs down "
And then, further down, a comment in support of this, gets up-voted.
The smooth-brained asshole fanboys don't have enough sense to be consistent, let alone utilize anything approaching critical-thinking skills. And, as always, provide us with an almost limitless amount of entertainment.
Keep those down-votes coming, you brain-dead jerks idiots.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
