Hacker News Reader

Comment by vecinu | Hacker News Reader

> So I think that SSR (running JS on server) is rarely useful.

I would disagree for a couple of reasons. The team I work with at a large SV company built a very complex SSR framework for our mostly static app for 2 reasons:

- Isomorphic codebase, you can share the majority of your code with the client/server since it's Node on the backend and ES2015 on the frontend

- SEO. Google penalizes your site for slowness and more often than not it can't even render some pages the way you'd expect. Attempting to "fix" that through client-side hacks is a fool's errand and you're likely to get penalized.

View on HN

> mostly static

> SSR is justified because isomorphism

> SSR is justified because SEO

I think the fundamental problem is that you have a mostly static site and yet chose to write it like a non-static SPA.

SSR now bridges the downsides of this mismatch.

But the point is that SSR is a solution to a problem introduced by some sub-optimal decision-making.

If you had a use case that necessitated a SPA, then it is understandable.

If you just built a static site, then you don’t need isomorphism and your SEO would also be straightforward.

Do you realize that neither points justify SSR? You only need those because you introduced SSR.

Anyway, there are webapps that fall between the highly interactive webapp examples of the GP, and static sites. With just enough interactivity that static + sprinkled JS becomes unmanageable. In that area I would really like to see a comparison between SSR (which everybody seems to jump on) and alternatives like... knockout.js? I don't know what's a modern alternative.

Modern alternative would be for example AlpineJS+HTMX, or Turbo/Hotwire.

Sorry, I’m not seeing how this overengineered solution adds any benefit…?

If it’s a mostly static site, just use Django or Rails and be done with it. SEO becomes a non-issue and your code stays in a single (server-side) language.

But you have Turbo/Hotwire in Rails so best of both worlds, no?

"We built a very complex SSR framework so we can share code between client/server". Um, how many development hours did you save here?

Honestly that's difficult to quantify, if not impossible.

The beauty of what we've done is that other microservices internal to our corp are also leveraging said SSR code and can bootstrap their own backend very quickly. We've been following the BFF pattern (Backend for frontend).

I know big SV companies have money to burn, but surely there was some project management in place to quantify the cost of building such a complex, in-house solution?

> SEO. Google penalizes your site for slowness and more often than not it can't even render some pages the way you'd expect. Attempting to "fix" that through client-side hacks is a fool's errand and you're likely to get penalized.

This is the only realistic reason I have seen to be honest. Isomorphism is a tool that you use to achieve a statically rendered site that you can give to Google, that will then become highly dynamic in the hands of the user.

But if you've got a mostly static site, what's the point of all the complexity? Why not just make a static site a more simple way, rather than using SPA tooling. Either you have highly interactive site or you don't, and if you do have an SPA style site, and need to appease Google, you might need SSR. Otherwise, use the right tool for the job and cut out the complexity is my opinion on the matter.

>SEO. Google penalizes your site for slowness and more often than not it can't even render some pages the way you'd expect. Attempting to "fix" that through client-side hacks is a fool's errand and you're likely to get penalized.

SEO aside(that is another discussion), but Google "requiring" your site to be fast is a net positive for consumers/us !

It has been of benefit I will admit, but I think for SSR in particular it can make things worse since you wait until a user interacts to spin up the application so to speak. But like anything, you can do this well with enough care.

> Isomorphic codebase, you can share the majority of your code with the client/server since it's Node on the backend and ES2015 on the frontend

I've been working for 20 years on this, last 8 ~ 9 only with node and React and not a single time, other than sharing some validation rules and/or for SSR, got anything useful out of having the possibility of running the same code in the browser and on the server... totally different responsibilities, libraries, requirements and environments.

Does SSR need to be so complex for SEO? Can't the backend basically throw its hands up and render a trivial (e.g. "reader mode" text view) version, as soon as a browser isn't detected properly, or determined to be known a bot/crawler? E.g. you skip all interactivity, layout etc. I assume Google would have to penalize sites that render something completely different to their bot, or else bait and switch would be rampant?

> I assume Google would have to penalize sites that render something completely different to their bot, or else bait and switch would be rampant?

That's correct. They call that "cloaking" when you render different content for a crawler than for a normal user. Google is rewarding sites for making the UX better for the end user.

> Can't the backend basically throw its hands up and render a trivial (e.g. "reader mode" text view) version

We're actually experimenting with this approach in a couple of different ways. One approach we're testing now is using AWS Lambda to render a fairly static version of the page using puppeteer. So far the results are promising as the page is true to what the end user would see (except for client-side logic / AJAX requests) and it renders much quicker than the standard experience with all the analytics/JS libraries we use.

This is what Discourse does.

It's sad that the primary reason for making the site perform well is SEO and not the improved user experience.

Uber? :)

Reply on news.ycombinator.com