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.