Dan is back. He gave his best talk to date. Obviously I made a video about it.
If you don't understand server components yet, you should watch this. Even
@RyanCarniato
learned things from it 😳
i’m sorry for annoying so many people. when working on explanations, i find it helpful to throw things against the wall and see what sticks. but i also find the whole “if you have to explain it, you failed” sentiment hugely demotivating. i’ll take a break and focus on posts
React Server Components does not require a server (and never has). i get that this is confusing but i’m at loss what to do. people keep repeating that it does and speak about it as if it were a true fact. can someone spread the word pls?
@nomadtechie
@nulladdict
@ryanflorence
@deriegle
if i may offer a correction, despite the (perhaps unfortunate?) naming, RSC *does not* require a server. by default it runs at the build time. you can think of the “server” part as serving a similar purpose to webpack loaders or build scripts — but packaged into components.
today’s a big day for the social network that must not be named! we’re opening up registration to everyone (bye invites), but i’m just as excited about
@martinkl
’s paper about b*****y’s architecture finally being up:
turning the social media inside out :)
@kentcdodds
yeah. also <Context> will likely switch at some point to meaning <Context.Provider>, so it'll just be
const ThemeContext = createContext('light')
<ThemeContext value="dark">
...
</ThemeContext>
function Stuff() {
const theme = use(ThemeContext)
// ...
}
i write for anyone who’s willing to empty their cup and come with a beginner’s mind. then it’s joyful. if you don’t find joy in playing with concepts and trying to look at familiar things from an unfamiliar angle, my shit isn’t for you. if you do, stay tuned — more coming
this looks like a spiritual successor to RNW, but approached from the other direction (web APIs won, so RN is building support for a strict subset). essentially, you’ll be able to render a <div> in RN. compat table reflecting current state:
We just published the first beta for React 19! This beta release is for collecting feedback and preparing libraries for the next major version of React.
To see what's included, check out the release post:
ok new rules
your UI travels between at least two programming environments. they’re now called server and client. no matter what they machines they run on
forget “static generation” or “build-time generation”.
that’s just server! but you run it early
it feels strange and surreal to be excited by something so many people i know and respect are cursing or making fun of. almost makes me doubt my sanity. having distance from it (like it’s not even my job to care) makes it even weirder
when it came out, react felt like a refreshing alternative to the traditional mvc. i liked different mv-whatever styled patterns before, and react blew my mind because all patterns disappeared. it’s just functions calling functions. without even exposing their return values. what
watching the commits in Next.js repo it’s wild both how far ambitious the App Router vision is (small API surface area allowing very powerful combinations of concepts) *and* how rough the implementation still is. this is maybe like React a year before it got open sourced. WIP.
someone pls make a video about this because i’m tired of explaining it. “use client” can’t be a “default” for the same reason a PHP/jQuery program can’t “start” inside jQuery. there’s the outer layer and the inner layer. the outer layer has to be the starting point!
@PatrickJS__
@t3dotgg
it’s not a “default”, it’s a “root”. the data flow starts at the server/build — it’s the part of the code that *has to* run earlier because it determines what’s rendered next. it’s the same reason HTML is the “outer” layer and the <script> tag is “inside”.
Presenting danGPT: I pulled every post *ever* from
@dan_abramov2
and built a RAG-based GenAI.
It’s a silly side project that may be helpful. Let me know if it is, and if you’d like it open sourced and taught in a YouTube video or similar.
👉 Try it:
this attitude in general alienated me enough that i stopped blogging for a few years. but when i went to a few confs in person, people kept coming up — mostly young devs — and said they loved my posts. so yeah this will be for those kids. i don’t care about yr fights
i’m beginning working on my talk on atproto. atproto is a slightly different way to build web applications. (it is relevant to native applications too. anything with a backend.) i’m trying to figure out how to talk about it. would it make sense to workshop some of this in public?
htmx essays are great. breath of fresh air. i don’t agree with some stuff and i don’t click with all the framing it uses, but if “hypermedia” is what makes it resonate for people, that’s wonderful. htmx advocates some of the things we’ve been trying to say—better than we ever did
many ppl are dunking on this with self-assured “dev machines should have no prod access” but like.. at FB they always did, and it was great. there were many layers of protections (you used a privacy-aware data layer) and i don’t recall it being possible to drop tables but still
On February 21st, Resend experienced an outage that affected all users due to a database migration that went wrong.
Here's a summary of what happened, how the incident was resolved, and the changes we're making moving forward.
in RSC the “server” and the “client” don’t refer to a machine. they refer to pieces of software — the server and the client of the React protocol. you can think of it as virtual DOM over the wire.
frieren is so beautiful. i’m on the second episode and already enjoying a lot.
not sure if intentional but the outro title sequence is a very accurate visual depiction of what it’s like being on acid
V3 IS HERE 💥 We are excited to introduce our first model capable of producing radio-quality music. v3 allows you to make full, 2 minute songs in seconds and is now available to all users. Try it for free here:
Thank you to our Pro + Premier members; v3
may I propose an alternate name for React Server Components:
React "Over Engineered Stupid Fucking JSON Protocol Components You Probably Should've Just Picked HTMX Instead" Components
in other words "ROESFJPCYPSJPHTMXIC"
this is still a more easy to understand name than RSC
spent a bunch of time digging into why our ESLint setup was using the long-discouraged eslint-plugin-prettier even though it was nowhere in our config. turns out, it was in the recommended RN config! PR to remove:
programming in general is deeply unintuitive and confusing. think about how much time it took you to really get closures — and to use them proficiently. now why don’t you explain them in a tweet. if someone unfamiliar didn’t get them from a tweet, youre banned from using closures
it’s a shame flow has completely fallen off the open source radar. this feature is huge for design systems (eg <Select> can restrict children type to <Option> or anything that *eventually* renders <Option>). but with flow not being competitive, TS has no incentive to follow
fascinating new feature of
@flowtype
: specifying types for the children of react element
(thanks
@_gsathya
for pointing this out a couple weeks ago before it was documented)
i’m pretty happy with how this post turned out. might be one of my best so far. it does end with a cliffhanger so i hope i’ll manage to stick the landing with the next one. i have a decent idea of where i want to go. my writing process for these posts has been a bit unusual
finished frieren season one. hope the same team makes more. this is an all-time great classic for me, same as dark. 10/10, glad i could watch as it came out
Zed is now open source!
Our mission is to revolutionize developer collaboration, building the world's best code editor in the process. After working together in Zed as a small team, it's time to scale up to transform Zed into a collaboration platform.
there are two stages of maturity for software developers
the first one is learning to step *into* a problem. taking forward steps to solve it
the second one is learning to step *out* of the problem. walking backwards (“but why”) to find where (if at all) to “step in”
ok anyone whose work is related to webdev should probably watch
@ryanflorence
's "mind the gap" talk at
@BigSkyDevCon
great insights on how RSC bridges the gap between server and client
@kami_ayani
@ImSh4yy
google “server driven ui ios”. it’s a fairly well-known pattern although solutions tend to be closed-sourced and tied to specific company infra
one thing i strongly appreciate about the react compiler is how plain its output code is. it’s literally just a bunch of if (x !== y) conditions and array reads/writes, the rest is your own code. feels vanilla
i remember part of the pitch for useMemo/useCallback was “we’re going to teach people to use deps arrays so that by the time the compiler ships, people have a good mental model for how values propagate and what it automates” 🙂
Saw some people say that React Compiler is our admission that useMemo sucks and we pivoted in response to feedback.
In reality we had a “sufficiently smart compiler” in mind the whole time we were working on hooks, and the deps array pattern never would have shipped otherwise.
tip: if you’re ever planning to write a blog post about how much JavaScript sites are loading, remember that Disable Cache is misleading and unreliable. instead, use Open Guest Profile and measure there for good data :)
@inoyakaigor
@yhaskell
@nikitonsky
no. if you check “disable cache”, the behavior becomes unrepresentative because it disables cache even for requests made within a single session on the same page. that’s not how the browser works for any real user.
@ThePrimeagen
not everyone knows this, but React was inspired in many ways by XHP which was a server component-oriented architecture used at FB (alternative to MVC on the server).
why is it such a wild idea to think of these two parts as serving one purpose and componentize across the wire
react went from the first straight to the third season. we should’ve had an era where you’re only allowed to use just server components (no interactivity beyond html) or just client components. like you’d have to pick. everyone would hate it. only then add the ability to mix
@chantastic
imo the key winning aspect in React is composition, and composition is at the intersection of technological and cultural. it doesn’t matter if the tech is “good” if it doesn’t compose (see old Svelte). it doesn’t matter if marketing is “good” if it doesn’t compose (see Gatsby).
somebody working on chrome devtools — please! — can you change it so that pressing Cmd doesn’t hide the already JS value hover tooltip? every time i try to screenshoot it for debugging, the popover goes away!
when people talk about streaming in React frameworks, they tend to focus on HTML arriving as a stream (with content being filled outside-in)
did you know that RSC uses streaming for all future SPA-style navigations too?
the next screen’s UI arrives as an outside-in stream
this is super exciting. the biggest blocker to adopting RSC with a non-framework setup is that it requires bundler support, and it’s *really hard* to write a plugin for bundlers that weren’t *designed* for a combined server/client module graph. first-class bundler support is huge
Made some progress on supporting React Server Components in Parcel over the weekend. Will be very different from other implementations:
• Not a framework. No router, server, networking layer, cache, etc. — just the raw bundling primitives.
• Use with any server/router (eg
prediction: the same thing that happened with plain webpack/babel/setups in the first few years of CRA will happen to plain vite setups in a few years. they’ll still be popular but starting with a framework (SPA mode if you want etc) will be a no-brainer for most cases
With SPA mode, there are high chances of Remix filling the void that create-react-app left (without the known CRA limitations). People wanted us to turn the Vite React starters into a CRA equivalent. But this is right path. The new CRA had to come deep from the React community.
yeah this is a good observation. React forces you to confront the consequences of someone else wanting to reuse your code (or making a change above it) before someone actually does that. this can be frustrating but it spreads responsibility to the person best empowered to fix it.
@chantastic
@dan_abramov2
For me a key aspect in React‘s success was realizing how composition avoids future refactor costs. In other frameworks that allow it, you tend to write code that fits current assumptions. "This prop won‘t ever change; This will only render once“.
wrote a mini-thread on useFormStatus() and useFormState() and their design in React. could be an interesting blog post because the underlying principle isn’t really about forms. it’s about composition
@wesbos
to sum up, React is designed around the idea that you should be able to copy-paste code and have two things that behave similarly but are isolated. no spooky action at distance. so when you “tie things together”, you need to do it unambiguously. either via parent or via wrapping.
the common thing between RSC and Astro is that server-only rendering code in your components always works — both for the initial route and navigations.
with Qwik and Solid, you *can* write server-only rendering code inside of components — but it breaks on the next navigation.
Welp, I spoke WAY too soon.
@dan_abramov2
pointed out how routing would likely break some of the tests I did last night and he was absolutely right.
Next and Astro held up against this requirement, but solid.js did not. Routing completely breaks my initial "server component"
would any conferences be interested in me giving a talk on AT Protocol (the thing powering b*****y)? i think there are some very interesting ideas there that aren’t really in the mainstream yet
it’s undoubtedly an impressive piece of engineering. that can make people skeptical — like how do you trust something complex?
i think it’s being received so warmly because its *output* is easy to understand. like, almost all youtube overviews correctly explain generated code!
✍️ New blog post: "Instant Search Params with React Server Components"
The result of my three-week obsession with React's new useOptimistic hook — ultimately leading me to a much richer understanding of React transitions.
Hope you enjoy!
my favorite thing about b*****y is how hackable (in the good old sense of the word) it is. check out jaz’s social graph visualizer (warning: takes a bit to load). imagine if twitter provided enough data to build userland tools like this!
in case you didn’t realize:
HTMX existed at FB and was called Primer
Astro existed at FB and was called XHP
at FB, the initial adoption of React was literally Islands — not full-page React
React tip: "use client" misconceptions (1/5)
🚫 You need to mark EVERY individual file with "use client" to ensure it is a Client Component.
✅ You only need to mark each client entry point ONCE. Modules imported into a "use client" file are already part of the client bundle.
feeling ambivalent about the ego stuff on here. clearly drives progress but also sours relationships and gradually damages bridges. i wonder how much i participate in that without noticing
I still don't see how Server Components add complexity
For me all they have done is remove complexity
Every single app I have built to this day would get a massive simplicity boost with Server Components
They remove the parts of web dev that annoy me the most
@trueadm
@Huxpro
the current iteration of the compiler was done by
@en_JS
,
@zmofei
,
@_gsathya
,
@potetotes
, and
@kassens
. this is a team with both UI *and* compiler expertise — we didn’t have that years ago! but these people together, at this point in their careers, were able to solve this problem
i wonder how well-understood the problem of client-server waterfalls is in the community.
any solution that encourages you to call server code from the client during rendering suffers from this — you render a bit, then do a network hop, render a bit more, another network hop, …
@RyanCarniato
if i have a parent component with an createAsync call inside it, and a child component with a createAsync call inside it, will there be a client/server waterfall? or is this solved in some way?
@jh3yy
you’ll hate me but “use server” is not a directive that you put instead of “use client”. it’s not a default either!
“use client” marks a door from server to client. like a <script> tag.
“use server” marks a door from client to server. like a REST endpoint.
if you want to write something about react server components and are looking for technical feedback, please don’t hesitate to dm. i will try to review.
especially interested in the explanations that convey the conceptual simplicity. i have a few ideas but idk which are good
@ralex1993
my impression is a lot of people kind of take a look, it appears to be confusing or overengineered from a first glance, and they dismiss it or group with existing solutions. the conceptual simplicity and soundness of the concepts is not recognized or engaged with yet
@nomadtechie
@nulladdict
@ryanflorence
@deriegle
if i may offer a correction, despite the (perhaps unfortunate?) naming, RSC *does not* require a server. by default it runs at the build time. you can think of the “server” part as serving a similar purpose to webpack loaders or build scripts — but packaged into components.
imo: learning framework-first is *better*. when you want to add a route, you should be able to just add a file — not learn another library. when you want to load some data, you should be able to just async/await. there are the first things learners actually want to do
the current somewhat ambiguous React-first learning path of React is still kind of weird, though. learning framework-first doesn't seem like a good idea either. but I don't have a better answer tbh
imo this is
#1
feature request necessary for next to recover from vercel related fud. there’s already static mode but it’s too limited — need something in the middle where everything that’s nontrivial to scale on serverless is fully disabled
lmao i cant believe shadowbanning is real i thought it was like a rw grifter concept. but i get more engagement on this 1k than on my 300k. i wonder which tweet did it
except it’s better than a linter because when you fix the rules violations… your code just gets faster because the compiler doesn’t skip it anymore. so we finally have a carrot for writing idiomatic react code (which is good for all other features and generally helps avoid bugs)
REACT!
Just got caught up on all the posts 😅
I'm near the top of the list of people who could justifiably complain about how they've handled communication, community, and technical details of the project
But I'm not going to 🤗
With a spotlight as big as theirs, you're gonna
this is actually kind of funny. like imagine you’ve never seen nested functions in your life, and then closures “came out”.
“yeah.. it’s just nested functions! no.. not nested function calls. lexical scoping nesting is different from call nesting… the variables stay alive…” 🥲
programming in general is deeply unintuitive and confusing. think about how much time it took you to really get closures — and to use them proficiently. now why don’t you explain them in a tweet. if someone unfamiliar didn’t get them from a tweet, youre banned from using closures