The React Core team is joining the Facebook employee walkout in solidarity with the Black community.
Facebookʼs recent decision to not act on posts that incite violence ignores other options to keep our community safe. We implore the Facebook leadership to
#TakeAction
.
Therefore, I'm joining Vercel starting next year!
I'm lucky that I'll get to keep working on React together with the amazing teams at Meta. I'm also excited to work closely with the equally stacked team at Vercel.
There’s a lot of work ahead but React at Meta is on a great trajectory, with greater investment than ever. I've learned so much after 9+ years. Now, I'm excited to learn even more about wider usage of React and continue helping the ecosystem grow.
This is a little known React optimization pattern. React rerenders this component deeply when updateX is called, and since children can't have changed, it automatically bails out of trying to update the children. No need for sCU, memo, etc.
Evaluating tech is really hard. We come up with clever arguments to justify our choices to ourselves and others but, let’s be honest, it mostly ends up being pattern matching of previous experiences and personal preference.
I don't think React has become popular because it's more "intuitive" to people. It's not an iPad that toddlers just naturally interact with. It has become popular after a network of teachers taught the principles and patterns that empower people to solve complex problems.
Saw some sassy points against React's immutable reactivity model and comparison to other approaches. :) Wrote down a brain dump on some notes that I don't think have properly been addressed around the tradeoffs.
Hydration in React was originally not built for SSR. It was because IE6 had a really slow DOM API but relatively fast JS strings. It was faster to concat HTML strings on the client and then "hydrate" it. This equation later changed as more refs were used and the DOM got faster.
My philosophy on abstractions (like React components): If your abstraction works in 9 out of 10 cases. That's a good abstraction. If it's insufficient in one of those cases, then copy/paste (i.e. decompose into its pieces) and tweak it for that case. Don't change the abstraction.
You might want to check the build output of your Webpack. If you see something like react_default.a.createElement(...). Note the extra .a. That might mean you're using `import React from "react"` which adds a bad getter in Webpack. Instead use `import * as React from "react"`.
Rebase stacked diffs. Don't merge.
Write tests. More on the E2E side than unit side but not the extreme of either.
Stay away from classes and inheritance. It's never better.
My dad finally passed away last night. He has been in hospice for a while so it was expected. He did get COVID in the end, which he cleared, but it probably sped up his existing symptoms. I'm glad I got to see him several times and prepare for this day.
The anti-React sentiment in Web Standards circles for the past 10 years - while it being the primary defacto way people build for the web - needs some real self-reflection. Even if not the future. What a waste of butting heads and wishing it away for 1/3rd the life of the web.
Atomic CSS is surprisingly effective performance wise (if done well) which is why I'm all about it lately. It scales well by flattening out both in terms of number of rules and incrementally loading rules. It minimizes recalc of the whole documents. It allows for local scoping.
Post-Google cheat sheet:
MoMA:
@glean
Buganizer:
@linear
Workday: Workday 😱
Blaze:
@turborepo
(you can do bazel but do yourself the favor)
Rasta:
@statsigio
Gmail: Slack
Google Docs:
@NotionHQ
Gaia: a world of painful disjoint identity models
I hate rewrites but what I hate more is delaying the inevitable. When I joined Vercel I saw that Next.js had a good foundation but there were some changes needed. Rather than delaying the inevitable we started App Router two weeks after joined.
My first contribution to React was the heuristic for the key warning. IMO it has worked fairly well to avoid a set of problems. BUT it has given the misinterpretation that only lists need keys. You need keys on single items too. In a master/detail, the detail should have a key.
My biggest lesson from 10 years of React: Intuition is overrated. Intuitions in programming are not innate but based on previous experience. Intuitions change over time as the industry moves on. New lessons echo through it. Each next generation will have different expectations.
Rule
#1
of debugging errors. Always look at the first printed error message first if there are multiple. The rest might be a consequence of the first one.
It can be surprising how often the solution is just to scroll up.
Build good error handling the first thing you do. It's hard to find all the places you ignored after the fact, and it helps you along the way when you develop the main thing because you'll inevitably have errors while doing it.
Nested routes/layouts was a huge DX improvement missing in Next.js but it's absolutely critical for RSC to enable subtree fetches and streaming! It's a big piece left out of the original Server Components demo. The new Next.js router is designed for RSC.
📣 The Next.js router is getting a major upgrade!
◆ Nested routes / layouts
◆ Client and server routing
◆ React 18 features – startTransition, Suspense
◆ Designed for Server Components
◆ 100% incrementally adoptable 🤯
Expect an RFC very soon 👀
Following iOS engineers learning about SwiftUI and rediscovering all the things the web ecosystem has already learned is interesting. First I'm like "aww that's cute, maybe you should get out more...". Then I get jealous of the excitement... I miss that new library optimism.
This is from an internal perf investigation I did. We also see similar numbers in all real significant apps. This is the percentage of all JS time and about 5% is the time spent creating the actual DOM nodes so it’s inherent. The framework code is about 8%.
React has lazy evaluation for components. It comes with some overhead but gives us things like suspense, memoization, time slicing, parallelization among children, lazy computation. Hooks are eager and will undo all of those benefits.
I don't know who needs to hear but Promise ticks are not cheap. There's some baseline overhead to just creating the objects, then callback etc. That's only if you don't actually use your stack for anything. As soon as you have lots of in-progress work on the stack it's expensive.
I can't disagree strongly enough with some of this style of narrative growing. Personally, my goal is to make tooling that delivers high quality experiences to lots of device classes and easy to build so that we can raise the bar even for small teams.
It’s beginning to feel like the HTML-CSS-JS vs JS-JS-JS war is a class war. If your project has a budget of millions, “of course” you should use a complex build process and a JavaScript framework that handles everything (according to the folks who believe this). The pressure…
We’re seeing numbers on mobile that suggest that JavaScript can be faster than native end to end due to I/O costs for loading the code from disk. On web this matter even more because the network cost. JS haters need to embrace I/O over CPU perf if they want to win.
I'm getting pretty convinced that testing that relies on asserting on implementation details like what react-test-renderer, react-test-renderer/shallow and enzyme does breaks the notion of semver. They mean that every change to the internals of a component is a breaking change.
A new developer step through code to find a bug and fixes it. A senior developer guesses what the bug is, spreads a word of warning and was wrong. An experienced developer steps through to find the bug and explains what the bug is how to systematically avoid it in the future.
I'm so excited for the collaboration we're doing together with the Chrome team. The work we're doing isn't limited to the React model and, better yet, it's focused on making an even better React than can be made today. Next gen instead of stagnating.
I love this thread, because we already started. :) We're working with the React team to design display locking, scheduling, and virtual scrolling. This is going to make the next rev of frameworks even more awesome. Chrome will be
@reactjs
conf, hit me up with all your ideas!
The worst part of “tech leaderings” is being a bad cop on code reviews. You don’t want to push against progress but need to uphold the quality bar. You don’t want people do changes just to comply with the reviewer. Feedback needs to be internalized so it gets easier over time.
Is RSC like PHP? No, because navigations can be done client-side with preserved state, animations, playing videos and more. In that regard it’s more like better Turbolinks. RSC can also refresh your data in place after mutation, focus or continuously using diffing.
SwiftUI is very impressive. Sure, lots of tradeoffs e.g. due to type system and language runtime. There are also some ideas in there that follows a path we opted not to take but others have. I can see why you'd want to tho. The team has really done their homework.
Google Drive just deleted a years worth of my notes due to a faulty upgrade to "streaming" file sync and back. Never felt so much lost of trust in product. One job.
I worry that the biggest threat to the Web/JS might be bitterness, arguing, cliques, combativeness and overall lack of unified optimism for the future. I hear about more and more people driven away by bickering. We better do better.
This is also how most dependency injection in React apps should be done. Not Context.
Import a named default value from JS. Override it in package.json imports.
Big update for TypeScript users!
🚫 Stop using compilerOptions
#paths
✅ Start using package.json
#imports
package.json
#imports
uses Node.js conventions, solving a specific pain point for monorepo folks.
Video coming. Too excited, had to insta-tweet.
Stay tuned.
Next gen programming languages should be judged by their ability to fix mistakes in the language while not forking
its ecosystem. It should be a primary built-in feature that every other feature is probably wrong and cheap to change.
It's so amazing that we can launch JSX fragment syntax extension in coordination with Babel, TypeScript, Flow, Prettier and ESLint! So much ❤️ and collaboration in the JSX community.
My top perf tip is to avoid multi-pass rendering (e.g. setState directly in use(Layout)Effect). It can be useful to adjust based on computed layout but if it can be avoided, it's always better. Even if it isn't a big perf issue, removing it makes profiling the rest easier.
The three things you need to get right for a good mobile app experience is 1) navigation drawers 2) infinite scrolling lists 3) positioning of the on-screen keyboard relative to other content. The web currently makes all three difficult.
Next.js Cache on Vercel changes the equation
Many backends we have to talk to are slow. Even slower if they're far from the Edge POP. Many are frankly just unreliable. Static has been the key for making many consumer sites reliable and fast.
One day, React will switch to only ESM. We won't do it yet because it would be very disruptive to the ecosystem because you have to convert any library to import through ESM. However, if everyone else could do it as much as possible, that'd be great. React has to be last.
If you like MobX, I highly recommend following along
@mweststrate
’s work on Immer. While MobX is pretty far removed from the vision of where we’re going with React. Immer is dead on.
This week has been a big week for async React. I feel bad for how long it has taken to get to a deployable state. It’s kind of embarrassing to peddle vaporware. I’m more excited about it than ever.
"Solved problems need constrained APIs. Unsolved problems need unconstrained APIs." Paraphrasing
@cramforce
. This really resonates with how I think about framework design. With time you learn a bit more about the right way of doing things, but constraining too early is fatal.
Don't use Context if it's not different per subtree, use module state (e.g. global store) or compiler level (e.g. alias modules per platform in webpack or file extensions like RN's .ios.js) if it's dependency injection.
The way I think of the new Next.js routing with React Server Components, is that it's like an MPA Island architecture but with like none of the downsides. It's very similar architecturally but it can upgrade to an SPA.
Render should be pure. It should have no external side-effects. The biggest challenge for React going forward is that we really meant it. "Yes, but..." As an ecosystem we'll have to find and teach patterns to replace the ones that break this rule. This is going to be frustrating.
TIL how harmful it can be to productivity to have people follow your every move. It adds a lot of stress to the process. Seems better to move release orchestration to a private repo.
The release of React 18 and adoption of concurrent features in Next.js will put us in a really good state to deliver on a range of features on top of that stack. Now is the time.
Let's bring that innovation to the broader ecosystem.
I don't get why
@PrettierCode
is still controversial in some places. I've worked at a wide variety of places before FB, and within FB, and it would be hugely beneficial at all and with little downside. If you don't, why not?
One thing I like about APIs without property names is that I can code in non-English.
🇸🇪
import {useState as användTillstånd} from ”react”;
var Komponent = () => {
var [antal, angeAntal] = användTillstånd(0);
// ...
}
I know stale closures are tricky in React with Hooks. They're also in Server Actions. That said, that is also a feature. It's a snapshot of the intent at the original time of render.
Tbh, I love it.
For history revisionists, I went to Vercel and changed Next.js. I didn’t change React. The React stuff was already there pretty much. I feel like I don’t get enough blame. lol.
Immer looks like a good project. I’m pretty convinced that temporal mutability like this is a good model. As long as it is wrapped in a scope like a reducer, render function, etc.
Our industry is too susceptible to thinking that newer is better and new things are too incentivized to showing off the new things that are better rather than the tradeoff being made, or the lessons that were forgotten. I’ll try to not do this with React Concurrent Mode.
The architecture in Next.js 13 is more of less the architecture that Facebook used with React for most places outside of ads from the start. One thing that always bothered us was that there was a different architecture that was associated with React that grew organically.
I highly recommend against useMount/useUnmount/useEffectOnce style helpers. I know useEffect is kind of annoying but it’s supposed to help write resilient code. It helps short term it is swimming upstream. If you know the risks, sure, but a lot of people get tricked by this.
Yawn: Yet another state manager or different way writing CSS.
Interesting: Framework for moving state to the server.
Exciting: Actual UI libraries.
More UI Libraries plz. Less Puzzles.
📢 Announcing React Aria's date and time pickers!
👑 Calendars, date and time fields, and range pickers
💪 Custom granularity, unavailable dates, and more
🌍 International – 13 calendar systems
♿️ Accessible
📱 Touch friendly
🎨 Bring your own design
In the Swedish army we used the term "MÖP" as a derogatory term for someone who shows a worryingly strong interest in the military and weapons. That's a red flag. I feel like we need this in software. One can be overly interested in software that you lose sight of its purpose.
Tools that hold the line and don’t let things get worse are so powerful. E.g. test coverage, type coverage, bundle sizes, perf metrics, etc. Much of APIs are about how not to break something that was once tested. Under-invested in open source and business critical in Big Tech.
Security and privacy is a passion of mine. It has to be taken seriously. A top priority. It shouldn't be left to learning by mistakes but part of learning a new framework. I wrote some thoughts on how I think about the security model in RSC with Next.js.
Learn about security protections being built into Next.js.
View our guide for auditing applications, including security best practices for Server Components and Server Actions.
2019. The React team came to London to finish the React Hooks release and meetups.
@timneutkens
took the train from Netherlands to visit the office just for a day. I ranted about how Next.js needs layouts that update deeply in place - from the server for scale. We finally did it.
Most of what I do is just slight refinements of ideas from other people I work with. I feel fortunate to work with so many inspiring people. I hope what I add is net positive. 🤞🏻
I’d like to think that we’re not just making it easier to build UI but making it easy to build better UI. For example, we’re exploring features to build UI paradigms that are not even in common use yet. We suspect that the reason they’re not is because it is hard to build.
The interesting thing about TailwindCSS isn’t its syntax, its compiler, atomic css being good for perf or its various use utilities. It’s that the was packaged well and at the right time to create a community and a de facto standard. It’s necessarily dependent on its popularity.
✅ Type safety
✅ Memory safety
❌ Cache safety
The next property missing from main stream programming languages is a guarantee that something can be memoized and that the programmer didn’t forget to encode any inputs to the cache key. It’s a common and highly risk mistake.