5 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. That layer doesn't go aw

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

by nuerow 5y ago

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.