Basically they were employed as futurologists.

Perhaps the mental model I should use is academic security researchers. Did they publish?

Agreed on using energy consumption and how many times do you reasonably expect to use it as important considerations.

Additionally you have to factor in the toxicity you introduce, especially with things like cookware.

An umbrella maybe a 1000 times (massive upper bound), but a le creuset pot I would expect to use 3000 times, and we eat the foot made in it.

It is such a flat road and relatively straight. There are lots, but ultimately limited use cases, compared to where busy roads go out there in the real world.

I also think every one of those workers under that bridge should be wearing some type of respiratory filter for their long term health.

Closure team have also deprecated a lot of the old tooling. Closue was ahead of it's time for sure and as someone who heavily used the Closure Library and Closure compiler in advanced mode, it is sad that it did not catch on. However using TSickle you can transpile Typescript into javascript which closure compiler uses for advanced optimisations.

no, I don't think this is accurate. You can have processes run on a device in the background, you can pair bluetooth to it, you can send data back with it.

The cache TTL on VOD is significantly higher, so your whole infrastructure needs to have a live origin, which gets hit repeatedly to get the latest fragments/segments from the origin, from multiple edges/midgresses. I find that our origin consumes an order of magnitude more CPU than transcoding and packaging for live once you have even a couple of thousand live viewers and when serving LL-HLS/ll-dash with a low fragment size it increases more. if you are latency sensitive then i between caching layers are not an option.

math requires something different than memory, it requires understanding and fluency in its variety of symbolic languages, which can only built with intellectually engaged work.

math requires an absurd amount of memorized techniques/patterns ... maybe that's what you mean by fluency?

of course these are rarely static (after all one can learn proofs of theorems without being able to solve any problem), hence the need for the "muscle memory" of how to apply these techniques to the particular patterns.

That is such a weird system of value. Obviously there are people who will do that.

The reality is that sex work happens, bringing it out of the shadows protects the most vulnerable people, mores have very little to do with this. As a society we should be protecting these people where we can instead of moralizing.

Delivery on web IOS specifically is the PITA. This post however uses CMAF and with IOS offering better API's for video from the next release there is a bit of hope that this protocol could be implemented without Apple needing to do it, once private relay on ios supports http3, all the bits needed to do this should be there.

The main thing we're waiting on is WebTransport in Safari.

Apple has committed to adding it, and there's already been some work on it in WebKit, but we don't know when it will make its way into a Safari release yet.

Apple accepts external PR's for Webkit right? Couldn't someone external implement it?

At the risk of them rejecting it and wasting everyone's time?

This is the main issue for me with webcomponents, they are not SSR friendly.

Do you want SSR for SEO, or for fast first interaction? Because if the latter, then arguably some form of webcomponents might be theoretically better optimizable by browsers than DOM-element soups.

> then arguably some form of webcomponents might be theoretically better optimizable by browsers than DOM-element soups.

Arguably they might be less optimisable than regular web frameworks, as they make it difficult to coordinate between different components on the page.

This is a good point, but I would counter, perceived speed of rendering from a user perspective is more important than time to interact with the app/site (a reasonable time to interact is however very important.

Good load order and only loading in the content and JS above the fold initially helps a ton.

JS frameworks are huge and I am still saddened that proper tree shaking and optimization got left by the way side in how the modern web has evolved. I worked with google closure in advanced modes and the closure components for a few years and the compiler was absolutely astounding (and the components designed with the compiler in mind) in code splitting, tree shaking and minimization.

Oh, google closure was absolutely ahead of its time!

Consider the approach this article suggests.

You want to have the tags and content appear in the web component (not rendered by JS) which makes it easily and immediately available to crawlers.

You can pre-generate them on the client though.