With new frontend technologies, basically sophisticated JavaScript frameworks, and especially single page applications, this premise has changed quite a bit. The web frontend frameworks became more and more client-centric and included much more business logic than in the past. On the server side this meant that the interaction between backend and frontend moved from fine grained methods to more coarse grained, business use case methods.
So, the more client-centric and powerful the JavaScript frameworks became, the more the communication between frontend and backend went from tightly coupled requests and responses to a more API-like usage, typically JSON via HTTP. This also meant that the server-side became more client-agnostic. For example, communicating solely via RESTful-like, JSON-format APIs enables native or mobile clients such as smartphones to use the same API like the frontend does.
We have seen this movement in a lot of enterprise projects. However, one could argue about the relevance of putting more and more logic into the client side or whether a hybrid solution of having some parts rendered on the server-side and some on the client-side is more appropriate. Without going too much into this topic, let us look at a few key points.
Preparation of data or content will be performed faster on the server-side. There are more capabilities and resources available than on the client. The server can also utilize features such as caching and use the advantage of seeing the whole picture.
Sophisticated frontend technologies often include a navigation logic that makes use of so-called hashbang pages. An example of a hashbang page URL is /car-manufacture/#!/cars/1234. These pages, for example, car 1234, do not reside on the server, but are only rendered on the client-side. The URL of that sub-page is determined after the hash-sign, which is not taken into account while requesting resources over HTTP. That means that the client requests a generic entry page that then does the whole navigation logic including rendering sub-pages. This clearly reduces the number of requests, but has the drawback that the server cannot support preparing or pre-rendering content; everything happens on the client-side. There have been big companies such as Twitter that originally pursued this approach but went away from it again, due to this reason. In particular, viewing these pages on mobile devices comes with certain challenges. With potential slow mobile connections and less computing power, rendering and executing sophisticated client-logic on these devices do take longer than displaying pre-rendered HTML.
Compared to statically typed, high-level languages such as Java, JavaScript frontends do have the issue that dynamically typed languages introduce more potential errors while programming that would have been prevented by a compiler. Because of this reason, we have seen more sophisticated frontend technologies such as TypeScript emerging, which introduced static types and higher language features that are processed into JavaScript again.