Infinite-Scrolling Social Feed

Model response

Every one of those costs is real, and I would not reach for virtualization by default. Find-in-page genuinely stops working for unrendered content, and that is a legitimate accessibility regression I cannot fully mitigate. My decision rule is measurement: if p95 scroll depth is thirty or forty items, mounted node count never becomes a problem and I should not pay this cost. Before full virtualization I would try content-visibility: auto with contain-intrinsic-size, which keeps nodes in the DOM — so find-in-page and anchors still work — while skipping their layout and paint. That covers a large fraction of the win. I only escalate to true windowing when profiling shows DOM size itself, not paint, is the bottleneck, which in practice means many hundreds of complex rows.

Model response

I largely agree with the critique, and for content where completeness matters — search results, a documentation index, an admin table — I would take numbered pages every time, because they are addressable, shareable, and bounded. The reason a social feed is the exception is that the underlying data has no stable end and no meaningful page boundaries; a ranked feed reorders continuously, so 'page 4' does not identify anything durable. The footer problem is real and I would solve it by moving footer links into the navigation rather than pretending users will reach the bottom. The middle ground I would actually propose is a load-more button after the first two or three auto-loads: it keeps the initial experience frictionless, restores user control, and stops the accidental infinite session.

Model response

You are right that an optimistic update is a claim the client cannot actually guarantee, and a silent rollback is worse than a slow response because the user has no model for why it happened. The reason I still take it is the latency asymmetry: a like round trip is 200 to 800ms on mobile, and during that window an unresponsive heart makes people tap again, which generates duplicate requests. So the choice is not honest-versus-dishonest, it is which failure is rarer and cheaper. Like mutations succeed well above 99% of the time, and the consequence of the rare failure is one wrong heart. What I would not do optimistically is anything destructive or anything with a money or permission consequence — deleting a post, submitting a payment — because there the rare failure is expensive. And I pair the rollback with a visible toast, so it never fails silently.

Model response

That is a fair objection and the naive version of what I described is genuinely expensive. Three things make it tolerable and I should have named them upfront. First, the poll returns a count, not content, so the response is tens of bytes and can be answered from a cache rather than the ranking service. Second, the interval should be adaptive rather than fixed — back off when the tab is hidden via the Page Visibility API, back off further as the session ages, and stop entirely when the user is scrolled deep, since a new-posts pill is meaningless a thousand items down. Third, at real scale the right answer is push rather than poll: a single multiplexed WebSocket or SSE connection that the server nudges. I would start with adaptive polling because it is a fraction of the operational cost, and move to push when the poll volume, not the latency, becomes the pain.