7777fps

They apparently have 300M daily meeting participants which is actually more impressive than this headline.

In general, yes.

Everyone seems to have their preferred style of coding, and it is an easy defence mechanism, when presented with anyone who tries and finds it wanting, to say that "Well they didn't do it properly".

You find that with Microservices vs Monolith, Strong types vs Weak types, Exception Handling vs Results, Agile vs Waterfall.

People fragment into camps which turn into echo chambers and it's easy to dismiss anyone who doesn't commit to that cult as being unpure and not worthy of being in the cult anyway.

If you want a serious answer is because peer to peer webRTC doesn't scale beyond two people.

If you have 4 people every client would need to maintain 3 streams, a total of 6 streams between all participants.

To have any kind of scalability you need a proxy in the middle that can act as a single stream to each participant.

This middlebox can also handle normalisation, interpolation and other useful features you might want to smooth things out when clients have connection difficulties.

Why don't we have a Free Open Source webRTC proxy server implementation? Because these days just publishing a protocol isn't enough for adoption; not to mention that proxying large amounts of data will incur a significant cost.

And that hasn't covered the need for authentication, which is yet another required service.

And if the proxy box is interpolating and gracefully handling frame drops, does that mean it will be handling gasp decrypted video traffic? Yes, it will, unless you want to move all that to the client and then have a key exchange happen not just at the start but a renegotiation every time someone connects or disconnects.

So you see it's not as simple as, "everyone just opens this URL, webRTC is a thing duh".

It's no longer declarative as soon as you've done that though; it's still a break in the declarative paradigm.

Don't worry, I'm not espousing lifecycles as a panacea or solution for the modern programmer, I just wanted to share that experience with lifecycle methods meant that I was less tripped up by the pitfalls of react lifecycles.

Less so than I've been tripped up by react hooks certainly so it's been a surprise that many here are describing them as being much easier and simpler than classes.

Classes had limits and some pitfalls but it's been frustrating that lifecycle methods have been retired and deprecated because sometimes they felt like the natural place to do something.

But that's great until it isn't.

You can design all the declarative things you want, but someone will eventually come up with a requirement that doesn't appear to fit a declarative structure, such as an event that fires 2 seconds after something else happens.

And so to resolve that you can construct state machines with transition states to get back to a declarative model, but those state machines can quickly become a bigger headache to maintain (yes, even with redux) than if you'd just been able to setTimeout from the component in the first place.

And you start with the best of intentions of re-usable components but find more things that ought to be owned by the component pushed up to the store and suddenly there isn't a neatly re-usable component but an empty shell of something that still needs the other half plumbed in manually every time.

I love the idea that you can abstract everything happening in an application to state and render reproducibly from that, but the reality is that it's really hard and time-expensive to do compared to jquery.

But that would be fine if the tooling was there. If React had a CLI like the AngularCLI it wouldn't be such a problem to add new actions, or new pieces of state, or new components.

But it doesn't, so each new component ends up adding a little more state into the state machine which ends up breaking types in far off places.

Now there's probably an assumption about how state is built up or how reducers are typed or how actions are defined that I'm missing some reason why this shouldn't be happening. But it is happening, it's the reality for the project I've been working on and it's a real headache.

I liked that model because as an ASP webforms developer the class lifecycle is easy to reason about, like a page lifecycle.

In ASP you wouldn't put initialisation code in the page constructor either, it would go in Page_Init, Page_Load, etc.

Of course the tooling there made it both easier to put in the right place and harder to edit the page constructor to stick it in the wrong place.

Then I agree completely, and must have misunderstood what was proposed by a handler. Typically a handler will launch an external application such as mailto, ftp, magnet, etc.

If we want to run code in browser there is WASM.

So is the proposal that it would it be beneficial to have a DOS-like OS or x86 emulator in WASM for running COM files?

Yes, that would be better and more sandboxed than dosbox running outside the browser.

Correct me if I'm wrong, I haven't used DOSBOX for a decade but doesn't it have the ability to access hard drives and mount them?

Given that, it's not much of a sandbox.

Or does that require intervention from the host system rather than auto-mounting home and similar?

A handler for executing arbitrary code. What could possibly go wrong?

Well yeah, either is fine.

Exactly, I think grammatically this would be correct:

Arsenal are winning

Arsenal is the best team in the league

It's contradictory (as well as plainly false ;) ), but that's English.

I'm not saying there's no effect I'm saying that weddings aren't special in that regard.

That's just as easily (or not!) answered the same as:

> So what about all the workers that cannot pay their mortgages now?

Thanks, that's it!

A good video and better than I explained it too.

The video says it's inspired by Taleb's Black Swan so I suspect I read it in that too.