Wow, there is an incredible amount of hate for Electron. I understand the desire to avoid it with consumer apps and it feels strange to have large companies using it, but I'm honestly a huge fan of what they've been able to do with it for GUI design. I'm a roboticist who has been stuck in the 90s with tools like tkinter / qt / whatever, and electron has finally enabled me to build something modern for control and monitoring. It's been a godsend, but maybe that's why we are seeing so much adoption in the commercial space.
I do agree with you that Electron is an amazing platform and definitely has a lot of cool, solid use cases, but that doesn't mean that every single app we use _should_ be written in Electron. Recently, it feels like every app uses Electron. Even the ones that shouldn't.
Video Conferencing is one of those apps that in my opinion should definitely be native for two important reasons:
1. Performance: Video conferencing needs great performance. As a user, you want the best video possible at the best FPS possible. Mostly Electron/JS video conferncing apps are not bad (Facebook Messenger, Google Meet) because Chrommium just provides a JS wrapper for native APIs implemented in C++. But, if you want to do anything outside of that you're screwed. You will eventually run into the limitation of what Chromium gives you and this gives you an upper limit to what you can do to optimize this.
2. Memory Usage: Video conferencing is usually used alongside other apps (while sharing your screen for example). For that reason, you want to minimize memory usage as much as possible to make it easier for the user to have the app open while using as many apps as they can. Electron uses a lot of memory.
A third reason is that the human interaction guidelines provided by Apple for their UIs (and embedded into their APIs) is very, very good. It keeps the user experience consistent across your platform and makes your app easier to understand. And this is coming from someone who is not really an Apple fanboy. What you see with Electron apps is a steeper learning curve for having to learn how to use every new app you install.
As a user I don't mind Electron when the main running app (which I define as the app that is in focus > 50% of the time) is written in it. For me this application is VS Code and I'm happy with it. However, I'm concerned that larger and larger count of apps running in background move to Electron platform, mainly because that requires more and more memory (eventually surpassing memory available on my machine).
Creator of Watercooler here. Happy to answer any questions!
A little more Watercooler:
For the past couple of months I’ve been doing a lot of video calls. Personally, I didn’t quite like any of the video call apps out there. The ones done in JS/Electron/Browser always felt sluggish/slow and Zoom has a very unintuitive UI and seems to be made for boring corporate meetings. I eventually decided to make a minimal video calling app of my own and hence Watercooler was born.
Watercooler’s three main characteristics are that it’s:
A) Completely, 100% native (uses the native WebRTC library)
B) High-quality video
C) Extremely simple to use (No account needed, for example)
I’ve been doing a lot of tests calls during the last month or so and almost everyone who uses it mentions one of these during our calls.
A couple of quick takeaways from working on this project:
1. The native macOS APIs (AppKit, Cocoa) are pretty good, but not a lot of people out there are using them, which makes it hard to get questions answered or find examples for things.
2. WebRTC is an amazing project. It really does solve a lot of problems. But it’s also extremely complex. One example for this is the logic for how video resolution is selected and adjusted over time.
3. Debugging video call issues can be extremely challenging without the right tooling because issues are hard to replicate and tend to “fix themselves” once they start happening.
4. While building Electron Apps seems way easier (HTML, CSS, JS over native APIs + automatic cross platform apps), integrating with the host OS makes for a really pleasant experience.
There are still some minor, hard-to-reproduce bugs that will get fixed in the next couple of days/weeks. If there’s enough demand, we’ll build out some of the big missing features like group calls and calendar integration.
Glad to answer any questions and hope you give it a try,
J.
Honestly, Thank you very much for creating this native app. I am fed up of my Macbook being served this Electron junk food that is filling up my computers RAM and disk space, which is unnecessary for the tasks I am doing. Discord, Keybase, Element, Zulip, Slack, Skype and many others are constantly fighting for RAM on my PC and running my system to the ground.
Some of the apps I mentioned are made by billion dollar companies with lots of employees and yet they still continue to use Electron to solve a problem that doesn't scale when multiple Electron apps are running. It's like Java but much worse. Yet you created a lightweight native alternative that is performant than the Electron counterparts. Not sure how it compares to Zoom (as that is native), but I would take your app (even if it is paid) over any Electron app Every. Single. Time.
I am starting to replace any Electron app whenever I can by exclusively finding native apps which direct using Cocoa, Qt, wxWidgets, etc. This is another app I am interested in looking at.
> If there’s enough demand, we’ll build out some of the big missing features like group calls and calendar integration.
Please support this.
EDIT: I looked at the macOS App store to check for screen sharing support it appears you have a typo in the screenshot? Screenshaing -> Screen Sharing?
Thank you for the kind words. Everything you said is exactly my motivation for building this. Please let me know what the experience of using it is like and what can we do to keep improving it.
When it comes to comparing this to Zoom, I would say that the video/audio quality is just as good if you have a good internet connection and a tiny little bit of luck. Like it really truly can be and has been many times during testing. What I think the app needs to be better at is handling situations where bandwidth is not as plentiful or the system doesn't have that menu resources. That's the next thing I want to work on with this.
Re: Typo: That one escaped me last night after putting the finishing touches on this. Will fix and upload to the App Store in a bit.
The screenshot does show slightly higher CPU. We wanted to remain honest in that way. Strictly speaking, CPU usage is lower if you use Watercooler over having to open your browser to do a video call (if you add up all processes) and it's comparable to Zoom. Will work on maybe changing the phrasing on this. Thanks for the feedback!
Edit: Changed the copy to just "Watercooler uses less memory and than any other video conferencing app with comparable CPU."
While this might be interesting and relevant to the HN audience, I doubt that this is a differentiating factor for 99% of today’s video call users. And of the two, I’d argue processor would be more important than memory: high processor usage makes your lap hot and the fans kick in; whereas in today’s world of multi-GB memory as standard, 100 vs. 200 vs. 300 MB memory usage is effectively invisible.
But, I do think that users do notice the difference. I think you're right that they'll "feel" an application hogging their CPU more than they'll feel one doing so with memory, but they can tell when an application is faster/slower. I think this is especially true with video calling.
So the bet is not su much that you're open up Activity Monitor and track CPU or memory, but rather that you'll "feel" how the app does perform better. And yes, I could be totally wrong about it!
All that being said, Watercooler definitely has a long way to go when it comes to this. There's a bunch of stuff I plan to do in order to improve performance.
Looks great, now just have to find a counterpart to test it out with. I love the fact that it's native, props for that. I had no idea that people are putting Electron/browser apps out there, yuck.
How does signaling between clients work? Is this going to a server you control?
And what about encryption, is that enforced by WebRTC per se?
Lastly, are you routing calls through TURN servers if NAT tunneling with STUN/ICE fails, or always?
I just wish that SIP had taken off. Then we could just call each others email address. Kinda works with FaceTime, except it's Apple's garden.
> How does signaling between clients work? Is this going to a server you control?
Yes, this is going to my own signaling server. No way around that. The signalling logic is very minimal though and no audio or video data touches the signalling server.
> And what about encryption, is that enforced by WebRTC per se?
In WebRTC, all communication between peers is encrypted once the connection has been established.
> Lastly, are you routing calls through TURN servers if NAT tunneling with STUN/ICE fails, or always?
I do have one TURN server based in SF in case STUN/ICE fails , yes. If I see a lot of usage in other geographies, we'll probably deploy more in different regions.
We're very, very close to coming out with a browser client soon. The experience is not as nice as the native one, but it will solve this issue of being able to use it with anyone.
If you're looking to test it out with anyone, feel free to schedule a demo (link in the landing page). The link is kinda hidden, but it's there!
