When to use a SPA with server rendering, and when to use a regular site?

Question

Frontend

Good day. There is a site design, the question is whether to do it as a SPA on Nuxt or as a regular site with page reloads. Is it purely a question of fashion and the ability to transition without a reboot, or is the main aspect the separation of the front end and back end parts?

Answer 1

Fashion is, of course, but not only in it!

the question is whether to do it as a SPA on Nuxt or as a regular site with page reloads

Depends on the backend, if the backend makes an api for you, then you only need SPA (no matter what), and if the old fashioned way, then the old fashioned way, with page reloading. How to agree here.
Advantages of the approach of separating the back and front ala SPA:

1. The division of responsibility itself. The front is responsible for the display, the back is for the data. This is their essence.
   
2. Convenience of work. You work exceptionally with the code base that you understand, that is pleasant.
   
3. separate repositories. Each environment decides for itself how it is best for them to contribute features, without regard to each other. The front should not care about updating features and resolving possible conflicts with the back-end code. You work exclusively with your codebase
   
4. Spa benefits in and of themselves. Updating only the necessary sections of html, faster solution of routine tasks, due to the automation of many ala processes (vue cli, nuxt, etc. - everything is already assembled and configured out of the box, just write the code), splitting the code into chunks, etc. p.s. I think it's clear
   
5. What no, but the architecture of the application.
   When deploying a project through cli, you are already given the initial folder structure, which already indicates that you do not need to think at least about this. You know in advance (if you have experience, if you don’t, nothing will help you figure everything out) that you need certain features of the framework to solve certain features.
   At least react, at least vue, even more so angular.
   

Cons of the approach of separating the back and front ala SPA:

1. Setting up the entire deployment of the application on the server. Set up gitlab.ci, set up docker, set up vps (if not ready already), set up nginx (not always, but it happens). Or do you think someone will do it for you? The backend will set everything up for itself, and let's do it yourself. You wanted separation. God forbid that you have an admin in your company who deals with such issues or just a sidekick who is ready to help you.
   
2. SEO is the big problem of our time. If SEO, then ssr, if ssr, then nuxt (well, or adjust the handles, good luck). This is where node.js comes into play. It would still be run on the server, hang on the port, etc. It’s just that SPA has collected everything, but SEO, SEO throws crap and work on us.
   
3. The implementation of "modules" from 0, which in the old approach can already be downloaded from the back (from the store of ready-made solutions, for example, if it is a CMS, well, or ready-made packages from frameworks) and run (a basket of goods, filters, catalogs, sorting, etc. things). At the front, everything will have to be done anew, because there are no ready-made solutions.
   If you take some kind of WordPress or Bitrix, where there is already a huge number of ready-made solutions that you have connected and they work, minimally + - correcting styles, then in the spa approach, God forbid that these solutions have a rest api for your miracle spa. And you, in turn, will clip the layout and logic from 0, tormenting yourself with a bunch of requests, updating data, etc. things.
   And writing an order with a choice of delivery, and a choice of an address on the map, followed by a choice of a bunch of other points when placing an order, is a gesture. But write it yourself, but SPA, vue. And if there is some kind of authorization, and with twists or through some external oauth server, then it’s beauty in general)))
   
4. Difficulty understanding which side the error occurred on. The front will always act in the forefront. All stones will fly towards you. Something didn’t work out, front come here, the form didn’t go, froooont, awww!!!!!
   How can you blame managers for this? They should not sit around clicking f12 and analyzing where and what kind of error happened.
   Sometimes the back is to blame, sometimes the front.
   Yes, you can connect some kind of sentry. But this, in my opinion, only proves that our approach complicates support and development. Now we have 1 more site where we look at the logs of the front, what happened to it. Everything is simple for the back, I went to the page, bam, the sql error is on the whole page, everything becomes clear)))
   Of course, this is not really serious, but the grain is in these words. Sentry is a good thing, but it will be indispensable for solving these problems. Otherwise, to understand on whose side there are incomprehensible errors that are not clear how to identify, and the logs at the node lie where the devil is, if you or your admin did not set them up like human beings.
   
5. Very frequent dependence on backend data. 1 field at the back has changed, you most likely need to go and edit it. A new field has been added, run again and display 1 variable. Damn it, bek, can’t you deduce a variable yourself ??? Oh yes, we have a SPA.
   
6. Hiding behind the convenience and fashion of SPA, you can do such shit. Any fool can make components, but to create chaos from these components and not understanding how to more or less clearly solve the problem of serious tasks and organization of the code base, yes. Not everyone realizes what they are signing up for. Otherwise, you wouldn't be asking these questions.
   At a time when the backend would do everything for you, because a lot of it is already ready, and you would just give it the layout and that's it. Well, they would sometimes make it up, well, they would add a couple of scripts.
   
7. And finally, the rise in the cost of supporting such a project. Because instead of a single code base, now there are 2 of them. Making changes requires more people than with the usual approach. A backender without a front can write a jquery ajax request or display a button with a modal window and a form, because very often they use bootstrap stupidly and it’s easy to assemble such blocks, or simply display a new field with text or something else.
   

I have given you food for thought. Everything I wrote is valid. Tasks may differ, projects may differ. But the essence of my words from this is unlikely to change. In most cases, I am for a separate approach to writing projects.

Answer 2

In addition to the words of Dima Pautov , I will add that SPA can be convenient in web applications with a large amount of dynamically changing data. For example, Dashboard. If you have, conditionally, an online store, I would stop at the classic version and not chase fashion.
And as it was written in one article of a popular site:

A good developer should always aim for a split site development approach.