Sounds like great news, very much looking forward to playing with that!
I have been trying to use transitions wherever possible and did run in some occasional limitations. I was on the verge of making a small PR to make async transitions easier with fetchers.

It's definitely a tricky ethics issue. Some could argue it's ok to take their money to do something good with it. Imho and I believe people like Rich do as well, it is only worth it if they have full freedom on their project. e.g. a donation with no return.
Being on payroll may complicate that?

I think because events allow better decoupling, at scale they actually may allow better code-splitting and several teams working on the same app concurrent?

Love this! Even good just to let some time for hotfixes if necessary 😆

I've read quite a few posts on tech debt but had never seen it framed that way. Definitely easy to grasp.

Because most client devices are now battery powered some (or all) of the time, we "get" more CPU every year, but when that only turns into more cheap, slow devices being sold, *the average speed can regress*.

And that's exactly what happened over the past decade.

I still prefer this unfortunate situation of a benevolent corp to underfunded OSS. If Vercel can afford that then I'd like FAANGs to fund hundred of OSS people full-time.
I know they do open-source a lot of stuff but it tends to be the public version of something they use internally, not the same.

Agree. Hiring full-time multiple maintainers of multiple frameworks sounds like a good boost to level up the whole ecosystem. Particularly welcome that they spend money on this instead of hiring more AI programmers like the market probably tells them to.

Sure it wasn't a great UI, but they just made it worse by adding more interactive tidbits.
I can hear @infrequently.org in the background saying "this is everything that is wrong with React-driven frontend development"
I guess it's still a beta and they'll fix some bugs but it's a shame.

Only alternative left I could find is to have a piece of state that you pass to `useBlocker` and set to true just before the submit starts, so you can be sure the blocker is triggered. Which is very unintuitive and not really documented/in tutorial.

A way to limit it is to use pass a boolean as an argument but then I can't use the more powerful callback arg.
You can't be smart, checking the navigation state to apply the callback argument, because well... the navigation has started so it's too late to block it.

Rules of hooks of course disallow you to call it conditionally. I had to dig the implementation to see that it just silently uses the last entry, but I don't think there's any guarantee about what's the last, since it's added to the queue in an effect.

I've read a couple horror stories about how forceful and non-transparent they are when they decide you belong to the enterprise category of billing. Definitely makes them scary for anything else than side-projects