201–210 of 438 posts
Will PWAs make Electron obsolete?
On electron you get closer to native apps in terms of network and OS access so I believe the PWA are and Electron are quite different platforms.Why doesn't Electron debundle itself into the Runtime vs Application? Much like .Net Runtime. Electron can then be installed in a single spot in the system and all Electron apps pick it up from that spot. You can install bundle the Electron Runtime in the installer (200mb installer is no biggie for a desktop app) but you get all the benefits of consolidating RAM usage across.
Looks like it uses system webviews instead of bundling a copy of Chromium? This to me seems like the real headlining feature, but strangely I had to dig pretty deep to find it: https://tauri.studio/en/docs/getting-started/technical-detai... I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. Interesting thing I just thought about: since users d…
This kind of makes me think... is there room for a much more stripped down version of Chromium that is suitable for lower memory footprint? Or is this impossible? It looks like Tauri uses system webviews, which use a lot less memory, but the burden is then on the developer to make sure that they build essentially 3 (maybe more) UI's on platforms that might change under their feet. That's why the Electron approach is…
> The goal of the Kaleido project is to make static image export of web-based visualization libraries as universally available and reliable as it is in matplotlib and ggplot2.
> To accomplish this goal, Kaleido introduces a new approach. The core of Kaleido is a standalone C++ application that embeds the open-source Chromium browser as a library. This architecture allows Kaleido to communicate with the Chromium browser engine using the C++ API rather than requiring a local network connection. A thin Python wrapper runs the Kaleido C++ application as a subprocess and communicates with it by writing image export requests to standard-in and retrieving results by reading from standard-out.
> By compiling Chromium as a library, we have a degree of control over what is included in the Chromium build. In particular, on Linux we can build Chromium in headless mode which eliminates a large number of runtime dependencies, including the audio, video, GUI toolkit, screensaver, and X11 dependencies mentioned above. The remaining dependencies can then be bundled with the library, making it possible to run Kaleido in minimal Linux environments with no additional dependencies required. In this way, Kaleido can be distributed as a self-contained library that plays a similar role to a matplotlib backend.
1. https://medium.com/plotly/introducing-kaleido-b03c4b7b1d81
Why doesn't Electron debundle itself into the Runtime vs Application? Much like .Net Runtime. Electron can then be installed in a single spot in the system and all Electron apps pick it up from that spot. You can install bundle the Electron Runtime in the installer (200mb installer is no biggie for a desktop app) but you get all the benefits of consolidating RAM usage across.
Sure, there are apps that get updated regularly, but not of all of them are like that, for example some company could implement some internal tool that doesnt have to get updated for years and runtime updates would present a risk with no benefit.
Earlier quoted context omitted.
Also: a lot of our "Electron" apps are essentially Electron frontends to the existing web frontend. For example, Slack-the-Electron-app and Slack-the-web-app are fundamentally identical, aside from likely some platform integration features and so on. That means that, likely, a lot of these Electron apps would already work in, for example, a Safari or Edge webview, since the web version has to anyway. I sincerely doub…
Slack originally was platform specific webviews, and migrated to avoid issues like what is mentioned in this thread. One of the engineers who did it has even commented on HN to explain this.
Earlier quoted context omitted.
A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks. On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well. This is not so significant if your app…
But why would the system webview be less resource hungry? If it runs in an own process instance, the only memory you safe is (maybe) the executable code (i.e. maybe 100MB max). Or you would need some common runtime which is shared across the OS, and somehow use IPC to it. Then you can potentially save some more memory. But I don't think this exists. And I'm also not sure how much you really would save. The advantage…
Looks like it uses system webviews instead of bundling a copy of Chromium? This to me seems like the real headlining feature, but strangely I had to dig pretty deep to find it: https://tauri.studio/en/docs/getting-started/technical-detai... I kind of wonder why it took this long for someone to try this approach. It just makes a whole lot more sense on the surface. Interesting thing I just thought about: since users d…
I believe there are dozens of projects using Webview and market themselves as a lightweight "Electron". The development for these apps takes longer (as you need to test for different webview versions/vendors) and the end product is worse as some features are shimmed or you just choose to not support them due the effort required. Of course this depends by project.
I've developed a media player and considered webview. Soon enough I've found the limitations of safari, ie webview and even firefox webview on audio/video codecs is a blocker. Next was indexeddb and some random performance issues. It didn't took long to realise that it's hard to compete with native apps using Electron but its even harder using different webview versions.
Earlier quoted context omitted.
A major benefit of Electron is that you can develop against a single browser and runtime version and don't have to deal with all the small but time consuming compatibility quirks. On Windows the default webview engine is still not the new Chromium but old Edge (WebView2 has to be installed separately), Safari has a fair amount of issues and gtk-webkit can be very quirky as well. This is not so significant if your app…
I wonder if it would make sense for Tauri to support shipping a bundled webview engine for platforms where the native webview is outdated or otherwise problematic for your application? With the idea that you could eventually migrate to system webviews. That way, you're building with cross-platform in mind but still have the option to pick a stable target if you need it, compared to solutions like Electron where you d…
I guess you can ship an electron version for these platforms where native webview sucks. Chances are that once you do the electron app you start doubting the benefits of shipping a webview based app.