You don't need an SPA to handle incrementing a counter. If a page needs dynamic behavior you add JS to it, whether it's just adding an in-memory counter or an API call to store and retrieve some data. It's not difficult to write JavaScript.
The problem with SPAs is that they force having to maintain a JS-driven system on every single page, even those that don't have dynamic behavior.
> You don't need an SPA to handle incrementing a counter. If a page needs dynamic behavior you add JS to it, whether it's just adding an in-memory counter or an API call to store and retrieve some data. It's not difficult to write JavaScript.
I agree with this. Sprinkle in the JS as and when it is needed.
> The problem with SPAs is that they force having to maintain a JS-driven system on every single page, even those that don't have dynamic behavior.
I don't agree with this: SPAs don't force "... having to maintain a JS-driven system on every single page..."
SPA frameworks do.
I think it's possible to do reasonably simple SPAs without a written-completely-in-JSX-with-Typescript-and-a-5-step-build-process-that-won't-work-without-25-npm-dependencies.
I'm currently trying out a front-end mechanism to go with my high-velocity back-end mechanism. I think I've got a good story sorted out, but it's early days and while I have used my exploratory prototype in production, I've only recently iterated it into a tiny and neat process that has no build-step, no npm, and no JS requirement for the page author. All it uses is `<script src=...>` in the `<head>`, with no more JS on the rest of the page.
A codebase doesn't need that toolset to be an SPA. An SPA is just a website where all the site's functionality is done on the "root page", and it uses JS to load the data, handle navigation, etc. Doesn't matter whether that's all done through React in TypeScript and compiled by Vite or by handrolled JavaScript fetched in .js files.
> A codebase doesn't need that toolset to be an SPA.
That's kinda the goal I'm trying to reach. If you know of any SPA that doesn't come with all the baggage and only uses `<script src=...>`, by all means let me know.
True, I shouldn't have said in memory. As the GP mentioned, you can store the counter value in a URL param. There are ways to achieve dynamic behavior without having to load or store values into JS memory.
That is more work both for the developers and the servers though. You need to re-render the whole page every change, rather than make a local change (or a tiny request if it needs to persist)
You misunderstood what I was saying. I was saying that you could write some plain old JS to catch an event on incrementing and updated the URL and the UI, and some JS to get the data from the URL on page load to set the UI. No new server render, and that's maybe 5 minutes of writing JavaScript code (compared to, say, setting up react project and instantiating that whole beast from the page root until reaching the specific UI element that needs to be dynamic).
The problem with SPAs is that they force having to maintain a JS-driven system on every single page, even those that don't have dynamic behavior.