> Calling this argument a strawman is pretty dismissive and is not a technical arugment.
It's quite literally a technical argument, and not "dismissive" in the slightest. My first sentence tells you why it's a strawman: there is no such thing as a "server-rendered" app. The framing of the original comment was black-and-white, when reality is (and has always been) shades of gray. Webapps have, since basically the earliest days of the internet, a question of where you draw the line between server-side and client-side rendering. Leaping to SPAs is just as lazy and thoughtless as trying to do everything on the server.
> There are lots of client side interactions that do not need to be blocked on data from the server. Popup menus, modals, collapsible lists, rich text editing etc.
Yes, of course. And if you implement your popups, modals, accordions and whatnot via asynchronous server calls, you are doing it in a silly way that guarantees bad performance.
There's a middle ground. For example: you can trivially render top-level dynamic elements (like menu content) into a SSR page. It doesn't require an SPA, yields imperceptible UX latency, and allows you the ability to do things like SEO without crazy infrastructure.
(Oh, and you don't need to "boot the app" in the browser. That's latency too.)
There's clearly something else going on here because I am having trouble following this argument.
You pretty clearly laid out what you meant by server rendered in your original comment:
> Were I forced to write a website today, it’d still end up looking similar to a traditional Django server-side rendering system with pages, and deep links, and all that.
Nowhere did I advocate leaping to SPAs for no reason. I simply made the case - and stand by it - that building with the same set of technologies client and server side leads to more flexibility and less code.
Re: the comment about booting the app, I think that is one of the strongest arguments in favor of server rendered apps, which is why I qualified my comment to "interactions", which happen after the page loads.
I lived through the server-rendering-only days of the original Hotmail client, and the php-plus-jquery spaghetti era. They were terrible for developers and terrible for users. Going backwards would be a huge mistake.
> Were I forced to write a website today, it’d still end up looking similar to a traditional Django server-side rendering system with pages, and deep links, and all that.
I didn't write this. You're confusing me with someone else.
It's quite literally a technical argument, and not "dismissive" in the slightest. My first sentence tells you why it's a strawman: there is no such thing as a "server-rendered" app. The framing of the original comment was black-and-white, when reality is (and has always been) shades of gray. Webapps have, since basically the earliest days of the internet, a question of where you draw the line between server-side and client-side rendering. Leaping to SPAs is just as lazy and thoughtless as trying to do everything on the server.
> There are lots of client side interactions that do not need to be blocked on data from the server. Popup menus, modals, collapsible lists, rich text editing etc.
Yes, of course. And if you implement your popups, modals, accordions and whatnot via asynchronous server calls, you are doing it in a silly way that guarantees bad performance.
There's a middle ground. For example: you can trivially render top-level dynamic elements (like menu content) into a SSR page. It doesn't require an SPA, yields imperceptible UX latency, and allows you the ability to do things like SEO without crazy infrastructure.
(Oh, and you don't need to "boot the app" in the browser. That's latency too.)