[shams93]

No matter what system you use for server rendered pages most likely you will have to hit a database just to render out the site. These days that's a bad idea when we should be building progressive web apps that can fetch and cache content as needed from services but the entire app can live offline and even cache data in local storage to enable it to have at least limited offline functionality.

[mottomotto]

That really is dependent on use case though. In my current project, I want the most up to date data possible so no caching. In reality, it is cached locally in the browser state and soon, I will be pushing data to update that browser state (based on other users activity in the same tenancy).

I think generalizing to "we should be building progressive web apps" is harmful. You should do what is appropriate for your use case.

[moogie]

> I want the most up to date data possible so no caching

This seriously doesn't mean "no caching" and shows a real lack of understanding about caching.

You state that people should so what is appropriate for use case, though your other comments here go completely against that and are cargo cultist in the extreme. I think perhaps, when you say "should do what is appropriate for your use case" you actually just mean "what I think you should do".

[mottomotto]

It is not the kind of caching that the post I'm replying to is advocating ("the entire app can live offline and even cache data in local storage"). I mentioned the caching I am doing to point out things aren't so simple. I do mean quite literally that none of my API HTTP responses have a caching header (assets are coming from CDN with very long cache life).

It might be more fruitful to try to explain why I go against that instead of simply saying I do without a rational argument that can be responded to. If anything, the thread pretty clearly revealed someone is extremely biased to server-side web frameworks and is unaware of the progression of client-side web APIs.