Those verbs (reduced, decreased, increased) all assume the situation was "bad" already. Avoiding that in the initial design is what's poorly rewarded.

Building a system that's fast on day one will not usually be rewarded as well as building a slow system and making it 80% faster.

Yes, and ironically there are promotion ladders that explicitly call out "staff engineers identify problems before they become an issue". But we all know that in reality no manager-leader is ever going to fix problems eagerly, if they even agree with someone's prediction that that thing is really going to become a problem.

Have you used a MacBook as a daily driver since the M chips came out?

No. I'm looking to get one with 64GB memory for local AI models. The worry is the keyboard experience on the MBA isn't as good as the MacBook Pro.

The keyboard and touchpad experience are nearly identical between the two... not nearly as good as old IBM Thinkpads used to be, but that's a trade with IMO the much better touchpad experience on Mac.

That said, I just don't think I can keep buying Apple hardware, just not a fan of the company... I only begrudgingly use Android as there isn't a reasonable, more open option.

I'll probably stick with my M1 air for personal use a couple more years then pass it on. My daughter is still using my now 13yo rMBP with 16gb/512gb. I wish the ram and storage upgrades on mac weren't so overpriced.

At current rates they aren’t overpriced at all. Frankly I’m surprised we didn’t see a big increase in cost with this generation.

Apple has their supply lines locked in a few years ahead of time... they likely won't see downward pressure for a couple years still. Not that they might not still take advantage... though downward sales pressure is a trade off too.

I’ve used both extensively and there’s very little difference in the keyboards between an Air and a Pro.

The difference in displays (Pro much brighter) and size/weight (Air much lighter) are much more significant considerations, IMO.

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.