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.
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?
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
> 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.
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.
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.
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.
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.
... 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.
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.
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.
> 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.
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 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?
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.
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,
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.
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.
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.
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.
> "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".
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.
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.
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.
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.
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.
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.
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.
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.
> 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…
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.
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).
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.)
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?
"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.
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.
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?
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.
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
(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.
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?
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.
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.
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'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 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.
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.
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.
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?
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".
Here's the related video from FOSDEM: https://fosdem.org/2022/schedule/event/lotech_lowa/