E.g., what if the "desktop" was simply a primary browser window, and if you opened an Electron-style app in it, the app got its own name and icon and separate window.
Visually it would be a traditional desktop, but internally it would be the logical progression of Electron.
Conversation
Progressive Web Apps, Single-Site Browsers, and similar concepts can get you pretty fucking far with that idea, honestly.
2
18
It's a little frustrating that Firefox seems to have outright abandoned both PWA and SSB functionality on the desktop, honestly, given that it does seem to be where desktops are headed.
3
5
23
It's also FirefoxOS. There's been a few attempts.
Quote Tweet
Replying to @duckinator
That's ChromeOS. You're talking about ChromeOS.
5
25
Android, iOS/macOS and now Windows have a proper WebView integrated into the OS with out-of-band updates not depending on the application. It doesn't solve the same problem because these are 3 substantially different APIs. iOS/macOS WebView is also missing a ton of modern APIs.
1
Despite both being Chromium-based, the Android WebView and Windows WebView2 would still require making an abstraction layer and separate code outside the WebView for both platforms. Would be much more painful to also make it portable to iOS/macOS with this approach though.
1
There's no proper equivalent in the Linux world providing a stable API for a sandboxed WebView. Qt and GTK WebView APIs aren't on the same level. They have too many limitations (especially GTK), the APIs are moving targets and the security situation is pretty much horrifying.
2
What is Tauri doing on those platforms? I know they've been working on exposing the various WebViews to Rust. I just know it's a problem folks are working on, seemed good on Windows, maybe naively assumed Linux could sort it.
1
> WebKit on macOS, WebView2 on Windows and WebKitGTK on Linux.
So you get a modern browser engine on Windows, a lackluster one for macOS and the sketchy GTK port of the underlying engine for that on Linux with problematic security. It's not fun dealing with Safari limitations.
1
Part of why people use Electron is they're targeting one consistent modern browser engine. It also provides the modern web developer tooling/debugging support. You'll be missing all that this way. Still a major problem even if the intention is writing all but the UI in Rust.
You can do a whole lot with only a web site without a native app at all if you're only targeting Chromium-based browsers. Add to home screen / desktop turns it into something resembling one, and unlike traditional desktop applications is sandboxed rather than near fully trusted.
1
Perhaps all that's really needed is simply having a nicer way of packaging up web sites as standalone web apps that's more easily discovered and offers offline signing instead of only transport security. There aren't really that many more APIs needed to handle most use cases.
1
1
Show replies



