Dev Agrawal

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

Nested Fetching - StackBlitz Run Solid2 Experiments created by Ryansolid on StackBlitz

besides - we've already shown that you can achieve this without a compiler, purely at runtime

stackblitz.com/edit/github-...

i would like hoisting/prefetching data to be an optimization, not a requirement

it's much easier to simply prefetch the bundles so that data fetching can be kicked off for most of the page instantly

when combined with offscreen rendering, waterfalls become a much smaller problem

without any hoisting/prefetching this provides the best possible scenario

there's a decent number of apps that don't bother hoisting manually because it's too brittle, and RSC/GraphQL solutions don't work for their use case

if we can offer them the best case scenario i don't see why we shouldn't

nice! excited to see what this ends up looking like

the wisemonkeys are not nested components, they are sibling components

even react can render siblings in parallel

nested but parallel is the real deal

only if you put the await in the template

if you put it in the code then it blocks everything under it

(given that the fetches aren't directly dependent on each other for data and they can happen in parallel)

can the compiler ensure nested components also fetch in parallel to their parents?

Lifecycle of a @solidjs.com convert:

1. Why recreate React? Touch grass!
2. How do I use my React library in Solid?
3. Fine-grained reactivity? Sure Jan
4. What do you mean...no re-renders? 🤯
5. Arghhhh React!!!
6. *cornering ppl at parties* Have you heard the good news about signals?

😆

Nested Fetching - StackBlitz Run Solid2 Experiments created by Ryansolid on StackBlitz

for example - nested components fetching data in parallel without unnecessary waterfalls by default
stackblitz.com/edit/github-...

> so far from representative real-world use cases

Rendering an array into a list/table is far from real world use cases?

Funnily enough wasm frameworks generally score worse than js frameworks in the benchmarks

The best part about the benchmarks is finding frameworks that push you towards good patterns AND are also super performant so I can spend more time building features and less time looking for regressions

It’s literally testing the performance of rendering an array into a table/list

Do you not have that in your app? I have like 20 of them in a normal app

It’s a big and general enough task to not qualify as a microbenchmark

if you think this is a microbenchmark you're ngmi

Signals and Sync Engines

Name a more iconic duo

I’ll wait

YouTube video by Local-First Conf Dev Agrawal - Sync engine's best friend: fine-grained rendering

i have to admit that i was skeptical about @devagr.bsky.social's talk about fine-grained rendering and sync engines, but he tied everything together really well. if you really care about the fastest possible performance, local-first data and fine-grained rendering are probably the way to go.

My takeaways from this year's @localfirstconf.com

Last year we collectively were at the stage of “hey this syncing tech is cool, you don’t need the cloud as much” and “hey, we have a community here, who knew?”

This year it felt like the community had more cohesion and sense of identity.

GitHub - lxsmnsyc/seroval: Stringify JS values Stringify JS values. Contribute to lxsmnsyc/seroval development by creating an account on GitHub.

Yes you can check out seroval by @lxsmnsyc.bsky.social that does this and more, and is used within solidstart and soon tanstack start

github.com/lxsmnsyc/ser...

Ooh never thought of it as “progressive JSON”

But this is a really cool way to describe the superpower that unlocks so many modern capabilities like RSCs and Single Flight Mutations in Solid Start

1. Effects run when atleast one of the dependencies change. Are you noticing unexpected behavior in any cases? Sounds like it could be a bug.

2. As in cases where dependencies are dynamic? And how does that affect the non-dynamic case exactly?

3. We have onCleanup, not sure what you mean exactly

What issues are you running into right now?
createEffect is supposed to be the best place for this stuff, would love to hear why that’s hasn’t been working for you

I appreciate the @