6 ms·

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 tha

by 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
  > 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. When I wrote my comment I was actually thinking the same, so I agree with you here. However, I still think the (view) model is way closer to your business model without having to go through JSON (or similar) and without the hassle to ensure the client actually received what it expects. I'd argue it's way easier to change or debug in the general case. > 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. It depends on the application, but of course you will have a few highly interactive parts that needs JS/TS (although technologies like alpine.js/html can help here), but still not all models need to exists in the client. > 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? Yes, I mean "elaborate" APIs, my point being that an API for a single consumer can be entirely focused on that consumer. I've seen a lot of people building very flexible APIs without the flexibility being needed at all. I'd argue that one is not tempted to do that as much when doing server-side rending.
vbezhenar 5y ago
Your typical server rendering looks like: Controller queries DB, builds a Model then passes that Model to a View. View uses that Model to render HTML which returned to the client. With dedicated frontend it turns into: Controller queries DB, builds an API response. Frontend receives API response and renders it into HTML. So basically Model is API. Issue with SSR is that it's not popular nowadays and most frameworks are stagnating. At this point it's better to stick to separate backend/frontend unless you don't want to touch it. You don't have to build JSON Schema, OpenAPI and whatnot. Just spew some JSON and consume it with JavaScript.
- renke1 5y ago
  > Issue with SSR is that it's not popular nowadays and most frameworks are stagnating. At this point it's better to stick to separate backend/frontend unless you don't want to touch it. It certainly stagnated a bit in the past, but Rails is still alive and so are newcomers like Phoenix (especially LiveView) or even some new PHP stuff. Also, a lot of talent is wasted when the old backend guys are barred from doing frontend work. They can be crazy efficient with classical server-side approaches. > You don't have to build JSON Schema, OpenAPI and whatnot. Just spew some JSON and consume it with JavaScript. This highly depends on the team structure. In projects where a team (or even single developer) works on both the frontend and backend at the same, it may be fine. However, when there is a dedicated frontend and backend team (in my current project we have a dedicated Android team), it makes sense to have some kind of schema (even when not using codegen). Otherwise you will have a lot of communication overhead.
andrekandre 5y ago
> Developing an API may also be a waste of time when your client-side application is the sole consumer of the server API i think this is assuming you'd never need a native (ios, android) client no?
- renke1 5y ago
  Yes, true, for a lot of our enterprisey customers a simple HTML view (or PWA for that matter; as in visible a web page that appears as app) often suffices (although that's sometimes hard to sell, because there may be potential future requirements that need native capabilities). iOS users probably expect native applications though.
guru4consulting 5y ago
Good developers are often average designers. And the UI changes are often isolated independent from backend changes. To me, a clean API layer with a static SPA style frontend makes it much easier to iterate both UI and backend changes in parallel, without risk of one impacting the other. Development, testing and deployments can be separate and be independent of each other. That decoupling enables faster iterations. Sometimes, SSR seems to take us back to the days of JSP/ASP where view generation is tightly coupled with control/backend layer.
- Raidion 5y ago
  You're both right. The tradeoff you have to make: is the opportunity cost really worth it? If you're a big company and are greenfielding a new design, you either need a huge amount of buyin (eg we're going to go heads down for 8 months and come up with a solution) OR you need to build something that provides incrimental improvements along the way. It's really hard for a new greenfield system to compete on features with one with 5 years of features on it. If you don't have any users, it's far more valuable to demonstrate the business value as early as possible and then build a more scalable solution that's easier for a large team to manage once you've gotten a good chunk of funding.

by renke1 5y ago

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
> 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. When I wrote my comment I was actually thinking the same, so I agree with you here. However, I still think the (view) model is way closer to your business model without having to go through JSON (or similar) and without the hassle to ensure the client actually received what it expects. I'd argue it's way easier to change or debug in the general case. > 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. It depends on the application, but of course you will have a few highly interactive parts that needs JS/TS (although technologies like alpine.js/html can help here), but still not all models need to exists in the client. > 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? Yes, I mean "elaborate" APIs, my point being that an API for a single consumer can be entirely focused on that consumer. I've seen a lot of people building very flexible APIs without the flexibility being needed at all. I'd argue that one is not tempted to do that as much when doing server-side rending.

vbezhenar 5y ago

Your typical server rendering looks like: Controller queries DB, builds a Model then passes that Model to a View. View uses that Model to render HTML which returned to the client. With dedicated frontend it turns into: Controller queries DB, builds an API response. Frontend receives API response and renders it into HTML. So basically Model is API. Issue with SSR is that it's not popular nowadays and most frameworks are stagnating. At this point it's better to stick to separate backend/frontend unless you don't want to touch it. You don't have to build JSON Schema, OpenAPI and whatnot. Just spew some JSON and consume it with JavaScript.

renke1 5y ago
> Issue with SSR is that it's not popular nowadays and most frameworks are stagnating. At this point it's better to stick to separate backend/frontend unless you don't want to touch it. It certainly stagnated a bit in the past, but Rails is still alive and so are newcomers like Phoenix (especially LiveView) or even some new PHP stuff. Also, a lot of talent is wasted when the old backend guys are barred from doing frontend work. They can be crazy efficient with classical server-side approaches. > You don't have to build JSON Schema, OpenAPI and whatnot. Just spew some JSON and consume it with JavaScript. This highly depends on the team structure. In projects where a team (or even single developer) works on both the frontend and backend at the same, it may be fine. However, when there is a dedicated frontend and backend team (in my current project we have a dedicated Android team), it makes sense to have some kind of schema (even when not using codegen). Otherwise you will have a lot of communication overhead.

andrekandre 5y ago

> Developing an API may also be a waste of time when your client-side application is the sole consumer of the server API i think this is assuming you'd never need a native (ios, android) client no?

renke1 5y ago
Yes, true, for a lot of our enterprisey customers a simple HTML view (or PWA for that matter; as in visible a web page that appears as app) often suffices (although that's sometimes hard to sell, because there may be potential future requirements that need native capabilities). iOS users probably expect native applications though.

guru4consulting 5y ago

Good developers are often average designers. And the UI changes are often isolated independent from backend changes. To me, a clean API layer with a static SPA style frontend makes it much easier to iterate both UI and backend changes in parallel, without risk of one impacting the other. Development, testing and deployments can be separate and be independent of each other. That decoupling enables faster iterations. Sometimes, SSR seems to take us back to the days of JSP/ASP where view generation is tightly coupled with control/backend layer.

Raidion 5y ago
You're both right. The tradeoff you have to make: is the opportunity cost really worth it? If you're a big company and are greenfielding a new design, you either need a huge amount of buyin (eg we're going to go heads down for 8 months and come up with a solution) OR you need to build something that provides incrimental improvements along the way. It's really hard for a new greenfield system to compete on features with one with 5 years of features on it. If you don't have any users, it's far more valuable to demonstrate the business value as early as possible and then build a more scalable solution that's easier for a large team to manage once you've gotten a good chunk of funding.