The micro-trend to refetch everything on any mutation or use browser in built cache. In contrast to JSON cache like you'd find in React Query, URQL, or Apollo.
I realize these are both client side. But I meant cache in managed in JavaScript. This can reduce the size of data fetching libraries. But more commenting on the savings might be in the range of 5kb or something and doesn't really impact size much overall.
Yeah, I mean the savings on library size is something. Apollo is 30kb, but URQL is 9kb, and SWR is 5kb I think and it isn't like the libraries using the browser cache aren't a few kb themselves.
It's been suggested that this somehow saves more but that is the result of just moving more logic to a backend API, you could do that regardless of the mechanism. Like saving on using moment or something in the browser.
So I think the win is that people are conscious enough to do better things but not so much that the technology itself changes very much in terms of bundle size. This portion of the win can be done at any step, but I suppose it gets more obvious.
By default everything ends up in the client. These cacheless solutions suggest doing stuff on the server. Things like Partial Hydration end up dropping enough peripheral code that those things and more don't end up in the browser.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
What did you mean by “moving away from client-side caches [doesn’t] meaningfully changes the math”? I really have no idea…
The micro-trend to refetch everything on any mutation or use browser in built cache. In contrast to JSON cache like you'd find in React Query, URQL, or Apollo.
I realize these are both client side. But I meant cache in managed in JavaScript. This can reduce the size of data fetching libraries. But more commenting on the savings might be in the range of 5kb or something and doesn't really impact size much overall.
Got it! So all you are saying is that moving from artifical JS caches to built in browser one's doesn't save much in terms of bundle size?
Yeah, I mean the savings on library size is something. Apollo is 30kb, but URQL is 9kb, and SWR is 5kb I think and it isn't like the libraries using the browser cache aren't a few kb themselves.
It's been suggested that this somehow saves more but that is the result of just moving more logic to a backend API, you could do that regardless of the mechanism. Like saving on using
momentor something in the browser.So I think the win is that people are conscious enough to do better things but not so much that the technology itself changes very much in terms of bundle size. This portion of the win can be done at any step, but I suppose it gets more obvious.
By default everything ends up in the client. These cacheless solutions suggest doing stuff on the server. Things like Partial Hydration end up dropping enough peripheral code that those things and more don't end up in the browser.