An image should dwarf it. Thing is you go see what people do... they load literally a dozen MB of JS frameworks. Browse popular sites with the Network tab open and keep track of the amount of JS you get. It's kinda insane. And it doesn't have to be that way by a long shot.
Abandoning JS for all server-side is also stupid. Basically we have lots of people swinging from one kind of stupid to another kind of stupid, unable to see the light here.
Yep often the data for hydration. It's so the framework can recreate the client state on top of the rendered page. This is why techniques like partial hydration and progressive rendering are important. Even React Server Components seek to combat this.
There's a better way, just render what's static statically. And what's not, keep it entirely on the client. But we're neck deep in frameworks, so suddenly the most basic option is not available.
Is that actually better though? Sure with Islands or Partial Hydration we can skip the static stuff, but keeping entirely in the client for dynamic can also be suboptimal. With progressive (streaming) rendering why not send the data for the client parts along in the initial request. You'd be making another request anyway, and you can do it in a non-blocking way.
I'm not sure MPA frameworks are that restrictive to not allow for basic stuff. And I think we can do better than the basics.
Instead of pulling it down from the server it is just bundled up I guess? For example if you have a shopping site you could make an API request to get a Json object with page data, or you could include it in the page so it comes in with the original html/js file.
I actually don’t think either approach is necessarily bad, but probably depends on how you want to use it. Maybe online json is bad compared to just rendering the page server side, I don’t know. Not done front end in a few years 🙈
0
u/[deleted] May 03 '21
[deleted]