11–20 of 362 posts
Why do people insist on comparing the initial frontload of a SPA to the page load of every page in their SSR web app? Once a SPA is loaded you can send tiny crumbs of data faster than any significant SSR.
> Why do people insist on comparing the initial frontload of a SPA to the page load of every page in their SSR web app? Because a user doesn't care if it's the initial frontload or not.
Why do people insist on comparing the initial frontload of a SPA to the page load of every page in their SSR web app? Once a SPA is loaded you can send tiny crumbs of data faster than any significant SSR.
> Why do people insist on comparing the initial frontload of a SPA to the page load of every page in their SSR web app? Because a user doesn't care if it's the initial frontload or not.
Wtf is an SPA?
I had actually never seen that written solely as SPA even though I've worked as a react dev for 2 years now in Canada. I guess the acronym really is going obsolete.
Earlier quoted context omitted.
> Why do people insist on comparing the initial frontload of a SPA to the page load of every page in their SSR web app? Because a user doesn't care if it's the initial frontload or not.
Prerender the initial page and they won't notice any difference.
While SPA tooling like React are incomplete since they don't provide all of the client/server data communications that comes for free with a server side application. That is starting to become more "standard" as GraphQL and Apollo start filling the gap of boilerplate. Though of course wrapping your head around GraphQL takes a bit of work for anybody who's spent their life with REST.
Most applications should be SPAs to create the interactions that users expect.
Why do people insist on comparing the initial frontload of a SPA to the page load of every page in their SSR web app? Once a SPA is loaded you can send tiny crumbs of data faster than any significant SSR.
You can, but often that's not what's happening.
E.g. crates.io is currently built as an SPA. It is first receiving a HTML page that loads a javscript file, that performs an XHR request (actually, multiple) that answers with JSON that is used to create the final DOM of the page. The Javascript file is cached but that's about it, it still involves one additional needless roundtrip for the website.
The JSON sent is so badly designed that it alone is far more than the final DOM of the page.
Jus check out this: https://crates.io/crates/winapi
vs this: https://crates.rs/crates/winapi
Only the XHR requests for the crates.io page take up 99 KB uncompressed, while the entire crates.rs winapi page takes 103 KB uncompressed.
For CRUD apps, using Rails etc. with Turbolinks[1] is the best way to go IMO. It gives you the SPA feel without the headache. In all SPAs, we load JSON, with Turbolinks, we load HTML of that page alone (without the CSS, JS etc). [1] https://github.com/turbolinks/turbolinks
Why do people insist on comparing the initial frontload of a SPA to the page load of every page in their SSR web app? Once a SPA is loaded you can send tiny crumbs of data faster than any significant SSR.
Why do people insist on comparing the initial frontload of a SPA to the page load of every page in their SSR web app? Once a SPA is loaded you can send tiny crumbs of data faster than any significant SSR.