4 ms·

Unfortunately this is true, as I grew more experienced I’m very careful with the dependencies I add to a project. I don’t work with React Native but I hear horr

by balder1991 3y ago

Unfortunately this is true, as I grew more experienced I’m very careful with the dependencies I add to a project. I don’t work with React Native but I hear horror stories of how the hundreds of dependencies force you to either stick to the old versions of stuff or keep fixing or rewriting things that used to work. Seems totally unsuitable for a side project you want minimal maintenance over time.

Our_Benefactors 3y ago
Create react app, with all node_modules included, is well over 200MB of garbage OSS libraries. That’s insane for a hello world.
- graftak 3y ago
  That’s like saying a pencil weighs 1000kg because the machine that makes them does.
  - c_crank 3y ago
    It would be more like a machine weighing 1000kg that makes a wooden stick. Us yeomen expect that you can just pick those off the ground.
- golergka 3y ago
  If “hello world” is the whole requirement behind an app, and you won't develop it further, you don't heed to use react. In fact, here's your whole app: “hello, world!”. Copy it, save it in .txt file, serve in static anywhere you want.
  - zelphirkalt 3y ago
    I wish more people would actually follow this advice. When they don't need anything "reactive" they would not use React. When they don't actually need an SPA, they would not use React. When they don't actually need dynamic behavior on a website, they would not use React or JS. But unfortunately people use what they don't need all the time, rather following hype than reason.
    - golergka 3y ago
      Or, may be, they use the tool they're familiar with, because what they need is to be productive immediately instead of wasting their time to learn different tooling. Even if this different tooling is simpler that what your already know.
      - kristopolous 3y ago
        Right but the earlier you catch your mistake the more time you'll save in total. Generally people use 10x on cost at every subsequent step. Andy Grove famously talked about how this made the FDIV pentium bug cost Intel untold millions instead of pennies. He said when the mistakes and decisions seemed free early on, that's actually when they were the most expensive. As more commitments were made towards the design, it became costlier to back out. Then they discovered it after production and shipping, and by then it became so costly and famous people still remember it 30 years later. To be more direct, if someone doesn't know how to do it right they Shouldn't Be Doing It. If someone can't fly a plane, they shouldn't be flying planes. If someone can't operate a construction crane, they shouldn't be operating one. Same thing here. If they're doing it wrong because that's all they know, they are unqualified. They should not be given the responsibilities. So that method of doing what you're familiar with is the cost of incompetency. Planes and cars crash under incompetent hands and software doesn't fare much better.
        golergka 3y ago
        I'm a little bit confused. At first, we were talking about people using React for Hello World or similarly small and simple project, but here you're talking about making architecture decisions for huge projects?... In context of a simple project: yes, React is not the best tool for the job if you look at project requirements. But also consider the fact that the bundle size and optimization might not be that important from business perspective, and project scope is very limited from time perspective. That's why using React might be the best choice: you're optimising for developer productivity on the short run. However, the situation you are describing now is different. Not only project's business priorities are different, but also the scope is much larger. Which means that spending time on choosing tools and learning a new tool would tale a much smaller % of project's timeline, and thus it makes sense to spend a lot of time on that to potentially save a lot of time and improve other characteristics later on. In other words, you don't do pre-production on hello world, but you do on something huge.
deleted 3y ago
[deleted]

Our_Benefactors 3y ago

Create react app, with all node_modules included, is well over 200MB of garbage OSS libraries. That’s insane for a hello world.

graftak 3y ago
That’s like saying a pencil weighs 1000kg because the machine that makes them does.
- c_crank 3y ago
  It would be more like a machine weighing 1000kg that makes a wooden stick. Us yeomen expect that you can just pick those off the ground.
golergka 3y ago
If “hello world” is the whole requirement behind an app, and you won't develop it further, you don't heed to use react. In fact, here's your whole app: “hello, world!”. Copy it, save it in .txt file, serve in static anywhere you want.
- zelphirkalt 3y ago
  I wish more people would actually follow this advice. When they don't need anything "reactive" they would not use React. When they don't actually need an SPA, they would not use React. When they don't actually need dynamic behavior on a website, they would not use React or JS. But unfortunately people use what they don't need all the time, rather following hype than reason.
  - golergka 3y ago
    Or, may be, they use the tool they're familiar with, because what they need is to be productive immediately instead of wasting their time to learn different tooling. Even if this different tooling is simpler that what your already know.
    - kristopolous 3y ago
      Right but the earlier you catch your mistake the more time you'll save in total. Generally people use 10x on cost at every subsequent step. Andy Grove famously talked about how this made the FDIV pentium bug cost Intel untold millions instead of pennies. He said when the mistakes and decisions seemed free early on, that's actually when they were the most expensive. As more commitments were made towards the design, it became costlier to back out. Then they discovered it after production and shipping, and by then it became so costly and famous people still remember it 30 years later. To be more direct, if someone doesn't know how to do it right they Shouldn't Be Doing It. If someone can't fly a plane, they shouldn't be flying planes. If someone can't operate a construction crane, they shouldn't be operating one. Same thing here. If they're doing it wrong because that's all they know, they are unqualified. They should not be given the responsibilities. So that method of doing what you're familiar with is the cost of incompetency. Planes and cars crash under incompetent hands and software doesn't fare much better.
      - golergka 3y ago
        I'm a little bit confused. At first, we were talking about people using React for Hello World or similarly small and simple project, but here you're talking about making architecture decisions for huge projects?... In context of a simple project: yes, React is not the best tool for the job if you look at project requirements. But also consider the fact that the bundle size and optimization might not be that important from business perspective, and project scope is very limited from time perspective. That's why using React might be the best choice: you're optimising for developer productivity on the short run. However, the situation you are describing now is different. Not only project's business priorities are different, but also the scope is much larger. Which means that spending time on choosing tools and learning a new tool would tale a much smaller % of project's timeline, and thus it makes sense to spend a lot of time on that to potentially save a lot of time and improve other characteristics later on. In other words, you don't do pre-production on hello world, but you do on something huge.

deleted 3y ago

[deleted]