This is really cool, but I wish it was sorted by date. It's difficult to see the narrative since it jumps around.

Web Streams do feel rather painful compared to other languages. The author ends up basically describing kotlin flows which are great and I wish the web would adopt that model (Observables wanted to be that but the API is much worse than flows in practice).

Fwiw the original Streams API could have been simpler even without async iterators.

  interface Stream<T> {
    // Return false from the callback to stop early.
    // Result is if the stream was completed.
    forEach(callback: (chunk: T) => Promise<boolean | undefined>): Promise<boolean>
  }

Similarly adding a recycleBuffer(chunk) method would have gone a long way towards BYOB without all the ceremony.

If we're optimizing allocations we can also avoid all the {done,value} records and return a semaphore value for the end in the proposed API.

(Web) API design is really difficult and without a voice in the room pushing really hard on ergonomics and simplicity it's easy to solve all the use cases but end up with lots of awkward corners and costs later.

Async call stacks is an optional feature when the devtools is open. There shouldn't be overhead from await like that?

It's awfully hard to know, and I am not myself sure.

On the inside, but not on the outside. Web Components standardize the interface for components to interact like MCP standardized the protocol but the server itself can be in and language. You can't just mix Solid, React and Vue components together but you can use any web component in a Lit app.

You joke, but a substantial portion of the Blink engine was (re)written in garbage collected C++ to a similar effect.

The slowness in a React app is not the DOM. Typical apps spend most of their time running component code long before any DOM mutations are committed.

If you look at DOM benchmarks it's extremely fast. Slow web pages come from slow layers on top.

It depends on the app. If the app has many hundreds or even thousands of DOM elements, there's no way to make that work smoothly with React or any other library or framework. Then a canvas based solution can fix things. I know, I've had to fix slow React apps.

I wish they would go after the fake spinning wheel discount pattern and the "app exclusive" or "better in the app" pattern. That's all a way to get people to install apps that will then bombard folks with notifications or slurp data off the device.

Reading the fingerprint.js is interesting, it's not just the thousands of extensions. It looks like it's also probing for a long list of webgl extensions, fonts, and other capabilities. There's recaptcha v3 references in there too.

Perhaps an overly aggressive attempt to block bots.

This is never an issue with number of engineers, it's an issue of business priorities.

Large tech companies have plenty of engineers to fix bugs, but most of them are on projects trying to 10X things instead of paying down debt.

Apple used to be unique in it's immunity to it, they even shipped an OS update claiming it was only big fixes and not features which is unthinkable these days. Over time there's much less focus on polish from them though.

Airbnb doesn't really follow that guide internally anymore. There's a lot of weird in there. I wish they'd publish the actual internal style and lint rules instead.