this post was submitted on 21 Mar 2025
1478 points (98.4% liked)

Programmer Humor

21809 readers
1844 users here now

Welcome to Programmer Humor!

This is a place where you can post jokes, memes, humor, etc. related to programming!

For sharing awful code theres also Programming Horror.

Rules

founded 2 years ago
MODERATORS
 
you are viewing a single comment's thread
view the rest of the comments
[–] Blackmist@feddit.uk 85 points 1 day ago (3 children)

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.

[–] nutt_goblin@lemmy.world 23 points 1 day ago* (last edited 1 day ago) (1 children)

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

[–] kungen@feddit.nu 6 points 1 day ago (1 children)

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...

[–] nutt_goblin@lemmy.world 4 points 20 hours ago* (last edited 20 hours ago)

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.

[–] rarbg@lemmy.zip 14 points 1 day ago

400mb iphone banking app entered the chat

[–] devilish666@lemmy.world 5 points 1 day ago (2 children)

Is there any alternatives to electron ? And why people's doesn't move on to alternatives if electron is huge & heavy resources ?

[–] dpflug@kbin.earth 12 points 1 day ago (1 children)

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.

[–] uuldika@lemmy.ml 0 points 1 day ago (2 children)

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?

[–] dpflug@kbin.earth 6 points 1 day ago (1 children)

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.

[–] uuldika@lemmy.ml 1 points 16 hours ago

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?

[–] Takumidesh@lemmy.world 2 points 1 day ago* (last edited 1 day ago)

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.

[–] dbx12@programming.dev 6 points 1 day ago

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.