Inaccurate pros

[web-bert]

The app feels more responsive and users do not see the flash between page navigations due to full-page refreshes.

If you utilise caching correctly, the flash between page navigations does not occur. If your APIs respond in a timely fashion, then it will feel responsive too. Also if you employ chunked responses, the server can send the data is has straight away (like the header), then wait for APIs to respond and then send the rest of the page.

Fewer HTTP requests are made to the server, as the same assets do not have to be downloaded again for each page load.

Again if you use caching correctly, this is not true. If you are lazy loading assets, then you would probably have more when rendering in the client.

Clear separation of the concerns between the client and the server; you can easily build new clients for different platforms (e.g. mobile, chatbots, smart watches) without having to modify the server code. You can also modify the technology stack on the client and server independently, as long as the API contract is not broken.

If you separate the "server" into two parts, for example, a Python back end and a Node front end; you have clear separation of concerns and none of the downsides of doing it all in the client. You are in complete control of all versions of all the software on each server instead of running you app in an unknown and uncontrolled environment. You have the ability to re-use the APIs for mobile apps etc and can easily change the tech on either stack. Also you can easily make cross origin requests, which makes it easy to compose a page from many APIs (if required).

[yangshun]

Would you like to make a pull request to improve on the inaccuracies?

[anfengdege]

WHAT