Generating UX/UI in the backend doesn't imply to use old tooling. React server side rendering, Vue's Nuxt, etc are all modern ways to render UX/UI in the backe

Generating UX/UI in the backend doesn't imply to use old tooling. React server side rendering, Vue's Nuxt, etc are all modern ways to render UX/UI in the backend for example. And there are more. The discussion of rendering server side goes deeper than just performance or using a "modern" framework. There is for example: how many teams can work on a single application at the same time and deploy independently features in an efficient manner. How can we share business processing flow requirements between the web version of an application with the native mobile application counter parts in an efficient way, without implementing everything three times. Or other aspects mentioned here, like predictable performance etc. Or choice of language, in the backend your choice of languages to choose is greater and/or simpler than in the frontend. You can add more monitoring in the backend about aspects of your application than you can do in the frontend. Obviously, the frontend has advantages as well. I.e. if something needs to be calculated, animated it is almost instantly available to the user when done in the frontend. Frontend can perform functions offline, can use device specific features: like camera, contact list, push notifications etc. Thus I prefer to look at the requirements and pick the tools for the job that best fulfils all the requirements for a giving application in a given organization and strategy. If that means i do more stuff in the frontend, sure fine. But I wouldn't go for GraphQL just because it is "modern". Being "modern" is not solid reason to choose a technology unless you want to attract developers that like "modern" technologies. Which could be a valid reason as well for some organizations.