4 ms·

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, SharedW

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?
- codelikeawolf 3y ago
  > 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. Our team is very small, so we don't have the budget or resources to make a native version for each platform. I think this is why most companies go with Electron. The browser/Web APIs abstract a lot of the platform-specific stuff away (at the cost of missing some functionality), which means you can run pretty lean. > Do you REALLY care about supporting Windows, Mac, and Linux targets? If so, then... why? Yes, we really do care. The current version of our software only runs on Windows, just like our main competitor. We're trying to appeal to a wider audience, such as aerospace grads, most of which use MacBooks. We really only have one competitor and are pretty close to having feature parity with their product, so the ability to run our software on 3 platforms is going to be a pretty big feather in our cap. > I would assume that spaceflight would be dramatically more locked-down and spec-targeted To some extent, yes, but probably not as much as you might think.
  - 59nadir 3y ago
    > We're trying to appeal to a wider audience, such as aerospace grads, most of which use MacBooks. Is this actually the case? MacOS is in a distinct minority position in desktop/laptop usage as well as areas where people (erroneously) assume it has a significant market share, such as for developers.

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?

codelikeawolf 3y ago
> 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. Our team is very small, so we don't have the budget or resources to make a native version for each platform. I think this is why most companies go with Electron. The browser/Web APIs abstract a lot of the platform-specific stuff away (at the cost of missing some functionality), which means you can run pretty lean. > Do you REALLY care about supporting Windows, Mac, and Linux targets? If so, then... why? Yes, we really do care. The current version of our software only runs on Windows, just like our main competitor. We're trying to appeal to a wider audience, such as aerospace grads, most of which use MacBooks. We really only have one competitor and are pretty close to having feature parity with their product, so the ability to run our software on 3 platforms is going to be a pretty big feather in our cap. > I would assume that spaceflight would be dramatically more locked-down and spec-targeted To some extent, yes, but probably not as much as you might think.
- 59nadir 3y ago
  > We're trying to appeal to a wider audience, such as aerospace grads, most of which use MacBooks. Is this actually the case? MacOS is in a distinct minority position in desktop/laptop usage as well as areas where people (erroneously) assume it has a significant market share, such as for developers.