4 ms·

> 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 ver

by vecinu 4y ago

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

alkonaut 4y ago
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?
- vecinu 4y ago
  > 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.
- ngrilly 4y ago
  This is what Discourse does.
danjac 4y ago
"We built a very complex SSR framework so we can share code between client/server". Um, how many development hours did you save here?
- vecinu 4y ago
  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).
  - danjac 4y ago
    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?
flak48 4y ago
Uber? :)
adrianh 4y ago
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.
- cutler 4y ago
  But you have Turbo/Hotwire in Rails so best of both worlds, no?
the_gipsy 4y ago
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.
- danjac 4y ago
  Modern alternative would be for example AlpineJS+HTMX, or Turbo/Hotwire.
LASR 4y ago
> 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.
ehnto 4y ago
> 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.
- rawoke083600 4y ago
  >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 !
  - ehnto 4y ago
    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.
midrus 4y ago
> 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.
account42 4y ago
It's sad that the primary reason for making the site perform well is SEO and not the improved user experience.

by vecinu 4y ago

alkonaut 4y ago

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?

vecinu 4y ago
> 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.
ngrilly 4y ago
This is what Discourse does.

danjac 4y ago

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

vecinu 4y ago
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).
- danjac 4y ago
  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?

flak48 4y ago

Uber? :)

adrianh 4y ago

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.

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

the_gipsy 4y ago

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.

danjac 4y ago
Modern alternative would be for example AlpineJS+HTMX, or Turbo/Hotwire.

LASR 4y ago

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

ehnto 4y ago

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

rawoke083600 4y ago
>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 !
- ehnto 4y ago
  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.

midrus 4y ago

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

account42 4y ago

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