This is one of those "easy" things that should really be built into the CSS standard (as Josh points out in the article).
Readit Newsbhollis commented on Springs and Bounces in Native CSS joshwcomeau.com/animation... · Posted by u/Bogdanp
Neat, they have Newt, the robot my dad built that was the first mobile robot with its own onboard computer. Newt is still there in his basement, and as a kid I did science fair projects programming behaviors for it. At that point the computer had been upgraded to a Motorola 68K. https://www.theoldrobots.com/Newt.html
The anecdotes shared here are mildly interesting. But there is not much storytelling that pulls it all together. That is probably why it didn't get much attention the first 2 times it was posted. The author probably has internalized the connectivity between the stories so well that they did not notice that while some of it was written into the article, mostly their writing jumps from anecdote to anecdote without building upon an overall story/thesis/argument/point.
Rather than posting it multiple times and having a friend re-post it for you (which is, admittedly, an assumption based on OP and the author sharing the same work history), I'd recommend putting some energy into figuring out why this post is not garnering the attention the author clearly desires. As mentioned, I think it is just being too close to the writing to see the gaps in the writing style.
An incorrect assumption (though it was nice to have seen a familiar face when I came across it) but good to know what you think of it. I assumed HN deduped posts but I guess not.
At some point, every growing system hits the "you can't join that anymore" wall. Reads get offloaded to replicas, writes start queueing, and suddenly you're managing backpressure across half a dozen services.
Most teams respond by duct-taping workflows together with message queues, cron jobs, or hand-rolled orchestration logic. It's wild how quickly database scale issues turn into distributed state problems and how rarely people plan for that up front.
I've been leaning into explicit state machines lately (prop for making that less painful). Not because it’s trendy, but because once your system has implicit state transitions buried across services, observability and recovery get brutal.
I've found that once you make the jump to a real partitioned datastore (like DynamoDB) you can actually go back and undo a lot of the queues and caches that were used as band-aids to reduce pressure on the DB. If you have something that has consistent performance at any scale and true elasticity, you just don't need all that other stuff, and the whole system gets far easier to understand and operate.
bhollis commented on Postgres LISTEN/NOTIFY does not scale recall.ai/blog/postgres-l... · Posted by u/davidgu
The pattern I've always used for this, which I suspect is what they landed on, is to have an optimistic notification method in a separate message queue that says "something changed that's relevant to you". Then you can dedupe that, etc. Then structure the data to easily sync what's new, and let the client respond to that notification by calling the sync API. That even lets you use multiple notification methods for notification. None of that involves having to have the database coordinate notifications in the middle of a transaction.