4 ms·

> SSR is great, don't get me wrong, but the reasoning that encourages devs to use it is misplaced (not WRONG, misplaced). The reason we do SSR is because we wa

> SSR is great, don't get me wrong, but the reasoning that encourages devs to use it is misplaced (not WRONG, misplaced). The reason we do SSR is because we want developers to use the same language, libraries and frameworks in the frontend and in the backend. I just don't know which kind of developers are those who cannot bother to learn something else besides JS/TS. I have heard many times the argument "we are saving developer time by using the same technologies everywhere!", but I just don't buy it.

trinovantes 4y ago
If you have a monorepo, it is pretty convenient to have synchronized Typescript definitions for communication between frontend/backend because they reference the same file. If you use different languages, then you'll need a translation layer/tool for shared interfaces and that can occasionally desync over time.
- rad_gruchalski 4y ago
  If you use something else as a source of truth, for example generate your definitions from protobuf or openapi spec, why would it get desynchronised? I’ve done a couple of openapi-based systems recently and it’s a pretty good experience. I can generate server and client stubs next to models in various languages.
  - trinovantes 4y ago
    Not every project needs to use protobuf or openapi. It's an overkill dependency for internal APIs to solve the problem of mismatching interfaces that's easily solved with a shared Typescript file used by both codebases.
    - rad_gruchalski 4y ago
      Assuming that one can afford working with TypeScript on both ends, maybe. But what if you need to support other languages? brew install protobuf && some-proto-gen-wrapper.sh job done.
- johtso 4y ago
  Even bigger than that is reusing the same validation logic client side and server side.
dismantlethesun 4y ago
On the backend, I use Python and C, however rather than use yet another underpowered slow tempting language I opted to use JavaScript for the front end views. We deliver the HTML to the client, hydrate, and everything works seamlessly. Since the static and dynamic views are built from the same code, we never have to worry about any disjunction where they fall out of sync. Also hot reloading a live JS view is a lot faster than restarting the Django server, and refreshing the page. It’s not that the team doesn’t want to learn Mako or Jinja or another language (heck one of our members designed their own language for fun) but it’s simpler and better to use JS. If it was another project maybe the trade offs would work out differently though.
zmxz 4y ago
Wanting to use same tools for backend and frontend is one of the reasons. IMO, there's only one gain to SSR and that's the one you can instantly feel when using the app - it's that the page load seems faster. That's it. Added benefit is that your app/site can be indexed by search engines since there's no XHR going on that has to fetch additional data for that first request. Using the argument that dev does not have to learn something else in the technology world - I never liked that reasoning. We, developers, use tools. Languages are tools. I, and many that I worked with, learn multiple langues over the time, whether they want to or not. I don't know a developer that doesn't know, at least, how to use CSS next to using JavaScript. That's simply what our area of work requires. If one refuses, doesn't want to or can't learn an additional tool - well, is that a developer or code plumber?
threatofrain 4y ago
SSR is not specific to JS. You can do SSR in old-school PHP. People care about SSR because it relates to how Google ranks your page, among other concerns. SSR is also part of a larger story of optimization which touches upon network concerns, such as making network requests on the server rather than on the client.
- sdevonoes 4y ago
  I assumed SSR meant "JS on the server". The new generations don't call old-school PHP templating "SSR" (sadly).

trinovantes 4y ago

If you have a monorepo, it is pretty convenient to have synchronized Typescript definitions for communication between frontend/backend because they reference the same file. If you use different languages, then you'll need a translation layer/tool for shared interfaces and that can occasionally desync over time.

rad_gruchalski 4y ago
If you use something else as a source of truth, for example generate your definitions from protobuf or openapi spec, why would it get desynchronised? I’ve done a couple of openapi-based systems recently and it’s a pretty good experience. I can generate server and client stubs next to models in various languages.
- trinovantes 4y ago
  Not every project needs to use protobuf or openapi. It's an overkill dependency for internal APIs to solve the problem of mismatching interfaces that's easily solved with a shared Typescript file used by both codebases.
  - rad_gruchalski 4y ago
    Assuming that one can afford working with TypeScript on both ends, maybe. But what if you need to support other languages? brew install protobuf && some-proto-gen-wrapper.sh job done.
johtso 4y ago
Even bigger than that is reusing the same validation logic client side and server side.

dismantlethesun 4y ago

On the backend, I use Python and C, however rather than use yet another underpowered slow tempting language I opted to use JavaScript for the front end views. We deliver the HTML to the client, hydrate, and everything works seamlessly. Since the static and dynamic views are built from the same code, we never have to worry about any disjunction where they fall out of sync. Also hot reloading a live JS view is a lot faster than restarting the Django server, and refreshing the page. It’s not that the team doesn’t want to learn Mako or Jinja or another language (heck one of our members designed their own language for fun) but it’s simpler and better to use JS. If it was another project maybe the trade offs would work out differently though.

zmxz 4y ago

Wanting to use same tools for backend and frontend is one of the reasons. IMO, there's only one gain to SSR and that's the one you can instantly feel when using the app - it's that the page load seems faster. That's it. Added benefit is that your app/site can be indexed by search engines since there's no XHR going on that has to fetch additional data for that first request. Using the argument that dev does not have to learn something else in the technology world - I never liked that reasoning. We, developers, use tools. Languages are tools. I, and many that I worked with, learn multiple langues over the time, whether they want to or not. I don't know a developer that doesn't know, at least, how to use CSS next to using JavaScript. That's simply what our area of work requires. If one refuses, doesn't want to or can't learn an additional tool - well, is that a developer or code plumber?

threatofrain 4y ago

SSR is not specific to JS. You can do SSR in old-school PHP. People care about SSR because it relates to how Google ranks your page, among other concerns. SSR is also part of a larger story of optimization which touches upon network concerns, such as making network requests on the server rather than on the client.

sdevonoes 4y ago
I assumed SSR meant "JS on the server". The new generations don't call old-school PHP templating "SSR" (sadly).