3 ms·

How about build-time rendering? Server-Side rendering tightly couples your front-end to your application server. Scaling the site means scaling up that applica

How about build-time rendering? Server-Side rendering tightly couples your front-end to your application server. Scaling the site means scaling up that application server. A bug in one "page" of the app can cause the whole application server to go down. If you leverage client-side rendering then it's easier to decouple your front-end from the back meaning you can take advantages of things like segregated micro/serverless services and progressive web apps. You can also re-use those services for multiple applications, making it easier to keep the business logic OUT of your pages and in an API layer where they belong. I agree that SPAs are not the solution for everything, but I think that server-side rendering is on it's way out.

bwilliams 8y ago
> A bug in one "page" of the app can cause the whole application server to go down. That doesn't seem like a valid issue. If a bug in a single page could take the application down then the same could be said for the API powering the front-end. > If you leverage client-side rendering then it's easier to decouple your front-end from the back meaning you can take advantages of things like segregated micro/serverless services and progressive web apps Your PWA point is valid but I don't think the microservices point is. Microservices add a ton of complexity and can easily become overwhelming. If you get to the point where your application can benefit heavily from microservices then congrats, you've made it. > I think that server-side rendering is on it's way out. If anything I think its on its way back in. So many companies bought into the benefits of client side apps and are now seeing the trade-offs that aren't very favorable.
- jamespollack 8y ago
  > That doesn't seem like a valid issue. If a bug in a single page could take the application down then the same could be said for the API powering the front-end. What? The previous poster said coupling frontend / server tightly will result in crash of both if there is a server bug. Your response is that a bug in an unattached API could happen? Of course a bug in your API could crash your API. But at least then it's just your API that's crashed, not the (thousand) servers you're using to serve the front end and every device using them.
  - bwilliams 8y ago
    If your API is down who cares if your app is being served or not? In the majority of cases it won’t work because the API is down.
    - skinnyarms 8y ago
      If my app runs off multiple API, then the bug in my (for example) commenting API shouldn't prevent users from using the shopping cart API to check out.
ec109685 8y ago
You don’t have to use a single server for your business logic and rendering. Separating those two on the backend will ensure you have a clean api that things like mobile apps can hit, while still having a service that renders html for the server-rendered view of your app.
mnm1 8y ago
> A bug in one "page" of the app can cause the whole application server to go down. Maybe if you're using node or some other single threaded server like that but this isn't true for multithreaded or multiprocess servers. It might be an argument against node but it's not an argument against server side rendering. Also, it's irrelevant how pages are rendered or what you're architecture is if a bug brings down the whole server--either way your app doesn't work.

bwilliams 8y ago

> A bug in one "page" of the app can cause the whole application server to go down. That doesn't seem like a valid issue. If a bug in a single page could take the application down then the same could be said for the API powering the front-end. > If you leverage client-side rendering then it's easier to decouple your front-end from the back meaning you can take advantages of things like segregated micro/serverless services and progressive web apps Your PWA point is valid but I don't think the microservices point is. Microservices add a ton of complexity and can easily become overwhelming. If you get to the point where your application can benefit heavily from microservices then congrats, you've made it. > I think that server-side rendering is on it's way out. If anything I think its on its way back in. So many companies bought into the benefits of client side apps and are now seeing the trade-offs that aren't very favorable.

jamespollack 8y ago
> That doesn't seem like a valid issue. If a bug in a single page could take the application down then the same could be said for the API powering the front-end. What? The previous poster said coupling frontend / server tightly will result in crash of both if there is a server bug. Your response is that a bug in an unattached API could happen? Of course a bug in your API could crash your API. But at least then it's just your API that's crashed, not the (thousand) servers you're using to serve the front end and every device using them.
- bwilliams 8y ago
  If your API is down who cares if your app is being served or not? In the majority of cases it won’t work because the API is down.
  - skinnyarms 8y ago
    If my app runs off multiple API, then the bug in my (for example) commenting API shouldn't prevent users from using the shopping cart API to check out.

ec109685 8y ago

You don’t have to use a single server for your business logic and rendering. Separating those two on the backend will ensure you have a clean api that things like mobile apps can hit, while still having a service that renders html for the server-rendered view of your app.

mnm1 8y ago

> A bug in one "page" of the app can cause the whole application server to go down. Maybe if you're using node or some other single threaded server like that but this isn't true for multithreaded or multiprocess servers. It might be an argument against node but it's not an argument against server side rendering. Also, it's irrelevant how pages are rendered or what you're architecture is if a bug brings down the whole server--either way your app doesn't work.