I honestly think it's pretty amazing how cheap air travel already is in the USA and Europe. It explains why we're seeing all time highs for air travel.
The air industry seems like a good example of just the right level of regulation: There's tons of competition, different pricing tiers with their corresponding levels of quality, and a lot of dynamism combined with a good set of consumer base regulations (24 hour cancellation period, for example).
As a former figma engineer, let me be the first to say that Evan Wallace is, in fact, a legend. A true 100x-er. There's still parts of the codebase basically no one at Figma really understands that Evan wrote back in the day.
One example of that is something like he adapted a shader we use internally to render font glyphs, which no one has touched ever since. The engineer who told me this had spent a few days trying to understand it and said (after having worked in this area for years) was stumped by it.
> IANA Employment Lawyer, so take everything here with a huge grain of salt, but is the separate product going to be a separate company? If it is would some mix of equity + cash work? If not, it seems like some custom contract based on the product and its dedicated revenues/profits might be necessary with lawyers involved.
It will be, yes! I do think it should work. I think I'm slightly worried about how much is appropriate given an unspecified time commitment.
> But no one, especially early on when they're small or solo, wants to go hire a lawyer to write these contracts. I wonder if we can create good templates for rev/profit shares for solo/indie/bootstrapped businesses. Think the SAFE that YC created, but more around profit or revenue shares.
Think this is a fantastic idea actually! I think there's a lot of projects out there that would benefit from this type of risk sharing in a way that would make sense for both parties.
> If this is interesting to you shoot me a msg would love to talk to others who are seeing this type of problem.
I'll definitely do that. Let me try to do a bit more research on my part too!
> Also, if you know Gumroad, they're building out a new product called Flexile.com that enables companies to hire contractors but also give them equity/dividends. It's not released yet, but may be worth looking into and getting on the waiting list. May or may not solve this exact problem but it's in a similar realm.
> The speed of history is increasing with each new generation after all.
This is the only statement in the post I honestly disagreed with. Anton is trying to talk about how his coworkers have lost historical perspective and that he, because of the geopolitical situation of the space in which he was born, has more historical perspective and therefore believes that everything might got s**. It's a very valid argument.
Yet, I have 2 questions:
- Doesn't the fact that there's a large group of people in the world (in North America, Europe, and other places) that believe in the stability of the system indicate that maybe they're actually experiencing history at a slower pace than their ancestors?
- More importantly, isn't the intent to predict history by claiming to understand a change in the way it operates (in this case its speed) also a lack of historical perspective?
Otherwise completely understood the point + liked the idea.
Wow that would be awesome! Shapes/Records are definitely the #1 thing I'm missing from moving over from TypeScript.
I started thinking about this a bit and I came up with the conclusion that the single biggest difference between structs and shapes is really iterating over keys. I spent some time trying to create structs by which you could iterate over all the keys and all the solutions seemed clunky or inelegant.
We've been starting to use Sorbet at Figma and honestly it's been pretty cool! Sorbet is definitely not as good at TypeScript (yet?). It's more verbose, doesn't support things like recursive types and records (shapes are experimental), and it doesn't inspire the same confidence TS does but it's definitely worth it to add it to your codebase if it's big enough!
Also, it's fast! I'm in total agreement with the point made in the article. That makes a huge difference in developer UX.
For a lot of the people that get to that level of wealth, it was never about the money. It was always about something else. I don't think the Bezos, Zuckerbergs, and Musks of the world wake up every morning wanting to make more money. They find fulfillment in their work. The external recognition is not bad either.
I think you're right that some people who want to continue making money are mentally ill, but there are other reasons people continue working. For some, the money is just a byproduct.
China does absolutely scare the crap out of both it’s own people and people abroad, but economically it’s clear they’ve done a lot of things right over the last 40 years. The US could learn a thing or two from the communists when it comes to Capitalism.
Does anyone know a lot of personally who have personally done this?
One of my friends is travelling+working across western states, but he's the only person I know. Another friend tried going to Truckee (Tahoe) and eventually ended up back with his parents after a couple of months.
So far, I would guess this is happening but to a much lesser extent that what most think. It'll definitely be a trending in that direction though.
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.
> 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.
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.
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.
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!
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."
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.
There might be nothing available on this page right now, but wow is this useful. I recently started doing some macOS dev and realized that this is a pretty big limitation when it comes to my normal CI workflows. I know there are some projects that dockerize macOS but they did not seem simple to work with.
The air industry seems like a good example of just the right level of regulation: There's tons of competition, different pricing tiers with their corresponding levels of quality, and a lot of dynamism combined with a good set of consumer base regulations (24 hour cancellation period, for example).