One cool thing about working on a web framework is that the tools you use to build a feature might eventually adopt the feature itself. 5.5 years later, in this case.
By the end of 2024, you’ll likely never need these APIs again:
• useMemo, useCallback, memo → React Compiler
• forwardRef → ref is a prop
• React.lazy → RSC, promise-as-child
• useContext → use(Context)
• throw promise → use(promise)
• <Context.Provider> → <Context>
A nice thing about working on the same project for many years is you’re forced to deal with the consequences of bad decisions you made long ago. Really sharpens your instinct for spotting technical debt before it starts accruing.
Tip when evaluating libraries: check if it's blazing fast. If it's fast, but the README doesn't specify whether its fastness is blazing, keep searching. Often you can find a similar library that does the same thing, but blazingly. Blazing means good.
How to Code Split with React Suspense
Coming soon to open source.
We're already shipping a version of this to Facebook employees. The code is sooo much nicer than before.
If you use React, you should be using a React framework. If your existing app doesn't use a framework, you should incrementally migrate to one. If you're creating a new React project, you should use a framework from the beginning.
If you call yourself a programmer, you must be proficient in my particular domain of expertise. I can’t overstate how fundamental it is.
For everything else, it’s totally fine if you have gaps in knowledge or experience! You can learn as you go. Tell the gatekeepers to shove it.
There's a real debate about whether Facebook should fact-check, suppress, or de-platform demagogic politicians. Personally, I think we should be doing at least the first two.
But to me, there's a deeper issue: Facebook is breaking society, and we're not doing enough to fix it.
Advice for anyone who’s interested: don’t worry about which technologies you need to learn to advance your career. You’re smart; you’ll figure it out. Instead, start by focusing on the problems you want to solve, and the things you want to build. The rest will follow. Good luck!
e2e tests continue to be underrated. Yes, they are slower to run than unit tests, and usually take longer to write, but a good e2e test lasts forever, no matter how often you change the implementation. It's the only kind of test I want to write anymore. It's worth the extra work.