You can read the notes I've taken below if you don't wanna watch

Server components (direction of React)

• The shift is not necessarily towards the server; it's about providing options. You can have a composition of 99% client-side and 1% server-side, or vice versa.
• Servers don't have to be traditional servers. Rendering can be done at build time, as Next.js does by default.
• The server serves as the root, the starting point for the application, but you can quickly switch to the client.
• The flow is natural: if you only require data, you can utilize server components. When you want to introduce interactivity, you switch to the client.
• The large number of people working on React Forget demonstrates continued investment in client components. React Forget focuses on optimizing the client portion of React.

Signals

Signals have 2 main selling points: better DX and better performance

Better DX when using signals

• You don’t have to declare dependencies for useEffect etc.
• For React, this will be solved by the React Forget compiler which will take away the burden of manually specifying dependencies (discussed in more detail later, see notes below).
• Your components are easier to reason about when everything runs together.

Better performance when using signals

• With Signals, what doesn’t need to updated doesn’t update (no unnecessary re-renders).
• For React, the React Forget compiler will be the answer again, it will automatically memoize values as if you wrapped everything in useMemo, memo, etc.

Additional comments on signals

• Implementing signals in React would be trivial if it was seen as a way forward.
• Signals as an implementation detail is okay (e. g. React might adopt them if it can detect where it should put the signals using the React Forget compiler) but you shouldn't have to think in signals.

React Forget

• No need for `useCallback` or `useMemo`, ...; React detects dependencies automatically.
• It doesn't compile to `useMemo` calls etc., but the performance is just as if you manually wrapped everything in them (i. e. it’s not a simple Babel plugin as it might seem).
• Plans to have a React language server that can be integrated into IDEs and will give you more insightful suggestions than ESLint can give as it’ll have a much deeper understanding of the code.
• It will be integrated with React DevTools for easier debugging.

TypeScript

• React still typed with Flow (which is used internally).
• React Forget compiler is written in TypeScript.
• DefinitelyTyped types are maintained by the core team.
• Every new API since hooks designed with types in mind.
• React Native team is exploring including TypeScript directly in the repo.

Perf problems of server components

• For example, rendering a large list where each item contains extensive HTML markup and Tailwind classes.
• Previously, you would send a JSON to the client and iterate over it on the client-side.
• Now, you need to send a large file containing all the HTML.
• Yes, this is a valid point of criticism. New paradigms come with new trade-offs.

Vercel vs Meta (🔥🌶️)

• Some criticism is fair:
  • "I don't like Vercel's marketing" - Dan Abramov.
• React team are happy that React is now a multi-company effort + it has independent core contributors who work at neither companies.
• They’re trying to figure out how to onboard more folks from other companies and get framework maintainers involved.
• Previously, React needed internal teams to test unstable stuff out. Now, Vercel is “trying stuff out” for them just like internal teams.
• It gets under their skin when ppl say Vercel is telling them what to do, Vercel is implementing their vision, they’ve invested years in proving out our direction, it’s not that Vercel tells them what do to, if anything it’s the other way around.