> To me this sounds of the polar opposite of the direction CMS's need to go, instead simplify and go back to the "websites" roots where a website are static fil

> To me this sounds of the polar opposite of the direction CMS's need to go, instead simplify and go back to the "websites" roots where a website are static files wherever, it's fast, easy to cache and just so much easier to deal with than server-side rendered websites. To me this wording is strange, since traditional web frameworks do render pages server-side. The specific functions of their templating engines are often even called "render" (https://jinja.palletsprojects.com/en/stable/api/#jinja2.Template.render https://jinja.palletsprojects.com/en/stable/api/#jinja2.Temp...) or "render_template" or similar (https://docs.djangoproject.com/en/6.0/topics/templates/#django.template.loader.render_to_string https://docs.djangoproject.com/en/6.0/topics/templates/#djan...). I guess "server-side rendered" is being coopted by the JS ecosystem for some time now, as if they had come up with the very idea of rendering pages on the server side. It would do the world some good, if people could just look at a technical term, understand its meaning by its components, and then not go: "Ah yes, I will use the same term, but no, no, no, I mean something different by that!" For this example: (1) "server-side": happening on the server (2) "rendering pages": various meanings in different contexts, but on the web meaning filling in information and creating parts of the HTML tree, to get a full HTML document. This has been done for decades and the result are usually, for the browser, static web pages. Static as in the opposite of dynamic. Dynamic meaning that the pages react to user interaction, meaning scripting, meaning JS.