Like with anything, that might be a good strategy in some situations, but not in all. For example:
* If you have some secrets that need to stay hidden (e.g. database passwords, API keys, encryption keys, etc) then that needs to be processed by code that lives on your servers. If all your code runs on the client, then there is always the chance for an attacker to discover those secrets.
* It is often easier to present a smaller, limited API to the client to reduce the surface area available to attacks. For example, if you let the client connect directly to your database, you need to make sure that that database is correctly secured, that the correct permissions are there, and that nothing can go wrong. But if you just give them a list of books, or films, or whatever your app does, then it will be harder for them to break through that defence. (And if they do manage that, you should still have the database set up as securely as possible to provide an additional layer of defence.)
* A site often feels more responsive if the initial load is served as one single chunk of ready-to-use data (as opposed to serving the application, showing a loading indicator, making the necessary data fetches, then showing the data). Even if they take the same time the first option often intuitively feels quicker to the user.
* Leading on from that, it can often be quicker to load things up front, just because the server that's responding to the user is probably sitting next to your database and any other servers it needs to talk to. These network calls are also much more reliable in that sort of context. If you push all of the processing to the user, you're going to have to handle the slower and more unreliable calls.
* The server will probably be a much more consistent platform than user browsers. Browsers are a lot better these days, but there are still lots of slight differences that you'll need to be aware of. If you have control of a server, though, you can specify the exact versions of every tool, runtime, etc that you need, and be able to update things more deterministically.
Fwiw, these aren't all true all of the time, and there will be exceptions. I work primarily on frontend applications, and there's a lot of value in a well-designed application that does the majority of work, if not all, in the browser. But this is typically only true for fairly complex web apps, or projects where some amount of rendering has to happen in the browser whatever happens.
* If you have some secrets that need to stay hidden (e.g. database passwords, API keys, encryption keys, etc) then that needs to be processed by code that lives on your servers. If all your code runs on the client, then there is always the chance for an attacker to discover those secrets.
* It is often easier to present a smaller, limited API to the client to reduce the surface area available to attacks. For example, if you let the client connect directly to your database, you need to make sure that that database is correctly secured, that the correct permissions are there, and that nothing can go wrong. But if you just give them a list of books, or films, or whatever your app does, then it will be harder for them to break through that defence. (And if they do manage that, you should still have the database set up as securely as possible to provide an additional layer of defence.)
* A site often feels more responsive if the initial load is served as one single chunk of ready-to-use data (as opposed to serving the application, showing a loading indicator, making the necessary data fetches, then showing the data). Even if they take the same time the first option often intuitively feels quicker to the user.
* Leading on from that, it can often be quicker to load things up front, just because the server that's responding to the user is probably sitting next to your database and any other servers it needs to talk to. These network calls are also much more reliable in that sort of context. If you push all of the processing to the user, you're going to have to handle the slower and more unreliable calls.
* The server will probably be a much more consistent platform than user browsers. Browsers are a lot better these days, but there are still lots of slight differences that you'll need to be aware of. If you have control of a server, though, you can specify the exact versions of every tool, runtime, etc that you need, and be able to update things more deterministically.
Fwiw, these aren't all true all of the time, and there will be exceptions. I work primarily on frontend applications, and there's a lot of value in a well-designed application that does the majority of work, if not all, in the browser. But this is typically only true for fairly complex web apps, or projects where some amount of rendering has to happen in the browser whatever happens.