Hello HN! I’m the founder of Pop (https://pop.com) and formerly the co-founder and CEO of Screenhero. Also on the team are a couple other ex-Slack folks and a former Electron co-maintainer.
Pop is the spiritual successor to Screenhero and strives toward the same goal: making remote work better than working together in the same room. After Slack acquired and subsequently killed Screenhero and after becoming remote workers ourselves, we found that none of the Screenhero copycats were really solving the problem adequately. Some are unstable, some are slow, some have poor UX. We decided to get back into the space and build a product that we like to use, leveraging some of the good ideas we came up with working on Screenhero and Slack.
With Pop, instead of just talking with your coworkers about concepts with words, the shared screen becomes a shared whiteboard for diagrams and flow charts. Instead of barking out line numbers or function names, it’s faster to highlight the line with a mouse. And instead of telling someone what to type, it’s easier to just show them by typing directly in their text editor. You can start a call directly in the app or with the Slack integration “/pop” command and collaborate with coworkers on macOS, Windows, and Linux. Or, if you don’t want to bother someone to download the app, they can join a session via web browser (mobile browsers supported, too!), even without a Pop account.
For now, it’s completely free to use. We plan to always maintain a free version, though for heavier team and enterprise use, we’re looking to start charging soon (servers are very much not free). Once we have revenue, we plan to turn some of our attention to adding more remote office features, like spatial audio and presence, and, more broadly, addressing issues of isolation and loneliness in remote work.
We’ve bootstrapped the company entirely ourselves and are unbeholden to outside investors. Our goal is to build a product that people enjoy using. We’re not looking for an exit; we’ve been through that and know what it’s like (financially great, but emotionally taxing). We want to create an independent and sustainable company where we are happy to work for our entire careers.
Let’s get these out of the way:
1. Yes, we’re building on Electron. Yes, we are aware of the performance tradeoffs, but have decided this is the best choice for us. We’re shipping Windows, Mac and Linux clients along with browsers with a four-person team — it’s the only good way right now to do that without features taking six months. We’ve modified the screen sharing pipeline in Chromium to reduce latency as much as possible, because with interactive screen sharing, milliseconds matter.
2. Yes, the domain was expensive. Roughly $1.5m. We consider it an asset that is unlikely to depreciate significantly. (The domain actually has an interesting history as a failed precursor to Netflix from Ron Howard and Steven Spielberg https://www.theguardian.com/technology/2000/sep/10/internet....)
3. No, our non-compete no longer applies — it expired two years after Slack’s ScreenHero acquisition.
4. Yes, we were originally called Screen.so. It was not a good name (and HN let us know, thanks!) and we are now very happy with Pop.
We’d love you to try Pop and let us know what you think, even and especially if it doesn’t work well for you. The app has gotten exponentially better because our dedicated users tell us about their issues and work with us to get them fixed. And, if you have ideas about how remote work could be more enjoyable, we’re eagerly listening!
Been using Pop since beta (on Arch Linux) and while it has had a few rough spots along the way, it keeps getting better. Pop does have a public issue tracker that we can submit bug reports and feature requests to as well > http://support.pop.com/.
Pop used to have a roadmap (https://www.figma.com/proto/bMYNNI6cy4DL1r0dgOFzjI/Screen?no...) more visible about the longer term vision which I really liked, it was about creating a constant layer on the desktop where you can just press a hotkey, up comes a list of Pop contacts, and you can basically knock on their door, they get a quick ping and you can be joined together in a second. This is the vision that I am really into and there is an issue to track the progress here > https://screen.canny.io/feature-requests/p/global-shortcut-t....
This means no more posting video share links in Slack and the friction to actual pair with someone becomes a couple seconds versus a minute+. Really looking forward to this!!!
We heard an equal number of people excited about being able to jump into a call with a coworker, vs. being worried about yet another layer of distraction. Having said that, we've now built out most of the infrastructure to support that feature (we have a contact list with your team in it), so we'll be looking into this soon.
Ahh, I could see some being distracted about that. Suppose one can just set a "status" of "available" or "focused/away" to be able to be pinged or not.
Good to hear that most of the infra is built out to support this feature!
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.
This also explains why the screen sharing so much less efficient than Screenhero's. I had no idea. Hopefully they can add more control over video quality in the future, as the current implementation seems to go for maximum quality all the time, which interferes with system performance. It being Electron especially explains why it's so much more resource intensive than the other solutions.
We have tinkered with the idea of a native module solely responsible for screen scrape + encode + send, which would further improve performance.
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.
Thanks for the feedback! You're right, we need to improve each of these significantly.
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 [email protected] and we'll make sure it's fixed in our keyboard overhaul.
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.
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?
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.
> 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.
When you say Pop could be more lightweight, are you talking about CPU or memory usage?
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.
For me personally, memory usage has been a big concern with the growing number of Electron apps. CPU usage on well-behaved Electron apps in idle seems mostly negligible or at least not significantly worse than on native apps.
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 :-)
Not OP, but with the apps you've mentioned (and other Electron apps), I'd be less likely to keep them running (and would prevent them from opening at login) due to their outsized resource impact. Which in turn decreases user retention and my ability to recommend it to others.
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".
> When you say Pop could be more lightweight, are you talking about CPU or memory usage?
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).
1Password and Dropbox being on Electron seems absurd.
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.
This is a good point. We definitely want it to be a no-brainer for people to keep Pop running. One idea may be for us to look into relinquishing resources while running in the background, which could be a best of both worlds solution.
This is how I wish more companies used Electron. It makes complete sense to me as a stop-gap when you're starting out, need to grow fast, and are still experimenting with your product.
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!
Related anecdote: Screenhero's UI was originally totally native on the two platforms we supported (Mac and Windows). It was a night-and-day improvement (it looked better, had fewer bugs, was easier to build and maintain) when we moved from native UI to HTML5 (using Awesomium on Windows, and WebView on Mac). However, we'd then have issues on Mac where a user's UI would have glitches because their version of OS X or Safari (often both) weren't up-to-date. So it was always a little awkward to tell people that the reason their screen sharing app looked funny was because they needed to update their web browser.
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.
Agreed, it's quite an inspiration as to the best Electron can be. I think the trick for an app like ours is to offload the heaviest pieces to native code, and use Electron purely as a presentation layer. This is something we're now going to look into.
While reading this[1] I just remembered you guys and thought I'd throw in the idea of compiling your "native" code to WebAssembly, in case it might fit your case.
In Pop, if you add people to your contact list (or connect with Slack), you can see your contacts and team members' online presence, and can call them from within Pop.
Slack runs like shit on my pc. I’ve not been able to answer a call this week: seems to freeze up for the length most people want to dial when there is an incoming call. I hope OP will optimise for performance when using electron.
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.
Pop’s performance is something we have spent significant time improving, and we’ll continue to do so. My only ask is for folks to try the product and judge its performance (or lack thereof) on its own merits, regardless of presumptions based on our use of Electron. We have thousands of daily active users that continue to use the product happily.
It's not about lower spec machines. It's more about using far less resources on very much capable machines, and leave the other resources for other processes, as long as there is a way of doing so.
Please provide a way to voluntarily downgrade stream quality. I understand if people with poor vision require it, but I really don't need everything in hi def and definitely don't need 3D.
A serious issue I've had lately is Teams consuming 90%+ of my total Internet usage. The fact that it is consuming massively more bandwidth even than Netflix doesn't seem at all justified. My ISP is throttling me now and again and preventing me from being able to work at all. I understand it isn't the place of your company to fix the problem of crappy residential network infrastructure in the United States, but if you want broad adoption from people working from home in the United States, you really have no choice but to accommodate this.
Note that the only reason I'm using Teams is because I'm required to while working on government contracts because it's the only service right now certified to transmit controlled unclassified information.
If you are looking for screenhero alternatives, you should check out Tuple! Our team has been using it for about a year now and we love it.
My favorite part about Tuple is how it HAS NOTHING that overlays the screen. It just hides in the tray.
I HATE when these screen sharing apps all try to put floating windows and menus and chrome around the screen edges. Just let me share my screen without getting in the way, dang it! Why is that so much to ask?
Tuple's done a good job of their minimalist UI (it's largely modeled after Screenhero).
With Pop, you can minimize the control panel with 1 click. We'll soon also be adding the ability to remove the border around your shared screen entirely (some users have told us it gives them anxiety to not see something that clearly shows them that they're sharing their screen, but we've now heard the opposite perspective from enough people to realize we need to support both preferences).
Why is it so important to get an expensive domain? Does the three-letter .com really add that much value? Especially when it's not a B2C product / offering and specific to a focused audience? I'd think a three-letter .com would be something with widespread, international appeal to be worth the expense.
My personal opinion is that in this case it’s going to make a world of difference. Very difficult to know for sure, not like we have a control group, but it’s super catchy and feels premium.
I'm explicitly not taking funding for Pop for this exact reason: I want to keep Pop around forever. I know that isn't something most people are able to do, and I'm grateful for my past success that's enabled me to do this. But I can tell you that it was incredibly sad for me to see Screenhero die, and I never want that to happen again — both as a founder, but also as a user.
My team has been using CoScreen (https://www.coscreen.co/) for collaborative meetings and development for much of the last year and it's been really transformational.
The ease at which anyone can share any window and everyone can instantly interact with it is quite game changing for distributed teams IMO.
We do that sometimes with Show HNs when the top comment is introducing the project. The reason is that there's not much difference between "replying to the comment introducing the project" and "replying to the project itself", i.e. posting a top level comment. But the former end up ranking higher on the page, which can be unfair.
Since you mentioned in a comment that your non-compete expired, maybe you are also no longer under any NDA. Can explain to a person outside of the startup world how this buy-and-kill works? If not killing a competitor, why? What do they expect a founder to do after killing their baby?
It wasn’t ever intended to be a buy-and-kill, it’s just unfortunately what ended up happening. When Slack acquired Screenhero, it was with the full intent to bring voice/video/screen sharing to Slack. The problem was that, post-acquisition, leadership lost interest in what could’ve been a promising feature set and growth vector for Slack (see: Zoom in 2020). Partially because integrating disparate pieces of software is a hard problem and partially because management's appetite for investment in the team waned after the first year, building Slack Calls was slow and it was unclear how valuable the feature was to Slack's success. Add in the cost of maintaining what is a very complicated and far-reaching implementation for interactive screen sharing, (not just for engineering, but also for policy/legal and customer support), it made sense for Slack to kill it.
While I was still at Slack, there were retrospective conversations around how Screenhero maybe should have been built on the Slack platform, instead of as a first-party app. However, the acquisition happened so early in the life of Slack that the platform didn't really exist yet, so it's unclear how we'd do better if we had to do it all over.
With Pop, we're doing things the right way. Pop is a standalone app, with a solid Slack integration. It makes it really fast to jump between the two (in fact, it's faster to jump into a Pop meeting via Slack, than it is to join a Slack Call!).
Slack's poor calling is baffling to us, and the fact that they are uninterested in making it better is obvious. The quality is so bad, we use google meet for almost everything at the company, even though we would prefer to use the native slack calling.
Its actually easier to use other apps than Slack's own apps.
For example, you can't schedule a recurring slack call that calls all the participants. I would LOVE this feature, if there is a way to add it into slack.
The way you explain it, looks like if Slack acquired Screenhero in a whim, "just in case we need it", and afterwards they realized that integrating and maintaining foreign code is a hard to do. Like, I could have told them that piece of wisdom for free.
I know, things are always more complex and your comment is no doubt a summarized version of what happened. It just read funny to me.
Yes, that was ~3 years of learning (and pain) condensed into a short paragraph :D
I think one key piece worth emphasizing was: Screenhero's core strength was in its interactive screen sharing. Slack's main desire was in voice, then video, then screen sharing, then interactive screen sharing — and this "impedance mismatch" is somewhat responsible for where things ended up. By the time we got to the end of that roadmap, the appetite for the final feature was low, while the cost was very high.
Hands down the best thing to come out for remote collaboration since the pandemic. My team and I have been using pop.com since we discovered it as screen.so. It's been amazing! We added it to Slack and it make it seamless for us to get into a pairing session with one command. Prior to pop.com we tried a bunch of other tools but didn't find any that gave us the fluidity of collaboration we got with pop.
One of our favorite features is the drawing capabilities. It's weird to believe that this is the only tool we've used that has perfected drawing - something that has truly helped us collaborate without having to use a virtual whiteboard application.
- back button from the download is broken
- connect with discord would be good
Not sure how this fits, but often we don't get services like this these days because of the pricing model. We like a lot of these kinds of things, and we subscribed to a bunch (many cancelled now), but they all added up and didn't really charge us based on our usage. Perhaps we aren't the target audience as you want people who integrate this into their regular work so people use it all the time. But for us, we'd want all employees to be able to use this, but if we don't use it, we pay nothing. When we do use it, we really want max concurrent users to be charged (concurrent being not necessarily exact time, but within a day or so ). i.e., if 1 user uses it for 10-15 minutes for the entire month, we want to be charged something representing that usage. Then we'd be much more likely to signup and have this kind of thing available if and when we need it. Or any other model that seems fair for occasional / spikey use, psychologically, we just don't want to feel like we are paying for something we aren't using when we don't use it.
We're pushing out a fix for the back button as I speak, thanks for the heads up! It should be live in ~10 minutes (CI build + test + deploy).
Discord: we haven't looked into their API yet, but it's an oversight on our part. We'll take a look soon!
Pricing: thanks for the detailed explanation of where you're coming from. Your perspective resonates well with ours, which is that we'd like the amount our customers pay us to be roughly commensurate with the value we provide them.
If you're truly interested in using Pop and providing feedback, I'd love to learn more about your team and your background so we can make sure we're aware of that perspective as we work on our pricing plan. Feel free to find a time via https://calendly.com/j-pop/30min or drop me a line at [email protected]. Thanks!
> Please use a supported browser Chrome, Safari, Firefox or download Pop for Linux.
I'm using Firefox 91 on Ubuntu 20.04. Is this a browser version check failing or a some missing capability? Maybe one of the extensions in my browser is blocking something needed by Pop.
It seems to work on Vivaldi. At least it gets to the account registration page. I hoped it would work without an account so I didn't go any further.
I've been following you guys' work since Screenhero then Slack integration then Slack reduced integration then Slack killing it (still makes no sense why) then screen.so then now we'll give a try to Pop!
> Yes, the domain was expensive. Roughly $1.5m. We consider it an asset that is unlikely to depreciate significantly.
Congrats on getting it! Hopefully it wasn't too much of distraction.
I worked with https://news.ycombinator.com/user?id=ted0 who was AMAZING at helping find and acquire the domain. I can strongly recommend him as an amazing person to work with. It took a few days to find a domain we loved, and another few days to close the transaction. It was quite an interesting experience!
At Fy!, we’ve been using Pop for impromptu remote pair programming sessions for a few months now. The killer feature, for us, is how easy it is to take or surrender control over the sharer’s screen. Much lower friction compared to Zoom or GMeet.
It works well, too. There’ve been random hiccups, but nothing too disturbing. Most of the time it just gets out of the way.
Wow, that's great to hear! Please do let us know about the random hiccups at [email protected], since the long tail of issues is surprisingly long in this product space, and so we really appreciate any feedback that can help us improve.
Have been using Pop for 1:1 pair programming sessions with a friend and it’s been great! To me there is a massive value in simplicity and speed with which we can go from zero to working. It’s 100x faster than Zoom or Meet. Two clicks and we are on!
> The second-system effect or second-system syndrome is the tendency of small, elegant, and successful systems to be succeeded by over-engineered, bloated systems, due to inflated expectations and overconfidence.
If this is an issue you can replicate, would you be open to debugging this live with me? If so, please pick a convenient time here: https://calendly.com/mustafa-pop. Thanks!
Hopefully we can fill the Screenhero-shaped void in your toolbox with Pop. Please do try it and let us know what you think! We're committed to making Pop exceed Screenhero in both functionality and longevity.
Wow, thanks for sharing, and for the detailed write up! Please keep the feedback coming (I'm [email protected] if you'd like to keep in touch in the future).
I do agree Screenhero should have had a more generous free tier. With Pop, we will likely have a free usage tier when we start charging. We haven't mentioned it on the pricing page just yet since everything is currently free and it would complicate the story.
I love the analogy you've made with Adobe Acrobat Reader! We definitely want Pop to become the default tool you'll use when you want to work remotely with someone on a task together on your computer (pair programming today, but a whole lot more in the future). And I agree that keeping a generous free tier will help us enable that, beyond just the ability to join calls started by paid users.
Not that anyone can hold a grudge for founders getting acquired, but I think myself and others here just want to make sure this doesn't meet the fate of ScreenHero, purchased by Slack and disappeared, ruined, etc.
> I named it “Screen” as homage to Screenhero, only to realize that such a generic word makes a terrible brand name, and consequently makes it impossible to find via search engines.
So you've changed it to "pop"? I don't think you're going to get any better here..
Congrats on the launch! How "low" is the latency? The "Live Share" feature is VSCode gets mentioned a lot and has some advantages over traditional screen-sharing as it seems to beam the diffs of the code itself rather than a typical video stream. How do you compare to that?
Sending over keystrokes will always be faster than sending across a video stream of your screen. So VSCode Live Share will always be faster. However, in practice, we've found the cost of a few extra milliseconds in latency are far outweighed most of the time by the benefit of being able to interact with any application on the shared screen (and draw).
For instance, if you're building a webapp, and need to look at the product alongside the code, screen sharing (especially with the ability to draw) is a lot more valuable than being able to type in the IDE.
Back when we made Screenhero, we had the option to share a specific app, and what our users told us was that they'd often start by sharing the IDE, but then realize they wanted a lot more, and so would have to stop and share the entire screen. We eventually dropped the 'window share' feature for this reason.
I've been using VS Live Share too, and it is good, however, I still use a Pop session along with it, as we still need to share the browser at times as well as other things. So, I use both in tandem and will likely continue to do so.
Thanks for the heads up on Firefox/iOS — we'll take a look!
Your repertoire of skills is crazy impressive — it's really inspiring and amazing to see all the stuff you've built and work you've done. Your manifesto is also exactly the kind of thing the world needs more of. We're not currently hiring but I would love to chat with you to exchange notes and war stories if you're up for it! Feel free to grab a slot via https://calendly.com/j-pop/30min :)
I have a small bug to report with the website: I cannot scroll the Privacy Policy site. This is on Firefox 91 on Windows 10, it does seem to work in Chrome, however.
I think I remember seeing this when it was screen and being a little confused why you were using daily.co if it’s your core business. Still using daily.co?
Our core business is enabling remote work and remote pair programming. WebRTC infrastructure is largely commoditized, and we're open to revisiting how we handle our WebRTC infrastructure in the future.
Daily is a great infrastructure provider, and moreover, the team was incredible to work with.
The reason we switched out from Daily was because we were running into bugs in the product, and weren't able to tell whether they were on our end or Daily's end. By owning our own infrastructure, this became a non-issue: every bug was ours to find and fix. It turns out most of the issues we had were bugs in our custom modifications to Electron to reduce screen share latency, but we had no way of knowing at the time. Now that we've invested in our own infrastructure, it's the path of least resistance to continue using it, but we're open to revisiting this decision in the future.
The Daily team is stellar to work with, and I strongly recommend them to anyone looking for a WebRTC infrastructure provider.
In short: when you need to see anything outside the IDE (e.g. a debugger, or even just seeing the running app alongside the IDE), a tool like Pop is very helpful. But you can also use it in conjunction with those IDE features, as Elijah in the above thread said he does.
It seems like it maybe does a better job of handling video and audio than tuple does, and it looks like it plays nicer when there are multiple people involved.
For example, inviting someone to a screen sharing session is as easy as sending them a link.
It also has virtual whiteboarding, which Tuple doesn't have
Am I the only one who can't scroll on this page? There appears to be content, but it won't let me go anywhere past the front page (Firefox, if it helps)
Pop is the spiritual successor to Screenhero and strives toward the same goal: making remote work better than working together in the same room. After Slack acquired and subsequently killed Screenhero and after becoming remote workers ourselves, we found that none of the Screenhero copycats were really solving the problem adequately. Some are unstable, some are slow, some have poor UX. We decided to get back into the space and build a product that we like to use, leveraging some of the good ideas we came up with working on Screenhero and Slack.
With Pop, instead of just talking with your coworkers about concepts with words, the shared screen becomes a shared whiteboard for diagrams and flow charts. Instead of barking out line numbers or function names, it’s faster to highlight the line with a mouse. And instead of telling someone what to type, it’s easier to just show them by typing directly in their text editor. You can start a call directly in the app or with the Slack integration “/pop” command and collaborate with coworkers on macOS, Windows, and Linux. Or, if you don’t want to bother someone to download the app, they can join a session via web browser (mobile browsers supported, too!), even without a Pop account.
For now, it’s completely free to use. We plan to always maintain a free version, though for heavier team and enterprise use, we’re looking to start charging soon (servers are very much not free). Once we have revenue, we plan to turn some of our attention to adding more remote office features, like spatial audio and presence, and, more broadly, addressing issues of isolation and loneliness in remote work.
We’ve bootstrapped the company entirely ourselves and are unbeholden to outside investors. Our goal is to build a product that people enjoy using. We’re not looking for an exit; we’ve been through that and know what it’s like (financially great, but emotionally taxing). We want to create an independent and sustainable company where we are happy to work for our entire careers.
Let’s get these out of the way:
1. Yes, we’re building on Electron. Yes, we are aware of the performance tradeoffs, but have decided this is the best choice for us. We’re shipping Windows, Mac and Linux clients along with browsers with a four-person team — it’s the only good way right now to do that without features taking six months. We’ve modified the screen sharing pipeline in Chromium to reduce latency as much as possible, because with interactive screen sharing, milliseconds matter.
2. Yes, the domain was expensive. Roughly $1.5m. We consider it an asset that is unlikely to depreciate significantly. (The domain actually has an interesting history as a failed precursor to Netflix from Ron Howard and Steven Spielberg https://www.theguardian.com/technology/2000/sep/10/internet....)
3. No, our non-compete no longer applies — it expired two years after Slack’s ScreenHero acquisition.
4. Yes, we were originally called Screen.so. It was not a good name (and HN let us know, thanks!) and we are now very happy with Pop.
We’d love you to try Pop and let us know what you think, even and especially if it doesn’t work well for you. The app has gotten exponentially better because our dedicated users tell us about their issues and work with us to get them fixed. And, if you have ideas about how remote work could be more enjoyable, we’re eagerly listening!