[throwaway7783]

A good example is when a page has expensive metrics specific to say a filter on the page. Let's say an action on the page shows a notification count change in the top right corner.

While morph will figure it outz it's unnecessary work done on the server to evaluate the entire body

[andersmurphy]

Expensive queries on the server should be shared where they can be (eg: global leaderboard) or cached on the server (in the game of life demo each frame is rendered/calculated once, regardless of the number of users). Rendering the whole view gives you batching for free and you don't have to have all that overhead tracking what should be updated or changed. Fine grained updates are often a trap when it comes to building systems that can handle a lot of concurrent users. It's way simpler to update all connected users every Xms whenever something changes.

[throwaway7783]

I agree on caching. But in general my point stands. The updates in question may not even be shared across users, but specific to one user.

Philosophically, I agree with you though.

[andersmurphy]

Yeah so that was how I used to think about these things. Now, I'm. less into the fine grain user updates too.

Partly, because the minute you have a shared widget across users 50%+ of your connected users are going to get an update when anything changes. So the overhead of tracking who should update when you are under high load is just that, overhead.

Being able to make those updates corse grain and homogeneous makes them easy to throttle so changes are effectively batched and you can easily set a max rate at which you push changes.

Same with diffing, the minute you need to update most of the page the work of diffing is pure overhead.

So in my mind a simpler corse grain system will actually perform better under heavy load in that worst case scenario somewhat counter intuitively. At least that's my current reasoning.