4 ms·

Once your application is complex and reactive enough, has a certain amount of JavaScript code and gets used by enough people, you will inevitably run into compa

by d3w4s9 3y ago

Once your application is complex and reactive enough, has a certain amount of JavaScript code and gets used by enough people, you will inevitably run into compatibility issues. Then you realize you cannot just rely on a random browser version on any platform and think a minimum wrapper works well. That's why Electron bundles a browser and people create applications targeting specific Electron versions.

synergy20 3y ago
very true, which is why Electronjs still prevails in practice. In the meantime if your WEBUI is not complex, and you just use the common features that all browsers have, this approach might work fine.
Xeamek 3y ago
I've never worked on big enough project to hit such issues. Could you provide some examples? Not that I doubt your claims, just curious
- codelikeawolf 3y ago
  I can provide an example. I work on spaceflight mission planning software that runs in Electron. We're using a lot of cutting edge Web APIs like WebGPU, SharedWorker, OffscreenCanvas, and Atomics. There's no way we would be able to ship something that would reliably work cross-platform if we used the OS's webview or whichever browser they prefer. There's other considerations as well. The biggest advantage Electron provides over other libs that use OS webview (e.g. Tauri) is I can use whichever newer features I want (e.g. CSS nesting) as long as they're supported by whichever version of Chrome Electron ships with. That being said, I get why Electron gets a lot of hate. I've been developing Electron apps professionally for the last 4 years. I can't use VS Code because I'm _accutely_ aware that it's Electron. I think 80% of Electron apps in the wild should probably just run in the browser. If you don't need to do stuff like access the filesystem, spawn processes, or interact with the OS in a way that the browser doesn't provide, you should probably just stick with the web app.
  - Xeamek 3y ago
    Fair example, although from what You are saying it looks more like its about using features that might not yet be available in os webview. But the parent post, as well as 'other stories' I see sometimes talk about using certain, 'frozen', older version to ensure compatibility, essentially stating that new releases break some stuff. So i was more asking about such cases
    - codelikeawolf 3y ago
      > Fair example, although from what You are saying it looks more like its about using features that might not yet be available in os webview. Right, which is what the parent comment explicitly stated about compatibility issues. The issues are with trying to use newer browser features that might not be available in the OS webview. > But the parent post, as well as 'other stories' I see sometimes talk about using certain, 'frozen', older version to ensure compatibility, essentially stating that new releases break some stuff. I'm a little confused here. Are you talking about an older version of the browser or an older version of your application? TC39 and browser vendors go to great lengths to ensure backwards compatibility. I've never had a web app break on a new version of a browser.
  - shellcoders 3y ago
    I don't think the difference between Electron and Webui is the JavaScript thing you are talking about because Electron uses a bounded Chromium browser. Webui uses any installed web browser, so both are the same. True differences: 1 - The big difference is that the Electron backend is ONLY JavaScript, while Webui can be used with any language, C, C++, JavaScript, Zig, Nim, V, Python, Go... 2 - Electron is big, yes, +100MB, but gives you complete control of the window, while Webui is 200Kb, but all it does is run a web browser for you and sends you click events, so you have no control over the window because the browser owns it, not your application. So, Webui is suitable only for quick software development, while "big" projects should use Electron. 3 - Any suggestions?
  - StevePerkins 3y ago
    > I work on spaceflight mission planning software... Yeahhhhhh. The thing is, though, I see two classes of desktop GUI applications: 1. The kind that are simple and casual enough to build around a web-based framework. In which case, I'd rather rely on the system native browser rather than ship my own entire browser in my distributable. Because I'm not doing anything complex enough to worry about cross-compatibility issues, and I'm not concerned about people running my executable 10 years in the future with zero updates. 2. The kind which don't fit the criteria above, and therefore really just ought to be honest-to-God native desktop GUI applications. I'm rather astounded that spaceflight mission planning software doesn't fall under this category. Do you REALLY care about supporting Windows, Mac, and Linux targets? If so, then... why? I would assume that spaceflight would be dramatically more locked-down and spec-targeted. If you do not care about cross-plat, then what's the point of eschewing native frameworks since that's the main reason people go with web-based?
Fire-Dragon-DoL 3y ago
Most of electron apps have compatible website version. A website has the same problem as non electron: the browser is always different, so this doesn't seem that dramatic as a downside

by d3w4s9 3y ago

synergy20 3y ago

very true, which is why Electronjs still prevails in practice. In the meantime if your WEBUI is not complex, and you just use the common features that all browsers have, this approach might work fine.

Xeamek 3y ago

I've never worked on big enough project to hit such issues. Could you provide some examples? Not that I doubt your claims, just curious

codelikeawolf 3y ago
I can provide an example. I work on spaceflight mission planning software that runs in Electron. We're using a lot of cutting edge Web APIs like WebGPU, SharedWorker, OffscreenCanvas, and Atomics. There's no way we would be able to ship something that would reliably work cross-platform if we used the OS's webview or whichever browser they prefer. There's other considerations as well. The biggest advantage Electron provides over other libs that use OS webview (e.g. Tauri) is I can use whichever newer features I want (e.g. CSS nesting) as long as they're supported by whichever version of Chrome Electron ships with. That being said, I get why Electron gets a lot of hate. I've been developing Electron apps professionally for the last 4 years. I can't use VS Code because I'm _accutely_ aware that it's Electron. I think 80% of Electron apps in the wild should probably just run in the browser. If you don't need to do stuff like access the filesystem, spawn processes, or interact with the OS in a way that the browser doesn't provide, you should probably just stick with the web app.
- Xeamek 3y ago
  Fair example, although from what You are saying it looks more like its about using features that might not yet be available in os webview. But the parent post, as well as 'other stories' I see sometimes talk about using certain, 'frozen', older version to ensure compatibility, essentially stating that new releases break some stuff. So i was more asking about such cases
  - codelikeawolf 3y ago
    > Fair example, although from what You are saying it looks more like its about using features that might not yet be available in os webview. Right, which is what the parent comment explicitly stated about compatibility issues. The issues are with trying to use newer browser features that might not be available in the OS webview. > But the parent post, as well as 'other stories' I see sometimes talk about using certain, 'frozen', older version to ensure compatibility, essentially stating that new releases break some stuff. I'm a little confused here. Are you talking about an older version of the browser or an older version of your application? TC39 and browser vendors go to great lengths to ensure backwards compatibility. I've never had a web app break on a new version of a browser.
- shellcoders 3y ago
  I don't think the difference between Electron and Webui is the JavaScript thing you are talking about because Electron uses a bounded Chromium browser. Webui uses any installed web browser, so both are the same. True differences: 1 - The big difference is that the Electron backend is ONLY JavaScript, while Webui can be used with any language, C, C++, JavaScript, Zig, Nim, V, Python, Go... 2 - Electron is big, yes, +100MB, but gives you complete control of the window, while Webui is 200Kb, but all it does is run a web browser for you and sends you click events, so you have no control over the window because the browser owns it, not your application. So, Webui is suitable only for quick software development, while "big" projects should use Electron. 3 - Any suggestions?
- StevePerkins 3y ago
  > I work on spaceflight mission planning software... Yeahhhhhh. The thing is, though, I see two classes of desktop GUI applications: 1. The kind that are simple and casual enough to build around a web-based framework. In which case, I'd rather rely on the system native browser rather than ship my own entire browser in my distributable. Because I'm not doing anything complex enough to worry about cross-compatibility issues, and I'm not concerned about people running my executable 10 years in the future with zero updates. 2. The kind which don't fit the criteria above, and therefore really just ought to be honest-to-God native desktop GUI applications. I'm rather astounded that spaceflight mission planning software doesn't fall under this category. Do you REALLY care about supporting Windows, Mac, and Linux targets? If so, then... why? I would assume that spaceflight would be dramatically more locked-down and spec-targeted. If you do not care about cross-plat, then what's the point of eschewing native frameworks since that's the main reason people go with web-based?

Fire-Dragon-DoL 3y ago

Most of electron apps have compatible website version. A website has the same problem as non electron: the browser is always different, so this doesn't seem that dramatic as a downside