[jongjong]

- Server side rendering is essentially a hack to work around web crawlers' inability to parse dynamic single page apps... My first issue with this is that it doesn't make sense to me why someone would build a high-exposure public website/landing page as a dynamic single page web app, what you really need is a website; these are much more lightweight, easier to cache and deliver over CDN and they use up far fewer resources (no need to serve libraries which are not necessary for the current page). Also, why would you want web crawlers to parse a dynamic application (e.g. dashboard and private areas)? It shouldn't even be visible unless the user is authenticated (which the crawler is not!). What should you show the web crawler in that case? Do you really need Google to see all your apps' form templates with all the empty input fields? SEO is for marketing; in this case, you need a website with a landing page and potentially a blog, not a dynamic single page app.

- About bundling, the current reality is that frameworks like React come with a huge amount of dependencies/boat... On the other hand, native Web Components require no dependencies. Web Components will generally load much faster even without bundling than React + all dependencies in a bundle because those bundles are often huge... Not to mention that nowadays, tags expose some nice attribute which let you control the loading and execution order of scripts in a highly fine-grained way (e.g. async and defer attributes on the script tag). That's even without going into the fact that since HTTP2, servers have the ability to preemptively push resources to the client without any round-trip latency. Also, loading resources separately allows for more fine-grained cashing with CDNs; you share some components between some pages and you only need to load what you need explicitly as needed.

[boredtofears]

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

Every time I hear someone describe their reasons for using SSR I usually can't figure out why they're building an SPA in the first place.

[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.

[azangru]

> Server side rendering is essentially a hack to work around web crawlers' inability to parse dynamic single page apps... My first issue with this is that it doesn't make sense to me why someone would build a high-exposure public website/landing page as a dynamic single page web app, what you really need is a website

Even when building a website, it is exceedingly convenient to compartmentalize large chunks of code into small, manageable UI components that can then be composed together. You will remember the uniquitous "partials" in server-side templating languages/engines/frameworks, such as rails, blade, or nunjucks. Such partials are good for extracting markup; but they do not solve the problem of co-locating the markup with the styles and interactivity associated with it. You can see an attempt to achieve this vision in such projects as Enhance, or webc, or even Astro, whose focus is on building html-first, server-rendered "websites" out of small UI components. But the syntax that these projects use is non-standard and unique to each of the projects. We are in dire need of a web standard way of doing sane server-side templating, which web components could have helped achieve; and my hope is that they will; only right now they still suck at this.

[zarzavat]

> Even when building a website, it is exceedingly convenient to compartmentalize large chunks of code into small, manageable UI components that can then be composed together.

React was designed by Facebook, a website that is mostly behind a login wall and not indexed. The complaint that React is bad for SEO is therefore somewhat ahistorical. Of course you can use React as a templating engine with SSR and it works just fine, but the original value proposition of React was interactivity.

It seems that nowadays the majority of people are using React in non-interactive contexts, which can be a bit weird for those of us who adopted it as a replacement for jQuery, rather than as a replacement for template engines.

[azangru]

I did not even mention React in my comment :-) React isn't web components. React didn't even invent the idea of a ui component. I agree that Facebook created React for large interactive web sites; and I know that as a server-side templating engine, React is very slow compared to competition; which is why I desperately want web components to succeed on the server and to stardardize ergonomic component-based templating.

[JodieBenitez]

> what you really need a website

finally some sanity

[yoz-y]

To me this seems to be the root of all problems with SPAs. They are mis-used for websites, and so a ton of technology has been built to make them work like those. Nobody cares about SEO in Figma, or your blog's web editor. We wanted to have a single hammer for everything and now the hammer has three handles.

[jongjong]

Agreed, and one of the nice things about Web Components is that it makes it practical to build dynamic components for use on multi-page websites since the bandwidth overhead for including a component into a page is so small (since most of the logic is built into the browser). No need to include an entire framework bundle just to include a small component. For example, I built a dynamic navbar as a Web Component and I just included that component on multiple pages (great for code re-use). All pages loaded instantly. I could never do that with a framework.

I'd never considered to implement a multi-page website navbar as a front-end component before. For code reuse in a multi-page website, one would typically rely on a server-side pre-processing engine (e.g. PHP, ASP.net, ...) but the pervasiveness and lightweight nature of web-components now makes this a possibility.

[troupo]

> All pages loaded instantly. I could never do that with a framework.

Of course you could. Depends on framework, but you certainly could.

[dgb23]

I like the typo “cashing”!

It’s like we’re “cashing” in on REST being inherently cache friendly.