What is the difference between template engines and server-side rendering?

In ~2015-2020: Django, Flask, Laravel, etc. All these frameworks had the pretty good template engines.

But in ~2018-2020 "modern" developers said that templates are old-fashioned. To much data is transferring between sever and client. It is much more effective to transfer only JSON-data and generate heavy HTML-code at client side. The future for single page applications. Vue, React.js, Angular, whatever is a new standard.

Nowadays it is 2023 and (they saying) SPA is very slow and using many resources at client side. The good style and killer-feature is a using of Server-Side Rendering.

I'm trying to learn what SSR is and how it works. And each time I see nothing but the wheel has returned to its original position and the "modern" SSR is a good old templates engine, but limited for Node.js backend.

What is the real difference? Both of ways are focused on returning pre-rendered HTML data. Why is Server-Side Rendering available only for Node.js? If you Google "Server-Side Rendering" most of the examples will be based on Node.js backend. But if you Google "Server-Side Rendering Python", here is a Flask and "legacy" template engine.

> I'm trying to learn what SSR is and how it works. And each time I see nothing but the wheel has returned to its original position and the "modern" SSR is a good old templates engine, but limited for Node.js backend.

Yes, more or less. There are some differences, but (1) SSR assembles html on the server from data about how to put that html together, i.e. templates and (2) the term is exclusively used (at least in my experience) for Node.js.

That said there is a difference, and it's largely genealogical. In template-style rendering you often write most of the logic into the html, interspersed with the odd callout (php or perl style CGI), or you write placeholders in the html template and populate them (jinja2 style, like in flask). Of course you don't have to do any of this. Nothing stops you writing a php site which uses string interpolation to build pages, or using multiple rendered sub-templates wrapped inside objects sharing business logic, pulled together by a dynamically developed populated template in django. But I think I've described the usual style of those frameworks accurately enough.

With 'SSR' you often have (i) developers who think in SPA frameworks like Vue, where 'template' and 'logic' often belong together in units which are composed more or less dynamically (Vue 'components'), and the language (JS/TS) is arguably closer to the structure of the resulting DOM, encouraging the kind of conditional building you'd have to think twice about in, say, python, and (ii) applications which started out as SPAs and have since realised that everything (or most) can in fact be rendered in advance or on the fly, i.e. the SPA framework wasn't a good fit for what the site ended up doing. The resulting design is, I think, frequently distinctly recognisable. You could write the same style in e.g. django---and sometimes a basic site generated from a single template would be a lot cleaner---but the family likeness is visible.

Thus I don't think this question (or this answer) is just opinion. These are different tools, they grew up in different contexts, and they suit slightly different problems. The right tool for a page which displays generated content is probably a CGI. The right tool for lots of websites is a static site. The right tool for pulling your massive SPA back onto the server when it turns out to be a glorified CGI interface might be SSR. (I'm sure there are positive uses for them too )

Separately, although I share your frustration about reinventing the wheel, this is just what happens in all domains of human effort. Whenever the wheel comes back one just has to improve it until it performs almost as well as the old wheel, admire the new paint, and move on