Unpopular opinion: Alex has a point. Defaults matter, even when the developers don’t work to fix perf.
This is why hydration should be non-blocking and progressive, and why it needs to be easy to move logic from client to server without rearchitecting your app.
This is why hydration should be non-blocking and progressive, and why it needs to be easy to move logic from client to server without rearchitecting your app.
This is why some React features take way too longer to release than the community (or us) would have liked preferred otherwise. We have a responsibility to make systemic improvements — even though they aren’t a part of the JS framework discourse.
His framing is frustrating when directed at individual developers.
When directed at library authors, it makes more sense — although if he directed its criticism at jQuery, it wouldn’t be able to fix any problems.
Here’s what’s interesting about React though.
When directed at library authors, it makes more sense — although if he directed its criticism at jQuery, it wouldn’t be able to fix any problems.
Here’s what’s interesting about React though.
React of today can’t fix these problems either. It’s in the same position as jQuery. Because it doesn’t have the power to change how you import things, fetch data, split code between client and server.
However, you can also approach these problems holistically. They’re all interconnected. How you fetch data affects how you express loading states. How you express loading states affect how you split code. How you split code affects how hydration works. And so on.
That’s when we approach data fetching in React, we don’t just “add support to returning Promises from render” and call it a day. We know the problem is much deeper. We need no waterfalls, no loading code until data says it’s used, no “load everything before you can use anything”.
So yeah, we have more things to figure out with Suspense and data fetching. And we are taking the time to do it right. Now you know why.
Two traits of a good architecture:
1. It should nudge you to do things in a scalable way by default. You should only pay for what you use.
2. When something gets slow, there should be a straightforward way to fix it.
Solving this generally for UI is hard, but worth the effort.
1. It should nudge you to do things in a scalable way by default. You should only pay for what you use.
2. When something gets slow, there should be a straightforward way to fix it.
Solving this generally for UI is hard, but worth the effort.
I should note we’re not doing all of this work alone. It’s a collaboration with the Relay and Next.js teams (both of which pioneered some of the approaches we rely on), and folks from the Google Chrome team.
These four slides from @sebmarkbage’s talk three years ago are still our roadmap. We’ve made a lot of progress but it’s not finished. 
All of that being said... it’s people who you don’t see shouting and proselytizing on Twitter that actually do the work. Including at Google. Big thanks to them.
