Will PWAs make Electron obsolete?
Unlikely, because Electron is very useful in exposing system and hardware APIs.
For most apps - wouldn't PWA's be sufficient as implemented today. Presumably, they'll expose more and more hardware APIs over time?
Tauri: An Electron alternative written in Rust
91–100 of 438 posts
Re: Tauri: An Electron alternative written in Rust
#92Earlier quoted context omitted.
> don't have to deal with all the small but time consuming compatibility quirks > Webviews are also a moving target so you need a big testing matrix I say this as a front-end web app dev who would most likely be affected by this kind of shift: it might be slightly less convenient, but I wholeheartedly think it's worth doing, on several levels. People built web apps 15 years ago in the dumpster-fire that was web stand…
> Most of the world was still on IE which was actively hostile to web standards for the sake of lock-in (and users weren't even on the same version of IE!) More like: A lot of corporate users mandated a specific version of IE and wouldn't allow anything else to be installed.
Some corporations did that. Most didn't. The main reason IE dominated was that most people didn't care, and stuck with the default. The main reason old versions of browsers were more common than new ones was that self-updating browsers hadn't become a thing yet, and most people didn't care, and just stuck with the default. The reason most browsers stay up-to-date now is that modern browsers are all configured to self-update by default, and most people don't care, and stick with the default.
I have never bought a prebuilt Windows PC, so this is pure speculation, but I am wildly guessing that the dominance of Chrome is because computers are now coming with Chrome preinstalled and configured as the default, and most people don't care, and just stick with the default.
Re: Tauri: An Electron alternative written in Rust
#93Earlier 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…
> don't have to deal with all the small but time consuming compatibility quirks > Webviews are also a moving target so you need a big testing matrix I say this as a front-end web app dev who would most likely be affected by this kind of shift: it might be slightly less convenient, but I wholeheartedly think it's worth doing, on several levels. People built web apps 15 years ago in the dumpster-fire that was web stand…
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 doubt that they're taking the time to strip out that compatibility, since the only reason to do so would be efficiency and if you're using Electron that's not a priority.
IOW, for many applications, there's a near-100% chance that everything would function with little to no extra work, and for most of the rest it would likely take very little.
Re: Tauri: An Electron alternative written in Rust
#94From the roadmap:
> Go, Nim, Python, C++ and other bindings are possible with the stable API.
I think something like this might actually have a lot of potential, specifically because it's much easier to create bindings for other languages with Rust than with JavaScript.
You're stuck with a NodeJS runtime to run an Electron app, even if you "compile" it. You could theoretically make bindings to another language, but you'd still be dependent on that NodeJS runtime. But this could theoretically be compiled to a relatively lightweight DLL and interfaced with using practically any language you want.
The page logic would still need to be JavaScript, of course, but that's just the nature of webviews for now.
Re: Tauri: An Electron alternative written in Rust
#95Without wanting to attack Tauri's author work in any way, for me, the only sensible alternative to Electron are native webviews and daemons/services talking to the user's installed browsers.
Isn’t that what this is basically?
So if I install a Tauri app I can access it with Firefox?
Re: Tauri: An Electron alternative written in Rust
#96Earlier quoted context omitted.
> don't have to deal with all the small but time consuming compatibility quirks. Good, then developers might start to develop against standards instead of handpicked browsers. Or if they use a future (unstable) standard that is their own headache (as opposed to user’s; which are subsequently in practice forced to use chromium derived browser). An app developed against a single browser (as opposed to the web standard)…
This is about desktop and not web development though. I agree that pages available on the web should be standard compliant and work with all browsers. On the desktop you are developing against a runtime that the developer of the app gets to choose, so why not choose one that has less potential for quirks?
Because then you'll get a more efficient app that people don't constantly complain about?
Especially on macOS, where Chrome/Chromium have historically been extremely inefficient, swapping the Chromium engine for WebKit2 WebViews would mean battery, memory, and CPU savings which would absolutely be worth the effort IMHO.
Re: Tauri: An Electron alternative written in Rust
#97This 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 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 Is this really different from the current state of web development? Front-end developers have to test against Chrome, Firefox, and Safari, at a minimum. For apps that are basically installable websites (like Slack, which has a perfectly functional webapp) this doesn't seem…
Not much different but enough to be dangerous. Older Windows use Trident, 10 still uses EdgeHTML, many people are stuck with old Androids that don't have up to date engines (not sure if Android is a target, wasn't easy to find in their website), and webviews have access to the system in ways a website doesn't (like reading files or using the camera without having to ask for permission or being allowed to issue requests to arbitrary domains).
Re: Tauri: An Electron alternative written in Rust
#98Looks 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…
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…
> A major benefit of Electron is that you can develop against a single browser version and don't have to deal with all the small but time consuming compatibility quirks.
Somehow I doubt the ideal solution is to bundle a web browser with every app. Electron feels like a prototype that went out of control.
Re: Tauri: An Electron alternative written in Rust
#99Earlier quoted context omitted.
I understand your point, however I still think it's unacceptable to have 1-1.5 GB of RAM consumed by simply two Electron applications running idle.
That's not the baseline though, the baseline RAM consumption for an Electron app is about 100MB. If you have garbage code as input it doesn't matter which stack executes it, you'll have garbage performance output.
Even 100MB is crazy. I know RAM is cheap but the absurdity of that amount is beyond me.
Re: Tauri: An Electron alternative written in Rust
#100Earlier quoted context omitted.
This is about desktop and not web development though. I agree that pages available on the web should be standard compliant and work with all browsers. On the desktop you are developing against a runtime that the developer of the app gets to choose, so why not choose one that has less potential for quirks?
Because then you'll get a more efficient app that people don't constantly complain about? Especially on macOS, where Chrome/Chromium have historically been extremely inefficient, swapping the Chromium engine for WebKit2 WebViews would mean battery, memory, and CPU savings which would absolutely be worth the effort IMHO.
Apart from the install size which is still not optimal, it is very much possible to write an efficient Electron app, as evidenced by Discord and Element.
That Slack, the poster child of bad Electron apps performs so badly must therefore have different reasons. Exactly the same way you can write websites in a way that is more or less efficient you can write Electron apps of varying degrees of efficiency.