I disagree, the problem with an SPA is that now you have two places where you manage state (the backend and the frontend). That gives you much more opportunity for the two places to disagree, and now you have bugs.
Every form also normally ends up duplicating validation logic both in JS for client-side pre-submit UX and server-side with whatever errors it returns for the JS to then also need to support and show to the user.
Anecdotally, it seems like I encounter a lot more web apps these days where refreshing doesn’t reset the state, so it’s just broken unless I dig into dev tools and start clearing out additional browser state, or removing params from the URL.
Knock it off with all the damn state! Did we forget the most important lesson of functional programming; that state is the root of all evil?
There are times the user experience is just objectively better with more state, and you have to weigh the costs.
If I am filling out a very long form (or even multi-page form) I don’t really want all that state lost if I accidentally refresh the page.
Which is what HN does and it sucks. It's very common for me to vote on a couple things and then after navigating around I come back to see that there are comments that don't have a vote assigned.
Of course the non-JS version would be even more annoying. I would never click those vote buttons if every vote caused a full page refresh.
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 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.
Very limited though, but it's still early days.
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.
We can sit here all day and think up counterexamples, but in the real world what you're doing 99% of the time is:
1. Presenting a form, custom or static.
2. Filling out that form.
3. Loading a new page based off that form.
When I open my bank app or website, this is 100% of the experience. When I open my insurance company website, this is 100% of the experience. Hell, when I open apartments.com, this is like 98% of the experience. The 2% is that 3D view thingy they let you do.
Notification count in the top right?
Remaining credit on an interactive service (like the ChatGPT web interface)?
So, maybe two(!) business use-cases out of thousands, but it's a pretty critical two use-cases.
I agree with you though - do all normal HTML form submissions, and for those two use-cases use `setInterval` to set them from a `fetch` every $X minutes (where you choose the value for $X).
There's an entire domain of apps where you truly need a front-end. Any desktop-like application. Like Google Sheets, or Figma. Where the user feedback loop is incredibly tight for most operations.
Most companies aren’t international.