The little model there helps us distinguish types of sites, and so the very first thing to do is to note that you probably aren't building one of these.
But let's say you are!
In that case, it might help you to know that I've consulted with 4 of the 5 teams you mention, and because they have high management maturity, they often make choices that look different than the stacks you're being pitched at JS conferences.
Outside the editing canvas itself (a 20+ year old codebase ported to WASM), Adobe realised they couldn't afford the overhead of using React the "usual" way and have moved to Lit-based Web Components for PS:
YouTube is made of Polymer Web Components, and before that (for most of it's history) was a server-rendered Python frontend with progressive enhancement.
Maps is built on the usual Google frontend tech (Closure Library, Soy, etc.), and while that means it's still lugging around a lot of legacy cruft, it performs because the team both works hard to keep it in check and that the tools started in an era that (correctly) assumed that CPU and bandwidth are not plentiful on the client.
Figma uses React outside the canvas, but their team also includes former browser engineers. They don't use it naïvely. Nor does Excalidraw, as the author knows where the (latency) bodies are buried.
In all these cases, the reason these experiences work well is management maturity, not tech. Strong teams that need to have deep local interaction respect the problem and usually make choices that go against the "HN consensus" because better user experiences matter more than in-group signaling:
I feel that there is a bit of miscommunication here. You focus your efforts on arguing against React. I do not disagree. I would love nothing better than to throw away React and embrace Lit or native web components for the heavily interactive sites with deep sessions. However, components is just a part of the story. There is also state management, client-side caching, server-side rendering with subsequent hydration, bundling and code splitting, etc. to think of — on which we are hearing little to no guidance from mature developers such as yourself, and, in absence of such guidance, have to fall prey to the twitter thinkfluencers from the js industrial complex that you denounce, but who promise some concrete solutions.
So, if you read the post, you probably saw this:
https://infrequently.org/2023/02/the-market-for-lemons/#fn-t...
The little model there helps us distinguish types of sites, and so the very first thing to do is to note that you probably aren't building one of these.
But let's say you are!
In that case, it might help you to know that I've consulted with 4 of the 5 teams you mention, and because they have high management maturity, they often make choices that look different than the stacks you're being pitched at JS conferences.
Outside the editing canvas itself (a 20+ year old codebase ported to WASM), Adobe realised they couldn't afford the overhead of using React the "usual" way and have moved to Lit-based Web Components for PS:
https://web.dev/ps-on-the-web/
YouTube is made of Polymer Web Components, and before that (for most of it's history) was a server-rendered Python frontend with progressive enhancement.
Maps is built on the usual Google frontend tech (Closure Library, Soy, etc.), and while that means it's still lugging around a lot of legacy cruft, it performs because the team both works hard to keep it in check and that the tools started in an era that (correctly) assumed that CPU and bandwidth are not plentiful on the client.
Figma uses React outside the canvas, but their team also includes former browser engineers. They don't use it naïvely. Nor does Excalidraw, as the author knows where the (latency) bodies are buried.
In all these cases, the reason these experiences work well is management maturity, not tech. Strong teams that need to have deep local interaction respect the problem and usually make choices that go against the "HN consensus" because better user experiences matter more than in-group signaling:
https://infrequently.org/2022/05/performance-management-matu...