Hacker News new | ask | show | jobs
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.

1 comments

Apollo client? you mean where the Meteor Dev team suddenly leaped to when it dawned upon the world that Mongo as a primary-store and a bizarre architecture that let you walk away with exactly one artifact towards your inevitable rewrite? (moustache templates!) was probably not going to take-off in a big way. Awesome integration and polished docs etc. Mini-mongo and pub-sub with websockets always for everyone? mmmm it ran rather slowly... Put that at 30 degrees North North-West and integrate "what is good for a FAANG may bankrupt me and not provide foreign keys" lol.. Nothing against VC, but lets separate busy-work trends that mega-corps use in trench warfare of attrition (Google has more developers than you do.) from productivity tools. GraphQL? I'd probably Postgrest if I were a one-human front-end/SPA shop
I mentioned it as an example of one of the more popular solutions available. Yes, it's complicated and requires a deep understanding of what it's doing - and even then it has warts that you have to work around - but we're talking about situations this complexity is necessary for the desired UX.

Whether the user actually desires this experience is another question entirely...