The point about Brotli compression being extremely efficient for SSE is a great insight.
It means applications that send “dumb” HTML snapshot updates instead of “optimized” payloads can actually be more efficient while massively simplifying the architecture.
I feel like the SPA vs. SSR debate misses the point: SPAs are most often web applications (as opposed to informational websites). I created SPAs as a contractor for 10+years, and it always has been B2B web apps for large corporations. The users are always professionals who work with the app on a mostly daily basis.
Since .js, .css and assets are immutable between releases (and modern tooling like NextJS appends hashes to the filenames so they can be served with 'Cache-Control: immutable'), the app is always served from browser cache until there is a new release - which is usually weeks, not days. And if a the browser cache should be empty, you would compare waiting 500ms-1s to use an app that you will use for hours that day. If however, every link click, every route change, every interaction triggers a SSR server roundtrip, the app will not feel snappy during usage.
Now, if people chose the wrong tool for the job and use a 1MB SPA to serve a landing page, that is where things go wrong. But for me, metrics that include the download time of the .js/.css assets are pointless, as they occur once - relative to total time of app usage. After initial load, the snappyness of your SPA will mostly depend on your database queries and API performance, which is also the case in a SSR solution. YMMV of course.
> if people chose the wrong tool for the job and use a 1MB SPA to serve a landing page, that is where things go wrong
That is exactly the case. Can’t really blame
the people when every learning resource, react evangelist, tweet and post points you towards that.
> If however, every link click, every route change, every interaction triggers a SSR server roundtrip, the app will not feel snappy during usage.
SPAs still do the same, maybe more round trips for API requests, we all know how endemic loading spinners have become. Rendering HTML does not meaningfully affect server response times. And frameworks like Datastar (used in this benchmark), htmx, alpine allow you to avoid full page loads.
It's a nice article about a topic I care a lot about (the need for rediscovering hypermedia, and about the magnificent Datastar library/framework).
But I fear that the comparison is less SPA vs Hypermedia than a specific nextjs app on vercel versus a specific php app on a vps. And that people will justifiably give people reason to dismiss the whole thing outright.
If anyone is inclined to do that, I really urge you to look at Datastar's website and examples to see what it is capable of.
Also to read infrequently.org for far more about spa (especially react) vs hypermedia + progressive enhancement.
The underlying architecture matters little when the SPA requires several seconds of main thread work after downloading various "blobs" of minified java script..
Hence the nextjs app on vercel (bloated mess). Plain react or svelte is performant fun fact, it’s all the cruft added on top that makes it bloated and slow.
Was expecting to see HTMX, cool to see Datastar in the wild.
Seems like people are finally rediscovering how much they can do with a lot less. Hope the push for simplicity continues
The point about Brotli compression being extremely efficient for SSE is a great insight.
It means applications that send “dumb” HTML snapshot updates instead of “optimized” payloads can actually be more efficient while massively simplifying the architecture.
I feel like the SPA vs. SSR debate misses the point: SPAs are most often web applications (as opposed to informational websites). I created SPAs as a contractor for 10+years, and it always has been B2B web apps for large corporations. The users are always professionals who work with the app on a mostly daily basis.
Since .js, .css and assets are immutable between releases (and modern tooling like NextJS appends hashes to the filenames so they can be served with 'Cache-Control: immutable'), the app is always served from browser cache until there is a new release - which is usually weeks, not days. And if a the browser cache should be empty, you would compare waiting 500ms-1s to use an app that you will use for hours that day. If however, every link click, every route change, every interaction triggers a SSR server roundtrip, the app will not feel snappy during usage.
Now, if people chose the wrong tool for the job and use a 1MB SPA to serve a landing page, that is where things go wrong. But for me, metrics that include the download time of the .js/.css assets are pointless, as they occur once - relative to total time of app usage. After initial load, the snappyness of your SPA will mostly depend on your database queries and API performance, which is also the case in a SSR solution. YMMV of course.
> if people chose the wrong tool for the job and use a 1MB SPA to serve a landing page, that is where things go wrong
That is exactly the case. Can’t really blame the people when every learning resource, react evangelist, tweet and post points you towards that.
> If however, every link click, every route change, every interaction triggers a SSR server roundtrip, the app will not feel snappy during usage.
SPAs still do the same, maybe more round trips for API requests, we all know how endemic loading spinners have become. Rendering HTML does not meaningfully affect server response times. And frameworks like Datastar (used in this benchmark), htmx, alpine allow you to avoid full page loads.
It's a nice article about a topic I care a lot about (the need for rediscovering hypermedia, and about the magnificent Datastar library/framework).
But I fear that the comparison is less SPA vs Hypermedia than a specific nextjs app on vercel versus a specific php app on a vps. And that people will justifiably give people reason to dismiss the whole thing outright.
If anyone is inclined to do that, I really urge you to look at Datastar's website and examples to see what it is capable of.
Also to read infrequently.org for far more about spa (especially react) vs hypermedia + progressive enhancement.
The underlying architecture matters little when the SPA requires several seconds of main thread work after downloading various "blobs" of minified java script..
Hence the nextjs app on vercel (bloated mess). Plain react or svelte is performant fun fact, it’s all the cruft added on top that makes it bloated and slow.
Was expecting to see HTMX, cool to see Datastar in the wild.
Seems like people are finally rediscovering how much they can do with a lot less. Hope the push for simplicity continues