4 ms·

It’s a little weird to say you’re ditching React, when your issues are not with React but other dependencies you’ve adopted. The choice to write a backend in Go

It’s a little weird to say you’re ditching React, when your issues are not with React but other dependencies you’ve adopted. The choice to write a backend in Go that handles routing was always there.

lordgroff 2y ago
That was kind of my take on this article as well. We're comparing libraries with lots of breaking-API churn vs. libraries that don't do as much, in another language. When it comes to React itself, only breaking changes I ever experienced were 17->18 and that was such a simple fix it's not worth talking about.
kerblang 2y ago
I had the impression that hash routing in React was deprecated and a React-based back end is almost a mandate now... Wondering what options people are actually taking?
- schwartzworld 2y ago
  That's not a React thing, but a React Router thing.
- ggregoire 2y ago
  I've been using react-router for almost a decade without any issue. I deploy the apps as static websites on S3.
- martinsnow 2y ago
  I've never used SSR and i have quite a few react apps under my belt. Why would you need to introduce it as a full stack app?
- sleazebreeze 2y ago
  Not at all mandated. Buying into React server-side rendering will get you into a morass of complexity. Traditional SPAs with history-based routing still work just fine.
christophilus 2y ago
Agreed. I’ve been using Preact on an entirely client-side SPA with a simple RPC-like backend all in typescript for 5 years or so. I can’t think of a single major dependency that has changed significantly in that time. But, I did make an effort to minimize my dependencies.
Tade0 2y ago
The problem isn't specifically with React, but the culture around it based on the fact that it's "just a library". Net effect is that you have many more dependencies than in frameworks which provide some features out of the box and thus much greater risk of having to deal with the problem discussed here.
azemetre 2y ago
That's fair but react forces you into the npm mentality hard on choosing random libraries that are often abandoned, don't have licenses, and a myriad of other issues other people have mentioned. I'm dealing with a massive migration at my job where the schism between libraries going from node-sass to dart-sass caused something as simple as just updating bootstrap versions into a year long effort of having to move a dozen core libraries to their latest versions simultaneously with the result being what? It's not like our product will be significantly faster or gain some new features, all we get is our app not breaking because the deps shit the bed. I think the lessons we can learn from the frontend community is that not having a robust standard library is a failure of javascript and this problem will persist until we stop caring about backwards compatibility. Will we as software engineers continue having discussions about supporting browsers from 1990 in the year 3025? I hope not, because bad decisions were made then and they have been compounded since. edit: clarity
- taeric 2y ago
  I have grown scared to look at OpenAPI and related technologies, for fear that I will find the same problems there. I don't think "not caring about backwards compatibility" is the issue, though? Quite the contrary, constantly forcing migrations because things have changed hurts far more.
  - yawaramin 2y ago
    OpenAPI is a JSON API specification system. It doesn't have any hard dependency on the npm ecosystem.
    - taeric 2y ago
      Fair that it isn't just a JavaScript thing, but have you tried looking at the various options out there supposed to help implement with it? Either as a client or as implementation. Many are abandoned. None seem to support AWS as a target. Really is wsdl all over again.
      - 2y ago

lordgroff 2y ago

That was kind of my take on this article as well. We're comparing libraries with lots of breaking-API churn vs. libraries that don't do as much, in another language. When it comes to React itself, only breaking changes I ever experienced were 17->18 and that was such a simple fix it's not worth talking about.

kerblang 2y ago

I had the impression that hash routing in React was deprecated and a React-based back end is almost a mandate now... Wondering what options people are actually taking?

schwartzworld 2y ago
That's not a React thing, but a React Router thing.
ggregoire 2y ago
I've been using react-router for almost a decade without any issue. I deploy the apps as static websites on S3.
martinsnow 2y ago
I've never used SSR and i have quite a few react apps under my belt. Why would you need to introduce it as a full stack app?
sleazebreeze 2y ago
Not at all mandated. Buying into React server-side rendering will get you into a morass of complexity. Traditional SPAs with history-based routing still work just fine.

christophilus 2y ago

Agreed. I’ve been using Preact on an entirely client-side SPA with a simple RPC-like backend all in typescript for 5 years or so. I can’t think of a single major dependency that has changed significantly in that time. But, I did make an effort to minimize my dependencies.

Tade0 2y ago

The problem isn't specifically with React, but the culture around it based on the fact that it's "just a library". Net effect is that you have many more dependencies than in frameworks which provide some features out of the box and thus much greater risk of having to deal with the problem discussed here.

azemetre 2y ago

That's fair but react forces you into the npm mentality hard on choosing random libraries that are often abandoned, don't have licenses, and a myriad of other issues other people have mentioned. I'm dealing with a massive migration at my job where the schism between libraries going from node-sass to dart-sass caused something as simple as just updating bootstrap versions into a year long effort of having to move a dozen core libraries to their latest versions simultaneously with the result being what? It's not like our product will be significantly faster or gain some new features, all we get is our app not breaking because the deps shit the bed. I think the lessons we can learn from the frontend community is that not having a robust standard library is a failure of javascript and this problem will persist until we stop caring about backwards compatibility. Will we as software engineers continue having discussions about supporting browsers from 1990 in the year 3025? I hope not, because bad decisions were made then and they have been compounded since. edit: clarity

taeric 2y ago
I have grown scared to look at OpenAPI and related technologies, for fear that I will find the same problems there. I don't think "not caring about backwards compatibility" is the issue, though? Quite the contrary, constantly forcing migrations because things have changed hurts far more.
- yawaramin 2y ago
  OpenAPI is a JSON API specification system. It doesn't have any hard dependency on the npm ecosystem.
  - taeric 2y ago
    Fair that it isn't just a JavaScript thing, but have you tried looking at the various options out there supposed to help implement with it? Either as a client or as implementation. Many are abandoned. None seem to support AWS as a target. Really is wsdl all over again.
    - 2y ago