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.
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.
Is there any alternatives to electron ? And why people’s doesn’t move on to alternatives if electron is huge & heavy resources ?
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.
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.