|
|
|
|
|
by ervine
1953 days ago
|
|
Agreed that it's complex, but I think the "needlessly" part is up for debate. Considering we're all here on hacker news, we're all used to and just fine with the idea that if you want fresh data, you refresh the page. I agree with you that for 99% of websites, this is just fine. But if the requirements are for less page refreshes and high interactivity with always-fresh data, then client side rendering with a client side cache and cache management become important. Like Apollo Client, or what have you. Does it add unbelievable amounts of complexity? Definitely. Is it needless? Depends on the goal. I would argue it's easier than manually polling for new data, managing the cache by hand and ensuring that everywhere the data is needed has been updated, and updating the DOM as a response to that new data. So to answer your question: when done right, the user is served by having the most up to date information displayed for them at all times, with the number of network requests for said data kept to a minimum. Is it worth it? I don't personally think so in the big picture, but in my day to day having this complexity live on the client side gives us so much more control over the UX that it's necessary to build what is expected. |
|