Hacker News Reader

Comment by schwartzworld | Hacker News Reader

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.

View on HN

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

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.

OpenAPI is a JSON API specification system. It doesn't have any hard dependency on the npm ecosystem.

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.

Yeah. That's how huge sprawling multi-language projects typically work. People who are interested in specific stacks maintain the code generation for those stacks. Stacks which are inherently less popular receive less attention in the OpenAPI ecosystem as well. It's very similar with Protobuf, Thrift, etc. There's no magic wand to automatically maintain the codegen for all stacks.

Also not sure how OpenAPI is supposed to support AWS as a target. Do you mean that AWS doesn't support OpenAPI specs for their JSON HTTP services? Pretty sure that's because they use Smithy: https://smithy.io/2.0/index.html

I mean, this doesn't change the complaint? I wasn't even looking in JavaScript at the time. The support in Python was... less than pleasant. Couldn't even do documentation generation well, as most of those plugins for sphinx still relied on the older swagger schema. Close enough to be a pain in the neck.

For supporting AWS, API Gateway has some efforts to support OpenAPI. It is a lot like the documentation problem. Close enough to be a pain in the neck.

So, the question is ultimately what did it help me do? I had a pleasant feeling of following standards for the intro. That is about it. Nothing was disastrous, I don't recall. Just a lot of paper cuts on things not working as hoped by the documentation. I grew to call it aspirational documentation.

You also don't have to choose any of those random NPM libraries, React can stand on its own. Adopting a new technology without any of those libraries just means having to roll your own, but that was always an option.

Do you write software professionally? Not saying this to chide but these types of comments always come from either devs that just work by themselves or green ears.

I have never worked on a project where the only dependency was react (let's ignore build or testing tools for the sake of argument). What I do mostly see are projects that captured the react zeitgeist of the time in regards to which "popular" libraries were recommended and people just copied willy nilly.

Maybe this is more of an indictment against software development in general where professionals are not allowed to design and engineer robust solutions because the alternative is getting fired from your job because John Dev was able to complete more tickets in a sprint when they downloaded a bunch of bloated npm libs that will break in two years and they'll job hop to the next place to continue the cycle.

Believe it or not even large teams can effectively constrain package adoption without abandoning NPM altogether.

Just because you haven't seen it doesn't mean everyone who has must be new to the field.

I'm not saying I haven't seen it, but I would bet my lifesavings the overall percentage is quite small. Why is bringing up the minority use case helpful in these discussions? Some teams just use javascript and opt for zero dependencies too, these teams are also an extreme minority.

You can't have an earnest discussion about react if you're going to argue that no one pulls in a myriad of other dependencies. Even the react docs recommend you use frameworks when starting out:

https://react.dev/learn/start-a-new-react-project

Your usage, while quite admirable (I earnestly mean that too, I wish I was on a team that was disciplined enough to only use react and nothing else), isn't the common experience.

> Why is bringing up the minority use case helpful in these discussions?

It was presented as a challenge to the status quo. As you point out, a majority of developers don't ever think twice about including everything and the kitchen sink. The idea that you don't have to do that may not be novel information to you, but is to a large number of developers. If they don't hear it here, where are they going to hear it?

That's true but that's not how I read their argument.

How else could it be read?

I hope "react forces you into the npm mentality hard on choosing random libraries..." isn't true. I'm just getting into a side-project using Vue and Vuetify components but not planning on using much else than commercial third-parties (which admittedly have free plans that I'm currently using).

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.

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.

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.

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?

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?

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.

I've been using react-router for almost a decade without any issue. I deploy the apps as static websites on S3.

That's not a React thing, but a React Router thing.

Reply on news.ycombinator.com