[JodieBenitez]

> SSR feels like it was a term coined by marketers more than it does engineers.

What I see is that sometimes young front-end developers use their favorite tools (ie. the JS ecosystem) and are unaware of (or have not practiced) the "old way" of building server-side applications and websites.

[MrJohz]

There's definitely some truth to that, but I also see a lot of older developers who are equally unaware of the newer ways of developing, and then struggle to see the potential improvements there.

For example, front-end templating systems are usually come with a lot more than more traditional templating engines. I can get autocomplete on component names and attributes, squigglies when I do something wrong, type safety, as well as more logical import/scoping rules - just follow the import lines and you find where a component was defined. Meanwhile, partials tend to be much more stringly typed, have very little IDE support, and often still seem to use a global partials folder to define reusable components.

The other big thing that I miss in traditional templating engines is scoping for web technologies. Being able to collocate styles and HTML structure is incredibly useful, and makes it a lot easier to share components around in different contexts. Similarly, if I have an accordion partial that uses a bit of Javascript for progressive enhancement, it's very useful to be able to group that Javascript with the partial, scope it to that context, and let the templating engine hook everything up. Scoped CSS (however you implement it, be that CSS modules, CSS-in-JS, tailwind, or whatever else) is a godsend for making really robust components, and I've never found anything even half as good on the server side.

[JodieBenitez]

> There's definitely some truth to that, but I also see a lot of older developers who are equally unaware of the newer ways of developing, and then struggle to see the potential improvements there.

Hey, we were just waiting for the dust to settle, we're catching up now ;)

[boredtofears]

It's not clear to me what you're describing is a "newer way of developing". Type safety and IDE autocompletion are nothing new - these are decades old concepts that are finally making their way to dynamic languages like javascript. Scoped CSS/JS isn't a unique concept to SPA's, you can absolutely implement the same thing in a page loading app.

[MrJohz]

Type safety in templating is almost unheard of though, alongside autocomplete for things like template arguments. For example, in JSX, if I write <Header [CTRL+SPACE], I immediately get a list of all the keyword arguments I could pass to that component, plus documentation, types etc, just like I'd get if I'd been calling a function in, say, Java. And if I pass the wrong arguments, I'll get errors at compile time or in my IDE.

I know there are a handful of tools that can do this for server rendered templates, but they are very rare and very underutilised, and typically don't have the LSP/IDE support that JSX or single-file-components do.

I do not know any server-side templating languages that do scoped CSS, much less any sort of scoped JS. By that I mean, I can write a CSS declaration (in CSS syntax or otherwise) and guarantee that it will only be used in one place, scoped to a single component (or template partial). This means I'm no longer stuck with the global CSS namespace, and I can link my CSS files directly with the components that use them.

[boredtofears]

Type safety in templating has been available for templating systems that are built on statically typed languages for literally decades now. This isn't anything new, it's just new to javascript solely because of typescript.

None of the concepts you're talking about are unique to SPA's. A cursory search for "CSS modules rails" or "tailwind django" turned up several pages of results.

[MrJohz]

There are precious few type safe templating systems, and they're mostly fairly niche. And even then, while they're often type safe, the developer experience is typically lacking, with minimal IDE support. Meanwhile, Vue redesigned their API partly because types were difficult to properly implement in previous versions, and then built an entire LSP to facilitate that.

Likewise, your cursory search for CSS modules in rails mainly returns blog posts where people try and hack things together to get CSS modules working well enough. The top result for me literally wrote "I tried to find a cool way to integrate CSS Modules into our Rails project, but I cannot", then explains how they parsed CSS by themselves. (I can't get further than that, because Medium.) Meanwhile, adding CSS modules to a project bundled with Vite is literally just a matter of naming your files `.module.css` instead of just `.css`.

Tailwind is a bit of an exception, as it seems to be more popular with backend frameworks, I think because it relies less on Javascript idioms like imports. I suspect we'll see it - or at least similar ideas - integrated into more frameworks over time.

But to me coming from the frontend, this sort of stuff is table-stakes - having IDE support, having Typescript support (and good TS support), being immediately accessible without spending a day fiddling with fifteen different plugins, etc.

[boredtofears]

Java Server Pages? Spring MVC? asp.net MVC? razor pages? go templates? None of these are niche and they all have had first class IDE support for, again, literally decades.

Concepts like CSS modules may not be as trendy in server side rendering frameworks, but that doesn't mean the concept itself is inherently limited to SPA's.

Things like IDE support have been table stakes for backend developers working in static languages for a very long time. Javascript tooling is just now finally catching up.