3 ms·

The article stated that he no longer needs eventing to update other parts of the page, he can send down everything at once. So, I guess that is much less comple

The article stated that he no longer needs eventing to update other parts of the page, he can send down everything at once. So, I guess that is much less complex. Granted, eventing and pulling something down later could be a better approach depending on the circumstance.

yawaramin 1y ago
You can send everything down at once with htmx too, with oob swaps.
- throwaway7783 1y ago
  yes you can, but the complexity is now moved to server side template wrangling. With SSE, its just separate events with targets. It feels much cleaner
  - yawaramin 1y ago
    Server side template wrangling is not really a big deal, if you use an HTML generation library...something like Python's Hpty/FastHTML or JavaScript's JSX. You can easily split the markup down into 'components' and combine them together trivially with composition.
  - andersmurphy 1y ago
    I mean in practice you rarely target individual elements in datastar. You can sure. But targeting the main body with the entirety of the new content is way simpler. Morph sorts out the rest
    - throwaway7783 1y ago
      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 1y ago
        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 1y ago
        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 1y ago
        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.

yawaramin 1y ago

You can send everything down at once with htmx too, with oob swaps.

throwaway7783 1y ago
yes you can, but the complexity is now moved to server side template wrangling. With SSE, its just separate events with targets. It feels much cleaner
- yawaramin 1y ago
  Server side template wrangling is not really a big deal, if you use an HTML generation library...something like Python's Hpty/FastHTML or JavaScript's JSX. You can easily split the markup down into 'components' and combine them together trivially with composition.
- andersmurphy 1y ago
  I mean in practice you rarely target individual elements in datastar. You can sure. But targeting the main body with the entirety of the new content is way simpler. Morph sorts out the rest
  - throwaway7783 1y ago
    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 1y ago
      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 1y ago
        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 1y ago
        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.