4 ms·

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 i

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.
    - yawaramin 2y ago
      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 https://smithy.io/2.0/index.html
      - taeric 2y ago
        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.
causal 2y ago
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.
- azemetre 2y ago
  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.
  - causal 2y ago
    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.
    - azemetre 2y ago
      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 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.
karmakaze 2y ago
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).

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.
  - yawaramin 2y ago
    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 https://smithy.io/2.0/index.html
    - taeric 2y ago
      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.

causal 2y ago

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.

azemetre 2y ago
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.
- causal 2y ago
  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.
  - azemetre 2y ago
    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 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.

karmakaze 2y ago

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).