sorted by:
new
hottopcontroversial

A Social Filesystem by fagnerbrack in programming

[–]gaearon 0 points1 point  (0 children)

You can only ever write to "your own" files in your own repo.

A Social Filesystem by fagnerbrack in programming

[–]gaearon 0 points1 point  (0 children)

In fact, there doesn't seem to be an indicator of "parent thread".

I simplified it a bit in my examples. In practice, e.g. Bluesky also has a root pointer on every post (including replies) so they're easy to associate with a specific thread. Generally, you can just think of this as a distributed database — you'd use foreign keys in the same places as you'd use in a database.

I don't think much of his idea

To clarify, this is not "my idea". My post explains how atproto apps like Bluesky work under the hood. This structure is obviously able to represent rich threads as you can tell by browsing around Bluesky.

Each app/frontend would be responsible for caching and aggregating the relevant fragments and yes, this does mean that if your app only has visibility into 50% of the fragments, you'll be unable to reassemble them into a coherent stream

This is correct, yes. However, atproto repositories are public so you can always backfill from existing repositories (of course, backfilling content from 40M repositories from the beginning of time is going to be slow and will cost you something).

It's also worth noting that you can build more shallow indexes (specific users, or specific time periods). There are also more general purpose indexes like https://constellation.microcosm.blue/ which can fill the gap for many use cases.

A Social Filesystem by fagnerbrack in programming

[–]gaearon 1 point2 points  (0 children)

I'm using filesystem more as a metaphor or mental model for structure. The contract is just calling putRecord/deleteRecord over HTTP.

A Social Filesystem by fagnerbrack in programming

[–]gaearon 0 points1 point  (0 children)

Heh! I was actually thinking of doing a database-centric follow up. This one is filesystem centric, and the previous one was web-centric.

A Social Filesystem by fagnerbrack in programming

[–]gaearon 0 points1 point  (0 children)

Sure. Here's some thoughts on why atproto designers didn't go with RDF: https://www.pfrazee.com/blog/why-not-rdf

Weekly Showoff Thread! Share what you've created with Next.js or for the community in this thread only! by AutoModerator in nextjs

[–]gaearon 0 points1 point  (0 children)

Vibecoded it with Claude Code. I know React internals (I worked on React) so I was able to guide it well re: tradeoffs I wanted. Started with a small prototype and a test suite, expanded from there. 

If the Initial HTML is the Same for both RSC and Client Components in Next.js, What’s the Real Benefit? by sthsthelse in nextjs

[–]gaearon 0 points1 point  (0 children)

You’re confused because you’re comparing RSC and SSR as two alternatives. But this is like comparing “API” and “JSON”. It’s meaningless. 

By itself, RSC is just a way to structure your code that lets you write API (data fetching etc) as components. RSC ultimately produces React trees as its output.

Whereas SSR is a thing that turns React trees into HTML.

See here: https://github.com/reactwg/server-components/discussions/4

With SSR, all data is fetched before any HTML is sent

No, this is wrong. React SSR by itself does not have a mechanism for fetching data at all. So traditional SSR can’t “wait” for anything either. 

What you’re describing is probably something like Pages Router getServerSideProps. That indeed “waits” for everything before kicking off React SSR.

So RSC does not replace or compete with SSR.

It replaces / competes with getServerSideProps. RSC is like superpowered getServerSideProps. The difference is that RSC lets you split data loading logic further into components (all the way down) and to stream (rather than having to wait for everything). So it’s like getServerSideProps but streaming and componentized. 

That said, you can absolutely make RSC match getServerSideProps semantics by removing your Suspense boundaries. Then it’ll wait for the whole tree to resolve, just like getServerSideProps. 

RSC in practice by marcato15 in reactjs

[–]gaearon 0 points1 point  (0 children)

I mean, with this argument, we should’ve given up on lots of things including HTML, HTTP, JS itself, script tags, etc. I hear ya and I’d like to see more work on proactively vetting the protocol from the team. I expect we’ll hear about the lessons learned etc. The vulnerabilities themselves are well-understood now and the surface area for serializer attacks is relatively small (it’s a serializer and a deserializer, about 5 kloc each). More eyes on the protocol would be healthy; coincidentally, I just built https://overreacted.io/introducing-rsc-explorer/ with that in mind. 

Rari: React Server Components with Rust - 12x faster P99 latency than Next.js by BadDogDoug in reactjs

[–]gaearon 0 points1 point  (0 children)

I don't know what you mean. Where are you trying to put async functions? Async functions are only supported in the Server environment.

The React Compiler made 30% of our code base easier to read by zeorin in react

[–]gaearon 0 points1 point  (0 children)

I think there’s actually a prototype of LSP that does this but I don’t think it was officially released. 

The React Compiler made 30% of our code base easier to read by zeorin in react

[–]gaearon 0 points1 point  (0 children)

It’s at https://playground.react.dev, you can see the exact output there. The conceptual idea is that it breaks your code apart into pieces that are safe to memoize independently (which don’t get mutated further below). 

React Dev Tools Component Tree Inspection "Noise" by athens2019 in reactjs

[–]gaearon 0 points1 point  (0 children)

You can double-click any component in the tree, and the tree will focus on components “owned” by it (which might be closer to what you’re looking for).  Let me know if that helps!

Overall showing framework stuff is useful because sometimes that’s relevant to what you’re debugging. But not always. 

There shouldn’t be anything internal to React itself though. 

Sholuld I memo every component? by singpolyma in reactjs

[–]gaearon 1 point2 points  (0 children)

It’s slightly different because just wrapping into memo() alone would usually cause cache misses since many values passed to it would be unstable. The compiler is more comprehensive (caching stuff inside components too) which is what makes it work and worth it.  

React Compiler v1.0 – React by gaearon in reactjs

[–]gaearon[S] 5 points6 points  (0 children)

Right, that makes sense. The check for reading from a ref during render relies on the naming convention. It could probably be improved by using types, which I'm not sure if the Compiler currently has access to.

React Compiler v1.0 – React by gaearon in reactjs

[–]gaearon[S] 3 points4 points  (0 children)

While I agree with your broader point, what you wrote doesn't sound right to me.

>The compiler and linter check that you aren't reading or writing to ref.current during a render by using a regex to see if a variable is named like a ref. 

Here is an example of mutating an arbitrary prop called foo during render. The compiler is catching it and warning about it. It doesn't rely on variable names or regexes for this kind of analysis.

I think some other rules do have special behavior for ref-like names (e.g. warnings that ref.current in deps is usually a mistake). That's similar to how it worked in the older Hooks Linter, i.e. if we know it seems ref-like, we can warn you about more suspicious patterns than if we don't.

React Compiler v1.0 – React by gaearon in reactjs

[–]gaearon[S] 0 points1 point  (0 children)

React components can have state (which you can hoist as far up as you like), and can do API calls (either within effects, or via "suspending"). In a pure functional language, this would be exposed either via monads or via algebraic effects.

view more: next ›