4 ms·

I also prefer the client-side approach because the separation between server and client makes more sense to me: the backend serves data, the client renders it.

I also prefer the client-side approach because the separation between server and client makes more sense to me: the backend serves data, the client renders it. It is also much easier to manage state. Unless the website is extremely simple, I always go for JS framworks. I never had problems with performance. React is less than 150kb, and as the backend is not a bottleneck, the website feels very snappy. SSR is not enough if you want an interactive page, you'll need some JS. If you do, instead of dealing with a ton of scattered JS scripts, I'd rather have a single React/whatever application.

elktown 2y ago
> the backend serves data, the client renders it SSR does this as well. The server serves data (HTML), the client (web browser) renders it.
- tail_exchange 2y ago
  By data I mean a format for data interchange, like JSON.
  - elktown 2y ago
    So what makes sense to you is adding the additional layer of transforming the JSON data into HTML from an API - all of which are almost always in the end tailor made for the app anyway - using a significant chunk of code within a completely separate and bloated ecosystem and in a different language than what the server uses? A bonus "feature" of this, and a very important one, is that this now also requires different specializations on your team and the personnel costs and communication overhead that comes with that. Great, now adding simple CRUD functionality to a website is a two week project syncing between backenders and frontenders, for something that someone wanting to scratch their own itch could hammer out independently in a single day back in the SSR days.
    - tail_exchange 2y ago
      Large companies typically have dedicated frontend teams with designers to build a user experience that feels cohesive across their products, so managing different specializations and the communication overhead is already part of their workflow. Your argument suggests that SSR requires only one type of specialization, but that's not entirely accurate. SSR developers still need full-stack knowledge, since they must write HTML, CSS, and JavaScript alongside the backend code. This means their expertise already needs to cover multiple areas and languages. While it’s true that frontend frameworks introduce additional build tooling, developers today are generally familiar with this ecosystem. The backend developers I work with do have a good understanding of React and can work with it comfortably, and I have seen junior developers picking it up within a week or two. They don't need to be specialists in order to be productive. Yes, it is true that many backends are tailor-made for a frontend, but going exclusively HTML-first will lock you into this state, unless you are OK with revisiting it to add a JSON API later to support additional use cases. When I write an application, it usually comes with a CLI in case I need to use it from a server without access to a UI, and I hook it up with tools for integration tests using its JSON API. It's also common to see frontends that are powered by multiple backends, and in these cases, it makes sense to have a separate frontend application that uses APIs. So yes, it does make perfect sense for me to have a layer between presentation and application. edit: fixed a typo
      - elktown 2y ago
        > Large companies typically have dedicated frontend teams with designers to build a user experience that feels cohesive across their products, so managing different specializations and the communication overhead is already part of their workflow. What makes you think this is confined to large companies? And even large companies have small teams. > SSR developers still need full-stack knowledge, since they must write HTML, CSS, and JavaScript alongside the backend code It's true, but it's a smaller scope, better & more stable documentation, and overall a smaller threshold to get going to add a form in passing to a SSR than getting going with a new ecosystem. > unless you are OK with revisiting it to add a JSON API later to support additional use cases. Adding another output format to an existing product is not a scary problem and usually not even a time consuming one, and best of all you can wait until it's actually needed. This includes endpoints for a CLI. Now the aren't shared either, so the HTML output can be adapted according to the needs of the website along its lifetime, and the debug endpoints' JSON output can be adapted according to the needs of the CLI along its lifetime.

elktown 2y ago

> the backend serves data, the client renders it SSR does this as well. The server serves data (HTML), the client (web browser) renders it.

tail_exchange 2y ago
By data I mean a format for data interchange, like JSON.
- elktown 2y ago
  So what makes sense to you is adding the additional layer of transforming the JSON data into HTML from an API - all of which are almost always in the end tailor made for the app anyway - using a significant chunk of code within a completely separate and bloated ecosystem and in a different language than what the server uses? A bonus "feature" of this, and a very important one, is that this now also requires different specializations on your team and the personnel costs and communication overhead that comes with that. Great, now adding simple CRUD functionality to a website is a two week project syncing between backenders and frontenders, for something that someone wanting to scratch their own itch could hammer out independently in a single day back in the SSR days.
  - tail_exchange 2y ago
    Large companies typically have dedicated frontend teams with designers to build a user experience that feels cohesive across their products, so managing different specializations and the communication overhead is already part of their workflow. Your argument suggests that SSR requires only one type of specialization, but that's not entirely accurate. SSR developers still need full-stack knowledge, since they must write HTML, CSS, and JavaScript alongside the backend code. This means their expertise already needs to cover multiple areas and languages. While it’s true that frontend frameworks introduce additional build tooling, developers today are generally familiar with this ecosystem. The backend developers I work with do have a good understanding of React and can work with it comfortably, and I have seen junior developers picking it up within a week or two. They don't need to be specialists in order to be productive. Yes, it is true that many backends are tailor-made for a frontend, but going exclusively HTML-first will lock you into this state, unless you are OK with revisiting it to add a JSON API later to support additional use cases. When I write an application, it usually comes with a CLI in case I need to use it from a server without access to a UI, and I hook it up with tools for integration tests using its JSON API. It's also common to see frontends that are powered by multiple backends, and in these cases, it makes sense to have a separate frontend application that uses APIs. So yes, it does make perfect sense for me to have a layer between presentation and application. edit: fixed a typo
    - elktown 2y ago
      > Large companies typically have dedicated frontend teams with designers to build a user experience that feels cohesive across their products, so managing different specializations and the communication overhead is already part of their workflow. What makes you think this is confined to large companies? And even large companies have small teams. > SSR developers still need full-stack knowledge, since they must write HTML, CSS, and JavaScript alongside the backend code It's true, but it's a smaller scope, better & more stable documentation, and overall a smaller threshold to get going to add a form in passing to a SSR than getting going with a new ecosystem. > unless you are OK with revisiting it to add a JSON API later to support additional use cases. Adding another output format to an existing product is not a scary problem and usually not even a time consuming one, and best of all you can wait until it's actually needed. This includes endpoints for a CLI. Now the aren't shared either, so the HTML output can be adapted according to the needs of the website along its lifetime, and the debug endpoints' JSON output can be adapted according to the needs of the CLI along its lifetime.