6 ms·

> Use server-side rendering if possible. Doesn't this lead to an unnecessary increase in complexity without any immediate benefit? > API development is a wast

by nuerow 5y ago

> Use server-side rendering if possible. Doesn't this lead to an unnecessary increase in complexity without any immediate benefit? > API development is a waste of time. Why do you think so? Doesn't a well developed API mitigate, if not eliminate entirely, needless increases in complexity?

sdevonoes 5y ago
Care to elaborate? In my mind, server-side rendering means: no more JavaScript framework to maintain (and that means: webpack + babel + a few hundred npm dependencies).
- nuerow 5y ago
  > In my mind, server-side rendering means: no more JavaScript framework to maintain Not necessarily. All the major JavaScript frameworks also support server-side rendering, which is used to improve load times and perceived performance.
  - satyrnein 5y ago
    I think the suggestion here is for the likes of Django or Rails, not next.js
renke1 5y ago
With server-side rendering you don't have to create yet another layer to actually transfer the data to the client just to render it. It usually also implies that you don't have build your data model in two different languages ($BE_LANG + JS/TS); of course there are things like JSON Schema, OpenAPI and whatnot to mitigate that, but they have their own share of problems. Developing an API may also be a waste of time when your client-side application is the sole consumer of the server API. This is especially true when people try to build an API that does too much (often seen when building REST-style HTTP APIs) instead of a more usecase-based (or even view-centric) API.
- nuerow 5y ago
  > With server-side rendering you don't have to create yet another layer to actually transfer the data to the client just to render it. That layer doesn't go away with server-side rendering. It is always there, even if you don't use a REST API. It just gets fused with views. In fact, I'd argue that this perception that server-side rendering gets rid of that layer is a telltale sign that the project is already plagued with accidental complexity. > It usually also implies that you don't have build your data model in two different languages ($BE_LANG + JS/TS); Unless the front-end is written in pure HTML+CSS, this hypothetical simplification doesn't materialize. Also, you can't brush off or ignore the complexity added by templating engines. > Developing an API may also be a waste of time when your client-side application is the sole consumer of the server API. I don't get what point you're trying to make. Even if you are the only client for that API, don't you still need to put it together and maintain it?
  - arethuza 5y ago
    "Unless the front-end is written in pure HTML+CSS" But that can be "good enough" for many applications - look at how the site we are discussing this on works as an example....
    - nuerow 5y ago
      > But that can be "good enough" for many applications I disagree. If you expect any type of non-trivial user interaction from the front-end, you'll find most of your needs is not practically possible to implement without javascript running on the client-side. > look at how the site we are discussing this on works as an example.... Please note that even HN loads javascript, which also makes AJAX calls to the backend.
      - arethuza 5y ago
        Something like 142 lines of pretty easy to understand JavaScript....
  - renke1 5y ago
ec109685 5y ago
Server side rendering also nicely avoids the multiple round trip problem the author mentioned given browsers are inherently request / response so forces one stream of html output. While you can be careful about round trips with client side rendering, and graphql helps in that regard, it’s easy to create hidden bottlenecks.
Zababa 5y ago
> Doesn't this lead to an unnecessary increase in complexity without any immediate benefit? Why do you think using server-side rendering leads to an unnecessary increase in complexity without any immediate benefit? > Doesn't a well developed API mitigate, if not eliminate entirely, needless increases in complexity? It does when multiple clients consume that API. The point of GP is, I think, that you shouldn't start with the assumption that you will have at some point multiple clients and prepare for it.

by nuerow 5y ago

sdevonoes 5y ago

Care to elaborate? In my mind, server-side rendering means: no more JavaScript framework to maintain (and that means: webpack + babel + a few hundred npm dependencies).

nuerow 5y ago
> In my mind, server-side rendering means: no more JavaScript framework to maintain Not necessarily. All the major JavaScript frameworks also support server-side rendering, which is used to improve load times and perceived performance.
- satyrnein 5y ago
  I think the suggestion here is for the likes of Django or Rails, not next.js

renke1 5y ago

With server-side rendering you don't have to create yet another layer to actually transfer the data to the client just to render it. It usually also implies that you don't have build your data model in two different languages ($BE_LANG + JS/TS); of course there are things like JSON Schema, OpenAPI and whatnot to mitigate that, but they have their own share of problems. Developing an API may also be a waste of time when your client-side application is the sole consumer of the server API. This is especially true when people try to build an API that does too much (often seen when building REST-style HTTP APIs) instead of a more usecase-based (or even view-centric) API.

nuerow 5y ago
> With server-side rendering you don't have to create yet another layer to actually transfer the data to the client just to render it. That layer doesn't go away with server-side rendering. It is always there, even if you don't use a REST API. It just gets fused with views. In fact, I'd argue that this perception that server-side rendering gets rid of that layer is a telltale sign that the project is already plagued with accidental complexity. > It usually also implies that you don't have build your data model in two different languages ($BE_LANG + JS/TS); Unless the front-end is written in pure HTML+CSS, this hypothetical simplification doesn't materialize. Also, you can't brush off or ignore the complexity added by templating engines. > Developing an API may also be a waste of time when your client-side application is the sole consumer of the server API. I don't get what point you're trying to make. Even if you are the only client for that API, don't you still need to put it together and maintain it?
- arethuza 5y ago
  "Unless the front-end is written in pure HTML+CSS" But that can be "good enough" for many applications - look at how the site we are discussing this on works as an example....
  - nuerow 5y ago
    > But that can be "good enough" for many applications I disagree. If you expect any type of non-trivial user interaction from the front-end, you'll find most of your needs is not practically possible to implement without javascript running on the client-side. > look at how the site we are discussing this on works as an example.... Please note that even HN loads javascript, which also makes AJAX calls to the backend.
    - arethuza 5y ago
      Something like 142 lines of pretty easy to understand JavaScript....
- renke1 5y ago

ec109685 5y ago

Server side rendering also nicely avoids the multiple round trip problem the author mentioned given browsers are inherently request / response so forces one stream of html output. While you can be careful about round trips with client side rendering, and graphql helps in that regard, it’s easy to create hidden bottlenecks.

Zababa 5y ago

> Doesn't this lead to an unnecessary increase in complexity without any immediate benefit? Why do you think using server-side rendering leads to an unnecessary increase in complexity without any immediate benefit? > Doesn't a well developed API mitigate, if not eliminate entirely, needless increases in complexity? It does when multiple clients consume that API. The point of GP is, I think, that you shouldn't start with the assumption that you will have at some point multiple clients and prepare for it.