Isn’t that just the same pig, just wearing different makeup? I’m not a fan of msedgewebview2.exe allocating 500+ MB RAM just because Teams is open, but maybe that’s Teams fault…
Not quite. instead of a bundled pinned version of electron, it is an arbitrary version of edge’s WebKit fork shared across all programs using it. That means you don’t need to keep multiple copies of the webkit libraries loaded into memory.
That’s not to say that building things on web technology is an efficient use of resources. Even if multiple programs are sharing the webview2 library, they’re still dealing with the fundamental performance and memory problems caused by building an app in JavaScript.
As for why teams is so memory hungry? I would blame Teams.
Discord manages to make a half decent, highly responsive webview app, and that’s with the overhead of having its own separate instance of electron.
EDIT: the original poster was also talking about application binary size, not runtime memory consumption. Application binary size should actually be significantly helped by linking webview to instead of bundling electron.
I mean, Object Pascal was doing the “write once, run anywhere” thing decades ago. Java, too. The former, especially, can make very small programs with big features.
Java (and Object Pascal, I’m assuming) have very old-looking UIs. Discord’s gonna have trouble attracting users if their client looks like a billing system from 2005. Also, what do you do about the web client? Implement the UI once in HTML/CSS/JS, and again in JForms?
So if you’re picking one UI to make cross-platform, and you need a web client, do you pick JForms and make it work on the web? or React and make it work on desktop?
I think maybe you’re confused. Java drives a significant percentage of Android apps. It absolutely can do modern UI. I can almost guarantee you’ve interacted with a Java program this year that you never considered.
Java was doing web clients before the web could and still can. I don’t know much about Delphi’s web stuff, but I know they’ve targeted it for years now.
WASM and transpiling blur the lines, too. LVGL can provide beautiful interfaces on the web as well as platforms Electron could never target, and works with any language compatible with the C ABI.
I’m not saying these strategies are without their own warts, but there are other ways to deliver good experiences across platforms with a ~single codebase in a smaller payload. But mostly nobody bothers because they just reach for Electron. It’s this era’s “nobody ever got fired for picking Intel”.
We need more people working with and on alternatives, not just for efficiency but also for the health of the software ecosystem. Google’s browser hegemony is feasting. Complexity has become their moat, preventing a fork from being viable without significant resources. Mozilla is off in a corner consuming itself in desperation.
A US-based company holds a monopoly over the free web and a hell of a lot of our non-web software. So maybe let’s look for ways to avoid feeding the beast, yes? And we can get more efficient software in the process.
Isn’t jfx still actually using HTML and CSS, though? like it’s cool that the UI logic is in Java, but doesn’t using CSS mean you still need to lug a rendering engine around, even if not a whole browser?
Yea, electron has flaws, but it’s basically the only way to make a truly cross platform native and web app. I would rather take a larger installed size and actually have apps that are available everywhere.
The sad truth is there aren’t enough developers to go around to make sleek native apps for every platform, so something that significantly frees dev time is a great real world solution for that.
The alternative is “just serve it as a regular website”. It doesn’t need to be an app to do its job. Name a functionality which only exists in electron but not in the standard browser API.
Fucking Chrome/Electron is why.
I honestly wouldn’t mind that if they could all use the exact same runtime so the apps could be a few MB each, but nooooo.
400mb iphone banking app entered the chat
See: Webview2
Unfortunately, it is extremely painful to work with😔 Enjoy rolling your own script versioning and update systems instead of using squirrel et al
Edit: I think Tauri works by targeting this and webkitgtk via their wrapper library, unfortunately I can’t get my coworkers to write rust
Isn’t that just the same pig, just wearing different makeup? I’m not a fan of msedgewebview2.exe allocating 500+ MB RAM just because Teams is open, but maybe that’s Teams fault…
Not quite. instead of a bundled pinned version of electron, it is an arbitrary version of edge’s WebKit fork shared across all programs using it. That means you don’t need to keep multiple copies of the webkit libraries loaded into memory.
That’s not to say that building things on web technology is an efficient use of resources. Even if multiple programs are sharing the webview2 library, they’re still dealing with the fundamental performance and memory problems caused by building an app in JavaScript.
As for why teams is so memory hungry? I would blame Teams.
Discord manages to make a half decent, highly responsive webview app, and that’s with the overhead of having its own separate instance of electron.
EDIT: the original poster was also talking about application binary size, not runtime memory consumption. Application binary size should actually be significantly helped by linking webview to instead of bundling electron.
Is there any alternatives to electron ? And why people’s doesn’t move on to alternatives if electron is huge & heavy resources ?
I mean, Object Pascal was doing the “write once, run anywhere” thing decades ago. Java, too. The former, especially, can make very small programs with big features.
Java (and Object Pascal, I’m assuming) have very old-looking UIs. Discord’s gonna have trouble attracting users if their client looks like a billing system from 2005. Also, what do you do about the web client? Implement the UI once in HTML/CSS/JS, and again in JForms?
So if you’re picking one UI to make cross-platform, and you need a web client, do you pick JForms and make it work on the web? or React and make it work on desktop?
I think maybe you’re confused. Java drives a significant percentage of Android apps. It absolutely can do modern UI. I can almost guarantee you’ve interacted with a Java program this year that you never considered.
Pascal is more niche, but it can do modern, too.
Java was doing web clients before the web could and still can. I don’t know much about Delphi’s web stuff, but I know they’ve targeted it for years now.
WASM and transpiling blur the lines, too. LVGL can provide beautiful interfaces on the web as well as platforms Electron could never target, and works with any language compatible with the C ABI.
I’m not saying these strategies are without their own warts, but there are other ways to deliver good experiences across platforms with a ~single codebase in a smaller payload. But mostly nobody bothers because they just reach for Electron. It’s this era’s “nobody ever got fired for picking Intel”.
We need more people working with and on alternatives, not just for efficiency but also for the health of the software ecosystem. Google’s browser hegemony is feasting. Complexity has become their moat, preventing a fork from being viable without significant resources. Mozilla is off in a corner consuming itself in desperation.
A US-based company holds a monopoly over the free web and a hell of a lot of our non-web software. So maybe let’s look for ways to avoid feeding the beast, yes? And we can get more efficient software in the process.
Isn’t jfx still actually using HTML and CSS, though? like it’s cool that the UI logic is in Java, but doesn’t using CSS mean you still need to lug a rendering engine around, even if not a whole browser?
Yea, electron has flaws, but it’s basically the only way to make a truly cross platform native and web app. I would rather take a larger installed size and actually have apps that are available everywhere.
The sad truth is there aren’t enough developers to go around to make sleek native apps for every platform, so something that significantly frees dev time is a great real world solution for that.
The alternative is “just serve it as a regular website”. It doesn’t need to be an app to do its job. Name a functionality which only exists in electron but not in the standard browser API.