Dev Agrawal

Going after OSS projects that are openly governed isn't going to do what you want it to. Vercel makes its money from its hosting platform and paid products. OSS is not a paid product and while contributes goodwill doesn't directly impact the bottomline. And these project's reach well exceed Vercel.

Innovating React w/ Ricky Hanlon YouTube video by Ryan Carniato

For the first time in the 4 years I've been doing Friday streams, I will be having a @react.dev Core Team member as a guest.

I'm excited to welcome @ricky.fm on to talk all things React. Past, present, future.

www.youtube.com/live/3vw6EAm...

all of that is in the pipeline for 2.0

Ricky's reaction to this was one of my favorites
bsky.app/profile/rick...

without a bundler, the "use server" will do nothing and the function will run on the client side instead of the server side. but with a bundler, it will allow you to directly interact with server side apis

both screenshots show client AND server code

solidstart uses "use server" compiler directive, svelte uses .remote.ts, both require bundler plugins to work.

this has nothing to do with SSR, this is making an RPC call to the server to fetch posts when the component is rendered on the client

well and the "use server"

Ryan beat me to it lol bsky.app/profile/ryan...

You can still opt in to 2 - hold previous consistent state. Just wrap the state update in a transition, and set some pending state to true. Since transitions in Solid 2.0 don't get entangled by default, you still have full control over the granularity of pending states.

Now even though the state tears, the user has a clear indication that something is happening in the background and it's expected to see old state. This also works with state that is derived from async sources, as well as multiple async sources. This provides more control than implicit grouping

This also provides the developer full control over how and where to manage pending indicators.
If the above solid example was written with 2.0 primitives, you can very easily add a pending indicator using `isPending`, which can work with data that is async or derived from async sources.

While defaulting to 3 might seem like the default experience is broken or inconsistent, it's actually the most natural way of handling async updates. it's exactly how "fetch in useEffect" or non-suspense loading works. all state updates come in as they complete, no blocking or suspending by default.

Defaulting to 2 is sensible because the existing content stays on screen. But when every state update is held until all async resolves, you might click a button, see nothing happening for a while, and think that something is broken. pending states also get lumped together quite often.

Defaulting to 1 is very awkward because the moment you click a button or submit a form that causes refetching, huge chunks of content disappear from the screen. It's a very jarring experience, and the only way to show a pending indicator is by adding a useTransition hook that wraps every update.

So none of this discussion is about "what UX are we building". In those terms all 3 are "broken" in my opinion.
This discussion is about the default behavior you get out of the framework, and how easy is it for the developer to opt in to a different behavior and/or a pending indicator.

React defaults to 1, Svelte defaults to 2, Solid defaults to 3.

To be honest, none of them are great options for the UX, which means ultimately it is the developer's responsibility to add pending indicators to let the user know something is happening or some data is out of date.

1 - Suspend, or don't show anything until the async completes and fall back to a suspense boundary.
2 - Hold, or keep the previous consistent state on the screen until the async completes.
3 - Tear, or show state updates as they come in on the UI.

I love that we have all three links here that show the three possible behaviors when there is pending async work on an existing UI component.

can you elaborate on "reverse the graph"?
i just see this

now hit the retry button

if you fetch in server components or relay fragments then you're fine, but useSuspenseQuery users are probably gonna be hit with this a whole lot more

i wonder if the perceived slowness is not just perceived but real slowness caused by suspense blocking component level data fetching

Posted this on twitter as a comparison in the DX of the upcoming SvelteKit (left) and SolidStart (right)

Almost everything I care about in DX is identical between these two, but I understand different people care about different things

Thoughts? Any meaningful differences I should know?

congrats on finally shipping this!

if Meta's usage of React has led to certain heuristics being developed to prevent over-fetching, it makes sense that you'd want to offer those heuristics as a first class citizen within React, and you might also think that the broader ecosystem benefits from the same things.

i might be totally off-base here, but it's possible that the opinions around data fetching with React are a consequence of how React gets used within Meta (and possibly Vercel), rather than what the general ecosystem is doing.

it's not a question of capability. both solid and svelte can easily build a temporary cache of sorts in the derived primitives that hold the previous values for a short amount of time in case the dependencies revert back.

it just sounds like a terrible api to offer developers.

you can't decide what requests are unnecessary as someone who's responsibility is to show data on the UI that is consistent with its dependencies

you can offer heuristics, but they have to be wrapped in an opt-in api, not the default that has to be opted out of

out of the box caching solutions make it difficult for the ecosystem to build solutions that suit specific use cases. there's no cache strategy that suits everyone.

even something as simple as "keep the last piece of data around for 30 seconds" leads to super annoying experiences

i don't see how caching data that is no longer needed by the UI is a concern that rendering frameworks should concern themselves with

or have you forgotten the biggest complaints people had with nextjs app router for the longest time until dynamicIO