3 ms·

Large companies typically have dedicated frontend teams with designers to build a user experience that feels cohesive across their products, so managing differe

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.
  - elktown 2y ago
    Not sure how the entire npm/react/SPA ecosystem can be described as stable when it's so many moving parts that it's almost a running joke. Latest I've seen is going full circle into the server-side again and some kind of a compiler? > I could say the same about my experience with UI frameworks. It's not a scary problem, it's not particularly time-consuming SPA UI frameworks are not particularly time-consuming? Then we have very different views on productivity. Being "proactive" is not rational if you're paying a higher price each day in additional complexity to possibly, maybe, avoid having to small cost later. When and if you get there you've already paid 100x the cost compared to just taking the one-time cost when it actually arrived.
    - tail_exchange 2y ago
      Because reality is often different from the running joke, the latter usually being an exaggeration for comedic purposes. If you constantly chase the latest and greatest frameworks, then yes, you’ll find yourself frequently rewriting your application over and over again. This applies to any technology, and it's especially common when less experienced engineers focus on the technology instead of the goal. Take PHP, for example - despite the jokes about it being obsolete and a horrible language, many developers find it effective when used correctly. I would agree with them. There are perfectly valid use cases where PHP is an excellent choice. Being "proactive" is not rational if you're paying a higher price each day in additional complexity to possibly, maybe, avoid having to small cost later. When and if you get there you've already paid 100x the cost compared to just taking the one-time cost when it actually arrived. Sure, but we are not paying a higher price in the name of proactivity, instead we are getting it as a bonus. As I said before, the maintenance cost has been negligible for us. Implementing and maintaining a React stack has not introduced significant overhead, the developers like it, the users like it, and we are happy with it.

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.
- elktown 2y ago
  Not sure how the entire npm/react/SPA ecosystem can be described as stable when it's so many moving parts that it's almost a running joke. Latest I've seen is going full circle into the server-side again and some kind of a compiler? > I could say the same about my experience with UI frameworks. It's not a scary problem, it's not particularly time-consuming SPA UI frameworks are not particularly time-consuming? Then we have very different views on productivity. Being "proactive" is not rational if you're paying a higher price each day in additional complexity to possibly, maybe, avoid having to small cost later. When and if you get there you've already paid 100x the cost compared to just taking the one-time cost when it actually arrived.
  - tail_exchange 2y ago
    Because reality is often different from the running joke, the latter usually being an exaggeration for comedic purposes. If you constantly chase the latest and greatest frameworks, then yes, you’ll find yourself frequently rewriting your application over and over again. This applies to any technology, and it's especially common when less experienced engineers focus on the technology instead of the goal. Take PHP, for example - despite the jokes about it being obsolete and a horrible language, many developers find it effective when used correctly. I would agree with them. There are perfectly valid use cases where PHP is an excellent choice. Being "proactive" is not rational if you're paying a higher price each day in additional complexity to possibly, maybe, avoid having to small cost later. When and if you get there you've already paid 100x the cost compared to just taking the one-time cost when it actually arrived. Sure, but we are not paying a higher price in the name of proactivity, instead we are getting it as a bonus. As I said before, the maintenance cost has been negligible for us. Implementing and maintaining a React stack has not introduced significant overhead, the developers like it, the users like it, and we are happy with it.