Hacker News new | ask | show | jobs
by IceDane 975 days ago
Not gonna lie: that sounds absolutely awful, and I can't imagine this works at any real scale. It will also have poor UX, because your users will be waiting for data which you already fetched and should just have cached.

There are also plenty of applications where what you are describing is arguably just not feasible at all, like heavier applications that due to their nature just need a lot of client-side state.

2 comments

If you have a fast API it's very feasible. I'll take slighly reduced UX due to slower page load times any day over unpredictable completely broken UX introduced by bad state management (common with e.g. Redux non-RTK in the hands of inexperienced frontend devs).

I'd personally still favor Next.js + TanStack Query if given the choice.

One of the apps I currently manage does this. It works fine, but that’s because we’ve basically reimplemented redux