How to correctly connect the work of backend and frontend?

Question

PHP

Greetings!
I want to write a website exclusively for my needs. For the backend, I decided to take the phalcon framework . But with the frontend, everything is more complicated. In the past, my client-side process was to use jquery , which resulted in a bunch of messy code.
Now, having re-read a bunch of articles about modular application design, I learned about such things as: ES6 , AMD , requirejs , commonjs , node.js , Webpack , etc. But to admit, due to lack of experience, I did not decide where to stop for the frontend. I think it's better to take ES6 + Babel +webpack . Maybe I'm wrong and it's better to take something else?
Also, it is not entirely clear how to implement client-server interaction. In particular, what to focus on more. Use the server only to receive some data, and entrust the business logic to the clientside? SPA or classic site?
I'll give you an example. The site has a navigation block. How would it be better to receive json data from the server and form a block on the client, or do all this on the server and just display the navigation block in the view? I understand that there is no single answer, but I would like to understand where to draw the line between "we do it on the backend" and "we do it on the frontend".

Answer 1

Just choose a concept:
1. Thin client. Everything is drawn by the server, the client only takes care of purely visual things, such as animations, switching elements, etc.
2. Thick client. The server sends only data to the client through the Rest API. It is desirable to have some kind of framework on the client side (ember, angular, etc.)
Keep in mind that a fat client or SPA does not make sense on its own, unless you have already done a hundred of them and you don’t have to do anything else one. It makes sense when your server simultaneously works on applications for different platforms (smartphones, tablets and desktop). In this case, it is easier to make a single server and a common Rest API through which different clients will receive data.
Doing this for one site is essentially extra work.

Answer 2

I think it's better to take ES6 + Babel + Webpack. Maybe I'm wrong and it's better to take something else?

Fine.

Use the server only to receive some data, and entrust the business logic to the clientside? SPA or classic site?

So you ask yourself a question, do you have a SPA or a classic site? App or newspaper? It makes no sense to make Gmail a classic site, it makes no sense to make a business card SPA.

Answer 3

Symbi0t :

More like a classic site than a full-fledged SPA. But it is the clientside that I would like to make modular using ES6.

Here is a bad approach. Tools are needed to solve the problem. And you have the approach - "Problems are needed to use the tools."
Moreover, getting superficial knowledge is one thing, and using it is another. With a high probability, the project will develop so slowly that you will score on dismorality.
choose one , focus on it, make the prototype work, then gradually rewrite it with new technologies (CommonJs / AMD, for example, in a small project it is quite normal to replace it with anonymous self-calling functions). Understand why you need this project at all, if this is something more than a sandbox for learning, then concentrate on this larger (content).
Try to implement some typical architectural pattern on native js in order to better see +/- frameworks (libraries), what problems they solve, and in general to understand what is happening there.