I hope you'll reconsider as your team grows. Developers look at their own app and think the extra resource usage isn't too bad, but the more this happens, the more Electron apps I end up running at once. Because Pop includes presence, it's something that, if it were more lightweight, I'd keep running all the time. As it is, if someone wants to call me, they have to first contact me on another platform to ask me to load Pop.
Also worth noting is that there's a setting to "reduce power when idle", which throttles screen scraping frame rate when relative CPU utilization is high. Additionally, you can disable "Use full resolution" to turn off Retina support, which should further improve performance for you. We'll work on surfacing these settings better, since it's not obvious that they're buried inside the settings page.
"Reduce Power When Idle" is always selected, but there's no explanation of what it actually does. I would've expected it to be based off the user being idle in regards to the shared screen (e.g. no input for x time), not based on relative CPU usage calculations. It's hard for the system to increase CPU usage if Pop is already consuming most of it, so I wonder how long it takes for this to actually kick in.
"Use Full Resolution" also doesn't explain what it does, so it's unclear how bad the video would get if it was turned off. Even "turn[ing] off Retina support" is unclear, as it doesn't tell me what the alternative is. Does it scale down to the 1x version of the screen? Ideally we'd just have a resolution selector here, for both local and remote.
I've also long had issues with the keyboard shortcuts and various settings, again because it's unclear how the settings actually effect anything. I've also encountered bugs where just typing certain characters (I think it was ".") to a remote share toggled my ability to control the remote at all, which was extremely irritating. I really need more explanation of local vs. remote short cuts and which go where and when.
Reduce Power When Idle: decreases the frame rate from 30fps gradually down to 15fps when there's no user activity after a few seconds, and also drops frame rate due to CPU utilization. But you're right, we need to rethink this.
Resolutions: yes, it does scale down to 1x, and yes, selecting a resolution would be better.
Re: shortcuts, do you remember when it was that you experienced these issues? We had a few bugs around these that have been fixed. We're also working on a revamp of our keyboard handling code for all three platforms to address some of the remaining issues. If you're still running into a specific issue, let us know via hello@pop.com and we'll make sure it's fixed in our keyboard overhaul.
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.
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?
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.
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.
Also, do you keep Slack / Microsoft Teams / Dropbox / 1Password / VSCode always running, and do you have the same concern with those apps or is it something unique to Pop?
Performance is definitely a priority for us, so understanding where you're feeling the bloat would be really helpful to us.
To add to that screen sharing and video calling is already resource intensive, so whilst the argument could be made - what's another 500mb of ram, I'd expect the client to be as optimised and light weight as possible, because a system under strain is no longer "blazing fast".
Regardless, you kind of hit on the point - Slack & VSCode are basically non-optional, maybe for other people it's some other combo. Pop, on the other hand, only has potential to be "non-optional" for collaborative work. Thus, given that real-time collaboration is not the standard way of working, being a resource hog on the level of "non-optional" apps means you will be shut off first for most users.
But memory is a different story. I don't always get to work with machines with "enough" memory, so I don't keep any apps with a larger memory footprint (let's say anything above 50MB) running longer than necessary. More often than not I will try to just use the web app, which will at least not load "yet another copy of Chrome". Where feasible I will also simply switch to an alternative.
Not to backseat engineer too much, but maybe you could look into a smaller native component that can run in the background to listen for incoming "calls" and only loads up Electron (or maybe a native webview) when the user wants to actively use the app.
All of that said, it looks like you have a solid product and I wish you success with it.
EDIT: It appears that a year ago when your product was still named screen, I also provided some feedback which you acted upon swiftly, so I'm optimistic you'll figure this out as well :-)
Memory usage. I haven't noticed an issue with CPU usage, because I usually only open it briefly and tend not to be doing anything else intensive during that time. If I kept it open for video chat while I was working, maybe it would be an issue, but I currently use Messenger (in the browser, not the app) or Discord.
> Slack / Microsoft Teams / Dropbox / 1Password / VSCode
Slack was definitely a big problem for memory usage, so I don't use that much anymore. VSCode I only open while I'm editing. I wish it worked better over an X connection for that. Dropbox I allow to keep running on my main Mac (although its memory usage is ridiculous for what it does), but only load it as needed on my Mac mini. I use Teams, but that's on a work laptop that only runs Teams and Outlook.
Discord is the only Electron app that I keep open nearly all the time.
Based on the feedback today, we're going to look into how we can reduce memory usage overall (especially when idle), and CPU usage especially when screen sharing. We already modify Electron, so we may be able to work out a good middle ground that reduces the footprint significantly, while still giving us the advantages of a shared codebase across our 4 platforms (Mac, Windows, Linux, web).
Where I get a bit frustrated is when companies stay on Electron. Slack knows—or should know—what type of product it is at this point, and so the developers shouldn't be pushing transformative software updates with any kind of frequency. So, step back and take the time to build native versions for each platform. Users will appreciate that their computers are suddenly faster!
Having said this, I think this discussion between Electron vs. Native is a false dichotomy. Performance and developer efficiency are both clearly important, and we don't have to maximize one dimension alone. I am confident we'll find a way to make Electron far more performant by switching off unnecessary features, such that it provides us just the surface area we need to be able to build great products that are indistinguishable from their native counterparts: except that they're quicker to build, easier to debug, are of higher quality (with fewer bugs), and cost less.
I know this sounds optimistic, but given the popularity of Electron, coupled with the issue of performance, this is an issue that is certainly going to improve over the coming months and years. Who knows, since ours is one of the more performance-hungry products, we may end up finding a solution that others can leverage as well.
OP: Until you are in the position where your software is forced on people by the pointy-haired managers (like Slack or Jira for example) you’ll need a better performing app or people will give up.
Coders especially; we don’t like waiting and emptying our L1 cache to context switch to troubleshooting a comms tool.
With the work from home boom you may be often running on lower spec machines than the developers work pc that they are remotely connecting to.