It’s kind of like when people ask, “Why don’t you have children?” Surely the decision to have a child should require deliberation and commitment, rather than the other way around.
From a writing point of view, it doesn’t make sense to argue for a mildly contrarian point of view with a very contrarian point of view. Having children is the default in society because everyone has parents, and so mostly people grow up around people who have children, with some exceptions. Maybe it’s a bad default, but you would have to write another, longer essay arguing for that, so it’s better to just leave the analogy out.
Having children is the default in society because everyone has parents, and so mostly people grow up around people who have children, with some exceptions
Recent trend of the US replacement rate suggest that this may not be the default in a generation or two.
When I read things like this, it’s hard not to imagine it like a patient parent explaining what a web site is to their 5-year-old. (not saying it’s a bad article, it’s just bizarre that people need to write things like this out)
Unfortunately our entire industry has become so twisted that this kind of stuff needs to be repeated a lot these days.
For a few years it feels like many web developers forgot (or never learned) that :
Yes, retuning HTML from the server is possible, it’s actually the default way to display an HTML page (even when people talk about “SSR”, they don’t really mean that, because the JS app still needs hydration to function and perform even basic navigation 🙃). And no, it doesn’t make your webapp an XSS factory if you know what you’re doing on server side (actually modern frameworks like Rails/Django/Symfony/Laravel help a lot)
Yes, writing CSS style in a CSS file by targeting HTML tags, and override these styles by targeting classes, is very powerful (and we have become so ignorant about this that we call it “classless CSS”, as if it had been invented after class-based styling 🙃)
Having to manage state on client side is extremely rare, and it’s so difficult that I don’t see why anyone would want to do it if not absolutely necessary
Having sat out of webdev for 10 years, I feel like I’m back home again with the recent trends: type-safety is a thing, server-side rendering is hip, and everyone looks at you funny when you say, “isomorphic Javascript.”
There still exists good use cases for SPAs (with the needle obviously swinging back finally to MPAs being acceptable again finally), but this is also missing that one of the key features in the SPA set up is (attempting to) fully separate the front-end & the back-end code. Back-end folks tend to write bad mark up & get intimidated by CSS & JavaScript along with front-end folks being scared of non-JavaScript back-end languages (who might also be a different paradigm) & databases like in general–where either of these two stepping in the other’s domain could cause their own issues & turf wars in review. Separating, even so far as separate repos SPAs can enable, meant the back-end builds the server connecting to the DB and hosting the API where the front-end handled all the fetching and rending in its own preferred manner (& language) where the API layer became the source of truth (with tools like GraphQL requiring even less communication to get the API “right”). The niches often require folks becoming experts in a particular part of the stack so it can’t be expected everyone be full-stack & still experts. Was this the right solution? Sometimes. Not as much as we thought(?). But it was solving some issues with teams (at often the cost of UX for the user).
Yes, but I think the flipside of that is if you have a single small team, you should avoid SPAs because it splits your team in half for no reason.
There is a latency v. throughput tradeoff in development time, and SPAs optimize for dev throughput (two parallel teams that only occasional interact through API contracts), but a small team can optimize for latency instead (just build the thing you want and deploy it without having to build an API first).
Wouldn’t disagree, but that is the logic of a lot of teams—and sometimes the lack of friction between different sides of the ball can really help the throughput for more features as you noted. It can also depend on how stylish the front-end needs to be. Simple CRUD doesn’t need fancy (even if users may kneejerk away from basic), but the more complex it is, the more one side being focused & having expertise starts to shine.
Luckily it seems HTMX & its ilk are coming thru as contemporary winners as an alternative middle-of-the-road approach for teams too as an alternative.
The more relevant question now is, why not use a meta-framework? They’ve been around for six years and are immensely popular. And yet articles like these keep surfacing as if Next.js and its successors had never been invented.
I have two answers to this “more relevant question”:
The first one is another question: “why use one?”. They are yet another layer of complexity that implies a technological lock-in (use Javascript for everything), and they do not solve the issue of the webapp being completely dependent of client-side Javascript for even basic navigation, which makes the beautiful pieces of software that are web browsers, well, simply useless, nothing more than Javascript runtimes. Just please use the power of web browsers, HTTP, HTML/CSS, you don’t need anything more 😉
The second one is a bit more philosophical: these so-called “meta-frameworks” are in no way “meta” ; it seems this name has been chosen to make people think these technologies are too smart/sophisticated/high-level for anyone to understand/challenge them, and that kind of bad naming just make me want to use anything else
I too wish I could hear a new claim made by the server render crowd. They’ve found their dead horse (SPAs circa 2015-17) and are beating it beyond recognition.
SPAs hit peak complexity in react-redux era, and we’re slowly climbing our way out. I hope to see the day when SPAs go to their logical extreme (local-first apps) and automate the “backend”/data-syncing entirely, and the irony of articles to come - “you don’t need your complex server-client apps”.
From a writing point of view, it doesn’t make sense to argue for a mildly contrarian point of view with a very contrarian point of view. Having children is the default in society because everyone has parents, and so mostly people grow up around people who have children, with some exceptions. Maybe it’s a bad default, but you would have to write another, longer essay arguing for that, so it’s better to just leave the analogy out.
Any other default probably wouldn’t last long.
Recent trend of the US replacement rate suggest that this may not be the default in a generation or two.
I missed the memo, since when are we calling websites “multi-page web apps”?
Since about 2000, when single page web apps emerged.
When I read things like this, it’s hard not to imagine it like a patient parent explaining what a web site is to their 5-year-old. (not saying it’s a bad article, it’s just bizarre that people need to write things like this out)
Unfortunately our entire industry has become so twisted that this kind of stuff needs to be repeated a lot these days.
For a few years it feels like many web developers forgot (or never learned) that :
Having sat out of webdev for 10 years, I feel like I’m back home again with the recent trends: type-safety is a thing, server-side rendering is hip, and everyone looks at you funny when you say, “isomorphic Javascript.”
There still exists good use cases for SPAs (with the needle obviously swinging back finally to MPAs being acceptable again finally), but this is also missing that one of the key features in the SPA set up is (attempting to) fully separate the front-end & the back-end code. Back-end folks tend to write bad mark up & get intimidated by CSS & JavaScript along with front-end folks being scared of non-JavaScript back-end languages (who might also be a different paradigm) & databases like in general–where either of these two stepping in the other’s domain could cause their own issues & turf wars in review. Separating, even so far as separate repos SPAs can enable, meant the back-end builds the server connecting to the DB and hosting the API where the front-end handled all the fetching and rending in its own preferred manner (& language) where the API layer became the source of truth (with tools like GraphQL requiring even less communication to get the API “right”). The niches often require folks becoming experts in a particular part of the stack so it can’t be expected everyone be full-stack & still experts. Was this the right solution? Sometimes. Not as much as we thought(?). But it was solving some issues with teams (at often the cost of UX for the user).
Yes, but I think the flipside of that is if you have a single small team, you should avoid SPAs because it splits your team in half for no reason.
There is a latency v. throughput tradeoff in development time, and SPAs optimize for dev throughput (two parallel teams that only occasional interact through API contracts), but a small team can optimize for latency instead (just build the thing you want and deploy it without having to build an API first).
Wouldn’t disagree, but that is the logic of a lot of teams—and sometimes the lack of friction between different sides of the ball can really help the throughput for more features as you noted. It can also depend on how stylish the front-end needs to be. Simple CRUD doesn’t need fancy (even if users may kneejerk away from basic), but the more complex it is, the more one side being focused & having expertise starts to shine.
Luckily it seems HTMX & its ilk are coming thru as contemporary winners as an alternative middle-of-the-road approach for teams too as an alternative.
The more relevant question now is, why not use a meta-framework? They’ve been around for six years and are immensely popular. And yet articles like these keep surfacing as if Next.js and its successors had never been invented.
I have two answers to this “more relevant question”:
Which meta-framework are you referring to?
I too wish I could hear a new claim made by the server render crowd. They’ve found their dead horse (SPAs circa 2015-17) and are beating it beyond recognition.
SPAs hit peak complexity in react-redux era, and we’re slowly climbing our way out. I hope to see the day when SPAs go to their logical extreme (local-first apps) and automate the “backend”/data-syncing entirely, and the irony of articles to come - “you don’t need your complex server-client apps”.