3 ms·

Yes, this is the thing. The option isn't electron vs native, it's electron vs nothing.

by fooey 7y ago

leadingthenet 7y ago
Often, nothing is better than the Electron equivalent. Case in point, if I run Slack in Safari, it runs better than the electron version. Functionally, it’s identical, except the scrolling is now native and feels a bit better integrated in macOS. So what’s the point?
- wutbrodo 7y ago
  I work on AVs, so we have incredibly beefy workstations: I've never managed to make my workstation seize up, even when building and running the full AV stack. Somehow, all of my coworkers who use native Slack have developed the reflex of killing and restarting the application whenever their workstation hangs. It's beyond me why they continue to use it. (That isn't to say that the web version of Slack isn't horribly engineered too, but it poses far less of a problem)
ldh 7y ago
The option is native vs. electron vs. a regular web app. There's rarely any reason you need your web app to live in a dedicated Chrome instance without a URL bar.
Seirdy 7y ago
There is literally no reason to distribute an electron app when you could simply run it as a web server using `npm start` and navigate to `http://localhost:[port http://localhost:[port number]`. Electron is born out of a misplaced notion that some apps are "special" and deserve a certain extra percentage of the users' CPU cycles and battery life for a spot in a user's system tray. 10% of a user's battery life multiplied by all their electron apps is not worth it when alternatives (like starting a web server and launching the users' preferred browser) exist.
- imtringued 7y ago
  I once used this pattern and implemented the webserver using C++. It was quite interesting that I could read gigabytes worth of files and run a sqlite database in the same process and still not exceed 3MB of RAM. Of course the tab in the browser used a lot more RAM (maybe 25MB) but browsers can suspend or simply close tabs. With regular applications the GUI would always be loaded in memory.
- imtringued 7y ago
  I once used this pattern and implemented the webserver using C++. It was quite interesting that I could read gigabytes worth of files and run a sqlite database in the same process and still not exceed 3MB of RAM. Of course the tab in the browser used a lot more RAM (maybe 25MB) but browsers can suspend or simply close tabs. With regular applications the GUI would always be loaded in memory. The reason why this pattern isn't used more commonly is the fact that right now web browsers simply aren't designed to be used this way unless you start a new instance for just a single app. The second reason is that electron developers are lazy. They only want to test a single browser (or browser version) and are perfectly happy that this means Google can get away with shady things.

Yes, this is the thing. The option isn't electron vs native, it's electron vs nothing.

by fooey 7y ago

Yes, this is the thing. The option isn't electron vs native, it's electron vs nothing.

Often, nothing is better than the Electron equivalent. Case in point, if I run Slack in Safari, it runs better than the electron version. Functionally, it’s identical, except the scrolling is now native and feels a bit better integrated in macOS. So what’s the point?

wutbrodo 7y ago
I work on AVs, so we have incredibly beefy workstations: I've never managed to make my workstation seize up, even when building and running the full AV stack. Somehow, all of my coworkers who use native Slack have developed the reflex of killing and restarting the application whenever their workstation hangs. It's beyond me why they continue to use it. (That isn't to say that the web version of Slack isn't horribly engineered too, but it poses far less of a problem)

ldh 7y ago

The option is native vs. electron vs. a regular web app. There's rarely any reason you need your web app to live in a dedicated Chrome instance without a URL bar.

Seirdy 7y ago

There is literally no reason to distribute an electron app when you could simply run it as a web server using `npm start` and navigate to `http://localhost:[port http://localhost:[port number]`. Electron is born out of a misplaced notion that some apps are "special" and deserve a certain extra percentage of the users' CPU cycles and battery life for a spot in a user's system tray. 10% of a user's battery life multiplied by all their electron apps is not worth it when alternatives (like starting a web server and launching the users' preferred browser) exist.

imtringued 7y ago
I once used this pattern and implemented the webserver using C++. It was quite interesting that I could read gigabytes worth of files and run a sqlite database in the same process and still not exceed 3MB of RAM. Of course the tab in the browser used a lot more RAM (maybe 25MB) but browsers can suspend or simply close tabs. With regular applications the GUI would always be loaded in memory.
imtringued 7y ago
I once used this pattern and implemented the webserver using C++. It was quite interesting that I could read gigabytes worth of files and run a sqlite database in the same process and still not exceed 3MB of RAM. Of course the tab in the browser used a lot more RAM (maybe 25MB) but browsers can suspend or simply close tabs. With regular applications the GUI would always be loaded in memory. The reason why this pattern isn't used more commonly is the fact that right now web browsers simply aren't designed to be used this way unless you start a new instance for just a single app. The second reason is that electron developers are lazy. They only want to test a single browser (or browser version) and are perfectly happy that this means Google can get away with shady things.