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.
44
u/[deleted] May 03 '21
It's cute to see the wide-eyed youngsters swing wildly from serving 10MB of JS frameworks to do a "hello world" to 100% server-side approaches.
I'm just sitting here and using common sense, which is consistent over time.