6 ms·

Thanks for the provocative phrasing — I really like it! The native module coupled with Electron could be a great solution to the performance issue: it would gi

Thanks for the provocative phrasing — I really like it! The native module coupled with Electron could be a great solution to the performance issue: it would give native performance for the most critical part of the product, while still providing a cross-platform foundation for a shared user interface across 4 platforms (Mac, Windows, Linux & browsers). Given the feedback today on performance and resource bloat, we're going to dive deeper into benchmarking our product against the competition, and will post an update on what we find.

hug 5y ago
Don't benchmark yourself against other Electron apps. Just promise yourself you'll eventually quit Electron. Electron is nothing more than a deal you make with the devil, selling potential for velocity, only the others are too far gone to even know where they are anymore. When you develop for Electron, you're lured in with an attractive proposition, shipping more & sooner than you otherwise could, at the expense of ever being able to make the best version of your app. As a tradeoff, that's not too bad. You can at least, with just the few of you, get the product out the door sooner rather than later and pick up your first users. You keep going with Electron, because it has the least friction, allowing you to introduce new features and fix bugs at pace you otherwise couldn't sustain. At some point you've listened to the silver tongue'd serpent for a little too long and you've got a slick app with all the value-adds you could want. Also, a giant user base. And that user base consists of people who all have a vague distaste for the app, but they use it anyway, because that's the game, that's how they get work done. Dragging everyone a little closer to hell if only by the amount of heat of their laptop CPU is putting out. But hey, at least your app is still not as bad as Teams, right?
- jsherwani 5y ago
  Another commenter mentioned how VSCode's performance shows that Electron isn't terrible [1]. Based on the discussion, we're going to look a lot deeper into finding ways to reduce Electron's memory bloat especially when idle, and reduce CPU usage when screen sharing by attempting to offload the most computationally intensive parts to purely native code, while still leveraging Electron as a unified, cross-platform presentation layer. We'll report on our progress on this front, and our goal will be to get the best of both worlds: one cross-platform code-base, coupled with native levels of performance. [1] https://news.ycombinator.com/item?id=28230542 https://news.ycombinator.com/item?id=28230542
- LewisJEllis 5y ago
  > shipping more & sooner than you otherwise could, at the expense of ever being able to make the best version of your app This reads like "you need to let perfect be the enemy of good", which is typically not the tradeoff to take while trying to build a business. I would further even posit that the "best version" of many apps is the one that has been iterated on the most, and if Electron allows for faster iteration, then the Electron version will be the best version, even if it uses a few more runtime compute resources (which everyone has plenty of anyway...). > people who all have a vague distaste for the app, but they use it anyway, because that's the game, that's how they get work done There are plenty of Electron apps I use daily that I have no distaste for or reservations around; some are done poorly, yes, but you can build shitty apps with or without Electron. I've found that most Electron apps I use are better for having used Electron. I don't care one bit if an app uses an extra 100 megs of my RAM or whatever - it's 2021, memory is cheap, dev time is expensive. The native-performance-purist crusade against Electron is really overblown, and I mostly see it from people who've never actually used Electron or otherwise tried to ship a desktop application themselves. In spots where performance actually matters, and Electron is actually a performance barrier, yea sure go native (like putting record/encode/send in a native module as mentioned further up here), but otherwise please do eat a few more of my computer's resources if it ultimately lets you offer me more polished tools.

hug 5y ago

Don't benchmark yourself against other Electron apps. Just promise yourself you'll eventually quit Electron. Electron is nothing more than a deal you make with the devil, selling potential for velocity, only the others are too far gone to even know where they are anymore. When you develop for Electron, you're lured in with an attractive proposition, shipping more & sooner than you otherwise could, at the expense of ever being able to make the best version of your app. As a tradeoff, that's not too bad. You can at least, with just the few of you, get the product out the door sooner rather than later and pick up your first users. You keep going with Electron, because it has the least friction, allowing you to introduce new features and fix bugs at pace you otherwise couldn't sustain. At some point you've listened to the silver tongue'd serpent for a little too long and you've got a slick app with all the value-adds you could want. Also, a giant user base. And that user base consists of people who all have a vague distaste for the app, but they use it anyway, because that's the game, that's how they get work done. Dragging everyone a little closer to hell if only by the amount of heat of their laptop CPU is putting out. But hey, at least your app is still not as bad as Teams, right?

jsherwani 5y ago
Another commenter mentioned how VSCode's performance shows that Electron isn't terrible [1]. Based on the discussion, we're going to look a lot deeper into finding ways to reduce Electron's memory bloat especially when idle, and reduce CPU usage when screen sharing by attempting to offload the most computationally intensive parts to purely native code, while still leveraging Electron as a unified, cross-platform presentation layer. We'll report on our progress on this front, and our goal will be to get the best of both worlds: one cross-platform code-base, coupled with native levels of performance. [1] https://news.ycombinator.com/item?id=28230542 https://news.ycombinator.com/item?id=28230542
LewisJEllis 5y ago
> shipping more & sooner than you otherwise could, at the expense of ever being able to make the best version of your app This reads like "you need to let perfect be the enemy of good", which is typically not the tradeoff to take while trying to build a business. I would further even posit that the "best version" of many apps is the one that has been iterated on the most, and if Electron allows for faster iteration, then the Electron version will be the best version, even if it uses a few more runtime compute resources (which everyone has plenty of anyway...). > people who all have a vague distaste for the app, but they use it anyway, because that's the game, that's how they get work done There are plenty of Electron apps I use daily that I have no distaste for or reservations around; some are done poorly, yes, but you can build shitty apps with or without Electron. I've found that most Electron apps I use are better for having used Electron. I don't care one bit if an app uses an extra 100 megs of my RAM or whatever - it's 2021, memory is cheap, dev time is expensive. The native-performance-purist crusade against Electron is really overblown, and I mostly see it from people who've never actually used Electron or otherwise tried to ship a desktop application themselves. In spots where performance actually matters, and Electron is actually a performance barrier, yea sure go native (like putting record/encode/send in a native module as mentioned further up here), but otherwise please do eat a few more of my computer's resources if it ultimately lets you offer me more polished tools.