News for hackers. Stuff that matters.
Re:Electron apps cannot be submitted to the Apple store by fooey on Monday November 04, 2019 @01:50AM (#21439476)
Yes, this is the thing.

The option isn't electron vs native, it's electron vs nothing.

Re:Electron apps cannot be submitted to the Apple store by leadingthenet on Monday November 04, 2019 @02:20AM (#21439575)
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?

Re:Electron apps cannot be submitted to the Apple store by wutbrodo on Monday November 04, 2019 @03:58PM (#21446436)
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)

Re:Electron apps cannot be submitted to the Apple store by Seirdy on Tuesday November 05, 2019 @07:21AM (#21451699)
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 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.
Re:Electron apps cannot be submitted to the Apple store by imtringued on Wednesday November 06, 2019 @04:51AM (#21461073)
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.

Re:Electron apps cannot be submitted to the Apple store by imtringued on Wednesday November 06, 2019 @04:44AM (#21461033)
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.
Re:Electron apps cannot be submitted to the Apple store by ldh on Monday November 04, 2019 @09:31AM (#21441943)
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.