4 ms·

The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories,

The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point (and the fact that you get an API by default with CSR is also nice). I don't think CSR is going anywhere, mainly thanks to Conway's Law.

spinningslate 3y ago
Big fat "it depends". Specifically, it depends on context. How big is the app? How many people are involved in building it? As with many things, separation of front and back ends grew out of web-scale companies and products. If you're buiding Facebook or Spotify or Gmail, then you need a way to partition your app - because you need to partition your people. Humans need structure, we don't deal well with single teams of multiple hundreds. Many apps don't fit that model. Lots of apps - e.g. business internal apps - might target at most small 100s of users and justify a dev team of < 10. In that world, separation of front end and back end devs & stacks is a disadvantage. Single language, single build apps mean less technical surface for the team to cover. Which means each person can more flexibly turn their hand to the requirements. Most people can do most things end to end. Features are business-driven and end to end. A single PR can deliver a meaningful piece of user-accessible value. There's no unionised demarcation. None of which says "separate UI & back end is universally wrong". But it's not universally right either. As is so often the case, it degenerates into a discussion that is technical and absolute when the underlying forces are organisational and relative.
Transpire7487 3y ago
> The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point. You say this as if it is necessarily good, but I disagree and would even say it's actually a hindrance for many teams. It often adds inefficiences, increases costs and makes planning and collaboration more difficult. > the fact that you get an API by default with CSR is also nice The vast majority of applications don't need an API.
jaequery 3y ago
I think the trend these days is we are now going back to combining backend and frontend again. I'm looking at you Next.js.
Phrodo_00 3y ago
> it creates a clear separation between frontend and backend devs Yes, and if a single team is doing both it adds another stack to master. This can be a pro or con depending on the size/organization of the team.
vbezhenar 3y ago
The same argument could be used for splitting backend to multiple services, or even micro services. Frontend/backend separation seems pretty arbitrary. If anything, I'd say that with server rendering, separating different modules is easier. You want to rewrite that page? No problems. With client-side rendering there's usually expectation of some monolith project using the single framework.
- jwells89 3y ago
  > If anything, I'd say that with server rendering, separating different modules is easier. You want to rewrite that page? No problems. It also gets you vastly more choice in language/tooling/etc, even allowing a mixture of different ones, which is what attracts me to SSR. Of course this may change in the future once WebAssembly has had most of the DOM interop overhead optimized away, bringing this freedom to CSR.
- edanm 3y ago
  Frontend-backend separation isn't arbitrary at all. A few things that are often different between FE and BE: 1. Written in different languages. 2. Completely different deployment paths. 3. Causing completely different ways of scaling. 4. Focus on UI and UX is a very different mindset, with often some people preferring it to be a focus of their work, or not.
  - azmarks 3y ago
    You can (and probably will) have multiple different frontends with website vs app. If you have a clean API for the backend, then you have one set of calls which can be made from multiple different user interfaces
fauigerzigerk 3y ago
Maybe you're right that people find it easier to think that way, but it seems rather illogical to me. The very first step in creating this separation is to define an API that is implemented and operated by backend devs and used by frontend devs. Once you have done that, you have achieved all the clarity that is necessary or possible. Whether or not some parts of the frontend are executed on the server-side shouldn't matter for the question of who has responsibility for what. Perhaps it's more about the ease of hiring for different skillsets. If frontend is synonymous with client-side and backend is synonymous with server-side, it makes life easier for HR and recruiters.
DylanSp 3y ago
There's definitely at least some truth to this. And even when working on both frontend and backend (on a small team), I find it useful to have a clear separation between client-side code and server-side code, with a well-defined boundary between them. This might be shaped by my experience with ASP.NET and .aspx templates, though; I struggled to understand when and how the client-side code would call the backend to send input or get updated data.
rambambram 3y ago
> a clear separation between frontend and backend devs I love the 'CHAMP' stack, which stands for CSS, HTML, Apache, MySQL and PHP. ;) Clear separation between frontend and backend. I'm almost happy that I started webdev in the 90's. This 'ancient' technology is still going strong, with websites and a whole lot of webapps.
- mock-possum 3y ago
  So how do you handle any interactivity that’s not a user click? Like say, mousemove, or keypress?
  - rambambram 3y ago
    First and foremost I tried to have the whole flow of UI and clicks be nothing more than request after request. Compared to modern javascript frameworks it might not be as smooth, but it is super quick and works for my use case. Of course I use a little javascript here and there, but the javascript is not making server calls (except for my visitor statistics module).

spinningslate 3y ago

Big fat "it depends". Specifically, it depends on context. How big is the app? How many people are involved in building it? As with many things, separation of front and back ends grew out of web-scale companies and products. If you're buiding Facebook or Spotify or Gmail, then you need a way to partition your app - because you need to partition your people. Humans need structure, we don't deal well with single teams of multiple hundreds. Many apps don't fit that model. Lots of apps - e.g. business internal apps - might target at most small 100s of users and justify a dev team of < 10. In that world, separation of front end and back end devs & stacks is a disadvantage. Single language, single build apps mean less technical surface for the team to cover. Which means each person can more flexibly turn their hand to the requirements. Most people can do most things end to end. Features are business-driven and end to end. A single PR can deliver a meaningful piece of user-accessible value. There's no unionised demarcation. None of which says "separate UI & back end is universally wrong". But it's not universally right either. As is so often the case, it degenerates into a discussion that is technical and absolute when the underlying forces are organisational and relative.

Transpire7487 3y ago

> The reason client-side rendering is so popular (IME) is that it creates a clear separation between frontend and backend devs. You can use separate repositories, languages, deployment flows/cadences, code review, etc, with an API as your connection point. You say this as if it is necessarily good, but I disagree and would even say it's actually a hindrance for many teams. It often adds inefficiences, increases costs and makes planning and collaboration more difficult. > the fact that you get an API by default with CSR is also nice The vast majority of applications don't need an API.

jaequery 3y ago

I think the trend these days is we are now going back to combining backend and frontend again. I'm looking at you Next.js.

Phrodo_00 3y ago

> it creates a clear separation between frontend and backend devs Yes, and if a single team is doing both it adds another stack to master. This can be a pro or con depending on the size/organization of the team.

vbezhenar 3y ago

The same argument could be used for splitting backend to multiple services, or even micro services. Frontend/backend separation seems pretty arbitrary. If anything, I'd say that with server rendering, separating different modules is easier. You want to rewrite that page? No problems. With client-side rendering there's usually expectation of some monolith project using the single framework.

jwells89 3y ago
> If anything, I'd say that with server rendering, separating different modules is easier. You want to rewrite that page? No problems. It also gets you vastly more choice in language/tooling/etc, even allowing a mixture of different ones, which is what attracts me to SSR. Of course this may change in the future once WebAssembly has had most of the DOM interop overhead optimized away, bringing this freedom to CSR.
edanm 3y ago
Frontend-backend separation isn't arbitrary at all. A few things that are often different between FE and BE: 1. Written in different languages. 2. Completely different deployment paths. 3. Causing completely different ways of scaling. 4. Focus on UI and UX is a very different mindset, with often some people preferring it to be a focus of their work, or not.
- azmarks 3y ago
  You can (and probably will) have multiple different frontends with website vs app. If you have a clean API for the backend, then you have one set of calls which can be made from multiple different user interfaces

fauigerzigerk 3y ago

Maybe you're right that people find it easier to think that way, but it seems rather illogical to me. The very first step in creating this separation is to define an API that is implemented and operated by backend devs and used by frontend devs. Once you have done that, you have achieved all the clarity that is necessary or possible. Whether or not some parts of the frontend are executed on the server-side shouldn't matter for the question of who has responsibility for what. Perhaps it's more about the ease of hiring for different skillsets. If frontend is synonymous with client-side and backend is synonymous with server-side, it makes life easier for HR and recruiters.

DylanSp 3y ago

There's definitely at least some truth to this. And even when working on both frontend and backend (on a small team), I find it useful to have a clear separation between client-side code and server-side code, with a well-defined boundary between them. This might be shaped by my experience with ASP.NET and .aspx templates, though; I struggled to understand when and how the client-side code would call the backend to send input or get updated data.

rambambram 3y ago

> a clear separation between frontend and backend devs I love the 'CHAMP' stack, which stands for CSS, HTML, Apache, MySQL and PHP. ;) Clear separation between frontend and backend. I'm almost happy that I started webdev in the 90's. This 'ancient' technology is still going strong, with websites and a whole lot of webapps.

mock-possum 3y ago
So how do you handle any interactivity that’s not a user click? Like say, mousemove, or keypress?
- rambambram 3y ago
  First and foremost I tried to have the whole flow of UI and clicks be nothing more than request after request. Compared to modern javascript frameworks it might not be as smooth, but it is super quick and works for my use case. Of course I use a little javascript here and there, but the javascript is not making server calls (except for my visitor statistics module).