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.
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?
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.
Edit: Changed the copy to just "Watercooler uses less memory and than any other video conferencing app with comparable CPU."
Thhaaaaank you for not making me sign up for yet another account.
In the future, we will probalby have other clients other than the macOS one.
Does anyone with a Mac not have an iMessage account, leaving their texts green instead of blue? That audience seems small.
To keep work separate from personal, I originate work texts and FaceTime from the work # on my dual number iPhone. This is also settable per Contact.
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.
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.
There's nothing in this world that I love more than native apps.
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!
