throwaway_bad

Same way you scale replication for any server, by sharding and only replicating the shards you care about.

The "shard" could just be that users own feed in this case. Then you get offline for free where user adds a tweet and it appears immediately, replicating back to server when he goes back online. The server replica side will need to be a lot more complicated to deal with broadcasting but I don't see why it won't work.

Having client state just be a replica of server state solves so many problems I don't understand why the concept never caught on. Pouchdb/couchdb are still the only ones doing it afaik.

Instead we have a bajillion layers of CRUD all in slightly different protocols just to do the same read or write to the database.

Possibly dumb question: How do you ensure there's no data leakage when benchmarking transfer learning techniques? Is that even a problem anymore when the whole point is to learn "common sense" knowledge?

For example their “Colossal Clean Crawled Corpus” (C4), a dataset consisting of hundreds of gigabytes of clean English text scraped from the web, might contain much of the same information as the benchmark datasets, which I presume is also scraped from the web.

Yea you're right, I guess there is a distinction between reinventing and reimplementing. The authors even mentioned that concurrent mode is inspired by "double buffering" from graphics.

I am just trying to support the grandparent comment that the current optimization is at the wrong level of abstraction. React is at the level of a "scene graph" (dom). If it's slow, the first technique to reach for should be stuff like "occlusion culling".

> If your app is architected to have any rendering operation take long enough that it's perceptible to the user, STOP DOING THAT THING DURING RENDERING.

As is tradition, frontend developers are still slowly reinventing the techniques from other fields.

The neat thing about UI is that your end user is a human and a human can't visually process too many items at once on a screen. This means you should never really need to consider more than O(thousands) elements to render either. That should always fit under 16ms.

This has been known to game developers since forever. Don't spend resources on things that won't be displayed. If you are doing too much work that means you aren't culling invisible objects or approximating things at a lower level of detail.

In practice for frontend developers, this just means using stuff like react-virtualized so that even if you have a list of a bajillion objects, only the stuff in the viewport is rendered.

It's easy to gain physical intuition because you can often explain one physical phenomenon in terms of another physical phenomenon that you have much more real life experience with.

But with mathematics, "intuitive" analogies are all in terms of other mathematical objects! You can't build intuition if you don't even know what they trying to abstract over.

In that regards, The Princeton Companion to Mathematics is fantastic because it maps out how the different fields of mathematics are interrelated.

Unfortunately anything screen readers can recognize as invisible, a more sophisticated bot can too.