4 ms·

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.
    - tail_exchange 2y ago
      Small companies are addressed indirectly in my second paragraph. Even if you have a small company or a small team, they still need full-stack experience. Documentation for frameworks like React is already very mature, so I don't think it is a problem. The scope might be slightly larger, but getting a React stack going nowadays can be done with a single command, and maintaining it has not been an issue for my team of mostly backend engineers: we are able to manage a few UIs in React for our tools without any problems. I would say the additional complexity introduced by React has been minimal, the team likes it, users like it, and the experience was pleasant enough to win me over. 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. I could say the same about my experience with UI frameworks. It's not a scary problem, it's not particularly time-consuming, and by adopting it, I gain the flexibility to handle new use cases like integrations with other APIs, integrations with other frontends, and CLI tools right from the start. A proactive approach means I don’t need to revisit and rework the application later.

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.
  - tail_exchange 2y ago
    Small companies are addressed indirectly in my second paragraph. Even if you have a small company or a small team, they still need full-stack experience. Documentation for frameworks like React is already very mature, so I don't think it is a problem. The scope might be slightly larger, but getting a React stack going nowadays can be done with a single command, and maintaining it has not been an issue for my team of mostly backend engineers: we are able to manage a few UIs in React for our tools without any problems. I would say the additional complexity introduced by React has been minimal, the team likes it, users like it, and the experience was pleasant enough to win me over. 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. I could say the same about my experience with UI frameworks. It's not a scary problem, it's not particularly time-consuming, and by adopting it, I gain the flexibility to handle new use cases like integrations with other APIs, integrations with other frontends, and CLI tools right from the start. A proactive approach means I don’t need to revisit and rework the application later.