hiphipjorge

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.

Super interesting. Will go and check it out!

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.

I see it completely differently.

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.

I think that's a valid opinion.

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.

Creator of Watercooler here.

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.

Screensharing in Messages does exist, but it's convoluted. This experience is (in my very biased opinion) way nicer.

Exactly! Give it a try and let me know what you think.

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."

The two mains reason right now would be because you can do screensharing and because this is not tied to your iCloud account in any way.

In the future, we will probalby have other clients other than the macOS one.

Hi HN,

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.

Tech favors the young. For people with more than 15 years of experience, there’s practically no correlation between years of experience and income (corr < 0). After 15 years of experience, you either retire, switch to management, or change career.

I’ve never quite understood the dynamics of this. Do people mostly self select? Is there organizational pressure to do this? Is the constant rate of change in terms of technology too exhausting for people to keep up (More senior engineers are def capable!)? In my experience I’ve seen a it of all of these, but honestly not enough examples to see clear patterns (...precisely because I’ve only worked with people in their 20s and 30s).

Slightly unrelated, but does anyone actually use DO in production?

We're on GKE and with their new Kubernetes offering, I've considered switching but just haven't talked to a single person who uses it in production at work.

Is it able to do something "dumber", like just adding a class to the <body> element to then modify what shows up with just CSS? (Tried finding documentation on your site, but seems like it's not a thing).

This is a test. tensorflow.

Hi. Jorge from Basilica here.

We don't have any concrete plans to tackle this right now but it is something we're definitely mindful of. Thanks for the links! We'll be sure to go through them.

Hi, Jorge from basilica here.

Yes. We intend to run this as a cloud service API for now.

Hi, Jorge from Basilica here.

Our bet is that the simplicity of using Basilica will provide a much easier experience that doesn't require complex infrastructure and training and will provide very good results thanks to transfer learning. The amount of data needed for this is also much smaller than if you were training a model from scratch.

The name "processing" isn't great though. It can be difficult to remember.

I interned with Ben Fry about 6, 7 years ago and think I remember him saying that he regretted naming it "Processing" because of all the reasons people mention here (google, it's a verb, sounds a bit generic, etc)

Maybe documentation should include uses cases? Newer users to npm + node might think this does something different. Just a suggestions.

I guess there is the "files" and ".npmignore" which handle these, but they don't seem to be widely used in the community.