8 ms·

I don't get it. I assume the author is trying to make it sound absurd that you would need all these layers of factories to build a simple spice rack and, by ana

I don't get it. I assume the author is trying to make it sound absurd that you would need all these layers of factories to build a simple spice rack and, by analogy, that frameworks are also absurd. But if you were building spice racks at scale, of course you would build them in a factory! And you'd use machinery made in other factories. And those factories would have tools and machines made in yet other factories. That's why you can go to Amazon or Wayfair or the Container Store and find 100 different spice racks for less than $30, and why nobody builds a spice rack by hand, except for fun.

kristopolous 3y ago
That's a mistake. Imagine you're instead a carpenter. You're being called up because the problem is specialized. Now as a carpenter, you go to the container store and then go back to your shop to dismantle prebuilt products and glue a bunch of different pieces from different containers together and present the Frankenstein cabinet as the product back to the customer. Also, you're on the hook for maintaining it. Is it faster then just doing it yourself? Higher quality? Cheaper? Maybe... Competency is the key skill here - someone could claim they're competent in both the NIH and framework way and they choose frameworks because of their vast power of assessments but statistically speaking, they're probably just choosing the frameworks because they lack the competency to DIY and are Dunning Krugering themselves. A lot of this depends on the types of jobs you decide to take on. The boring ones are pretty easy to do with frameworks but the interesting ones are wildly unclear whether you're saving or wasting time by choosing one path over another especially if you're interested in the product's reliability and longevity. The amalgamation of frameworks approach makes long term upgrading somewhere between very expensive and impossible. Dependencies, schemas, templating, test syntax can all change in totally incompatible ways as your version gets abandoned and you get locked in to whatever was hot 10 years ago. So much for security patches. Eventually you'll end up forking the dependencies you once used to save you time and then patch them yourself - code ages way quicker with (most) frameworks.
- 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.
Ultimatt 3y ago
The point that flew over your head is every one wants one spice rack. There is no scale, no one wants a 1km long spice rack or 10,000 small ones either. That you can just buy a ready made one is even more to the authors point. Most software shouldnt exist! Why even build a spice rack, indeed!
capableweb 3y ago
By that very analogy, using frameworks for building a service is absurd. A framework you would use in order to pump out a ton of services quickly, just like a factory in this case. They'd be similar, with similar functionality and such, but you can produce them quickly and upgrade things across all of them fast. They wouldn't by optimal, but time from development to launch would be quicker. But most startups and companies start with one web service, where at that point you don't really need a framework. What you need instead is careful deliberation and implementation, together with development speed and also enough proper architecture to continue to facilitate development speed in the future, but not too much as to over-engineer things. A balance if you will. But unless your business/startup is about pumping out 100s of websites, a framework will hardly help you achieve your goal faster.
austin-cheney 3y ago
Is the author trying to build themselves a spice rack or many spice racks for all the world? In one of those cases, yes, you would want a factory, but that isn't this case. The same is true for code. Are you writing one application or are you writing the same application for many different customers? In one of those cases you would benefit from some sort of template but in the other case it all the extra stuff to scale just gets in the way. If you want your one self-serving spice rack to scale then just plan ahead and make it bigger than your current needs so that you can add more spice later. Again, that also applies to code. If you want your one application to scale then just plan ahead. Jumping immediately into a framework only indicates you lack the confidence to make appropriate planning decisions.
JohnFen 3y ago
Like factories, frameworks are methods of reducing production costs, but come at the expense of certain aspects of product quality. Sometimes, that quality/cost tradeoff is desirable, sometimes it's not. The trouble comes if using a factory or framework is the only, or even main, tool in your toolbox, and it ends up getting used for everything.
- andix 3y ago
  > the main tool in your toolbox, and it ends up getting used for everything. I you get the work done efficiently this may be a good strategy. It may be a worse strategy, to spend a lot of time to find the "perfect" framework and a lot of time to master it, just because it's a better fit for the problem. "Good enough" very often does the trick.
  - JohnFen 3y ago
    > "Good enough" very often does the trick. Absolutely. From an engineering standpoint, "good enough" is often the right thing. An essential thing engineers do, after all, is to select appropriate compromises.
- yibg 3y ago
  I'm not sure the expense of reduced quality is even an issue. Just like an (decent quality) spice rack I buy from a store is probably better quality than spice rakes built by most people, an app built on a (decent quality) framework is probably better quality than apps hand built by most people.
reillyse 3y ago
Yea it’s nonsense. Factories are fantastic. If you want to do something as a hobby, sure don’t use the most advanced tools and do it by hand, but for everyone else especially professionals who are charging other people for their time and effort using the best possible tooling is essential. In fact, if somebody didn’t use a common library or framework and instead “rolled their own” it’s downright irresponsible, obnoxiously egotistical and just creates a huge maintenance burden for whoever has to maintain it when you move on. Take for example a crud app in ruby. If instead of using rails or another framework you instead “rolled your own” for one it would take you way longer for two it would never be as battle tested as the framework and lastly you are guaranteeing that whoever has to maintain it will need to learn the idiosyncrasies of your amazing implementation with zero outside help. It’s a recipe for disaster.
- jiggawatts 3y ago
  I use the same argument for IDEs versus fancy text editors like EMACS. Sure, you might prefer the specific keyboard shortcuts, but IDEs objectively make developers more productive through features like source code integration, debuggers, and refactoring capabilities. Use whatever you like on your home projects, but at work you should be using whatever is most efficient.
  - mattacular 3y ago
    > Use whatever you like on your home projects, but at work you should be using whatever is most efficient. Where's the incentive to do the latter?
  - kneebonian 3y ago
    > fancy text editors like EMACS. Them fighting words my friend.
    - jiggawatts 3y ago
      I knew mentioning EMACS would get the HN crowd riled up, that's the point. :) For laughs: Interview with an Emacs Enthusiast in 2023: https://www.youtube.com/watch?v=urcL86UpqZc https://www.youtube.com/watch?v=urcL86UpqZc And to keep things fair and balanced, an Interview with a VIM Enthusiast: https://www.youtube.com/watch?v=9n1dtmzqnCU https://www.youtube.com/watch?v=9n1dtmzqnCU "I actually wrote a vim versus IDE comparison. Do you know how much faster vim was? 4.3 seconds! 4.3 seconds I saved every day! All those months learning were totally worth it."
square_usual 3y ago
Exactly. This post falls apart because it's predicated on the company not selling hammers anymore. That's not true about software: you have plenty of choices if you don't want to use a framework. People are happily string together libraries to make web servers in almost every language I know of, including the heavyweights like Java and C#.
_hcuq 3y ago
The thing is you aren't building spice racks at scale. Every program is handcrafted.
- tripdout 3y ago
  But your program needs to build spice racks.
hattmall 3y ago
I think you might actually be surprised at the level of non-sophistication of most of these factories. Especially for the "made in China" items, but even in the US. My friend works at Masterbrand, a HUGE houseware manufacturer and it is essentially a massive workshop of people using the most basic tools within reason for the job. This is specifically by design because they found that the more advanced tools required more advanced workers and upkeep that ultimately made them more vulnerable to labor and tooling disruptions. Now 99% of the jobs are setup where anyone can step in with very minimal training.
- Roark66 3y ago
  Indeed, but they don't just do basic items. They make huge industrial products the same way. See this video for example where they melt down steel scrap in arc furnaces covering their faces with just cloth and pour those huge steel gears.... https://youtu.be/2lrGQbMEHaQ https://youtu.be/2lrGQbMEHaQ
jameshart 3y ago
And the spice rack itself is just a container for preprepared ingredients from spice factories, to enable a cook to easily access them. The end product here is the food, after all. When you go to cook a meal you’re oblivious to the framework of abstractions that go to make it possible for you to obtain and store and conveniently dispense your spices - as well you should be.
DannyBee 3y ago
Spice racks are assembled by hand in factories. The pieces are mass produced, the assembly is done by humans. Because unlike software they are not insane. There is no at scale for 99% of companies. The break even point for a factory building spice racks buying machines instead of humans is an immense volume of spice racks - like 100+ spice racks an hour type thing. Maybe more. Just like software, the number of companies that need to produce spice racks at this volume is miniscule. Unlike software, the ones dumb enough to buy machines they don't need go bankrupt very quickly.

kristopolous 3y ago

That's a mistake. Imagine you're instead a carpenter. You're being called up because the problem is specialized. Now as a carpenter, you go to the container store and then go back to your shop to dismantle prebuilt products and glue a bunch of different pieces from different containers together and present the Frankenstein cabinet as the product back to the customer. Also, you're on the hook for maintaining it. Is it faster then just doing it yourself? Higher quality? Cheaper? Maybe... Competency is the key skill here - someone could claim they're competent in both the NIH and framework way and they choose frameworks because of their vast power of assessments but statistically speaking, they're probably just choosing the frameworks because they lack the competency to DIY and are Dunning Krugering themselves. A lot of this depends on the types of jobs you decide to take on. The boring ones are pretty easy to do with frameworks but the interesting ones are wildly unclear whether you're saving or wasting time by choosing one path over another especially if you're interested in the product's reliability and longevity. The amalgamation of frameworks approach makes long term upgrading somewhere between very expensive and impossible. Dependencies, schemas, templating, test syntax can all change in totally incompatible ways as your version gets abandoned and you get locked in to whatever was hot 10 years ago. So much for security patches. Eventually you'll end up forking the dependencies you once used to save you time and then patch them yourself - code ages way quicker with (most) frameworks.

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.

Ultimatt 3y ago

The point that flew over your head is every one wants one spice rack. There is no scale, no one wants a 1km long spice rack or 10,000 small ones either. That you can just buy a ready made one is even more to the authors point. Most software shouldnt exist! Why even build a spice rack, indeed!

capableweb 3y ago

By that very analogy, using frameworks for building a service is absurd. A framework you would use in order to pump out a ton of services quickly, just like a factory in this case. They'd be similar, with similar functionality and such, but you can produce them quickly and upgrade things across all of them fast. They wouldn't by optimal, but time from development to launch would be quicker. But most startups and companies start with one web service, where at that point you don't really need a framework. What you need instead is careful deliberation and implementation, together with development speed and also enough proper architecture to continue to facilitate development speed in the future, but not too much as to over-engineer things. A balance if you will. But unless your business/startup is about pumping out 100s of websites, a framework will hardly help you achieve your goal faster.

austin-cheney 3y ago

Is the author trying to build themselves a spice rack or many spice racks for all the world? In one of those cases, yes, you would want a factory, but that isn't this case. The same is true for code. Are you writing one application or are you writing the same application for many different customers? In one of those cases you would benefit from some sort of template but in the other case it all the extra stuff to scale just gets in the way. If you want your one self-serving spice rack to scale then just plan ahead and make it bigger than your current needs so that you can add more spice later. Again, that also applies to code. If you want your one application to scale then just plan ahead. Jumping immediately into a framework only indicates you lack the confidence to make appropriate planning decisions.

JohnFen 3y ago

Like factories, frameworks are methods of reducing production costs, but come at the expense of certain aspects of product quality. Sometimes, that quality/cost tradeoff is desirable, sometimes it's not. The trouble comes if using a factory or framework is the only, or even main, tool in your toolbox, and it ends up getting used for everything.

andix 3y ago
> the main tool in your toolbox, and it ends up getting used for everything. I you get the work done efficiently this may be a good strategy. It may be a worse strategy, to spend a lot of time to find the "perfect" framework and a lot of time to master it, just because it's a better fit for the problem. "Good enough" very often does the trick.
- JohnFen 3y ago
  > "Good enough" very often does the trick. Absolutely. From an engineering standpoint, "good enough" is often the right thing. An essential thing engineers do, after all, is to select appropriate compromises.
yibg 3y ago
I'm not sure the expense of reduced quality is even an issue. Just like an (decent quality) spice rack I buy from a store is probably better quality than spice rakes built by most people, an app built on a (decent quality) framework is probably better quality than apps hand built by most people.

reillyse 3y ago

Yea it’s nonsense. Factories are fantastic. If you want to do something as a hobby, sure don’t use the most advanced tools and do it by hand, but for everyone else especially professionals who are charging other people for their time and effort using the best possible tooling is essential. In fact, if somebody didn’t use a common library or framework and instead “rolled their own” it’s downright irresponsible, obnoxiously egotistical and just creates a huge maintenance burden for whoever has to maintain it when you move on. Take for example a crud app in ruby. If instead of using rails or another framework you instead “rolled your own” for one it would take you way longer for two it would never be as battle tested as the framework and lastly you are guaranteeing that whoever has to maintain it will need to learn the idiosyncrasies of your amazing implementation with zero outside help. It’s a recipe for disaster.

jiggawatts 3y ago
I use the same argument for IDEs versus fancy text editors like EMACS. Sure, you might prefer the specific keyboard shortcuts, but IDEs objectively make developers more productive through features like source code integration, debuggers, and refactoring capabilities. Use whatever you like on your home projects, but at work you should be using whatever is most efficient.
- mattacular 3y ago
  > Use whatever you like on your home projects, but at work you should be using whatever is most efficient. Where's the incentive to do the latter?
- kneebonian 3y ago
  > fancy text editors like EMACS. Them fighting words my friend.
  - jiggawatts 3y ago
    I knew mentioning EMACS would get the HN crowd riled up, that's the point. :) For laughs: Interview with an Emacs Enthusiast in 2023: https://www.youtube.com/watch?v=urcL86UpqZc https://www.youtube.com/watch?v=urcL86UpqZc And to keep things fair and balanced, an Interview with a VIM Enthusiast: https://www.youtube.com/watch?v=9n1dtmzqnCU https://www.youtube.com/watch?v=9n1dtmzqnCU "I actually wrote a vim versus IDE comparison. Do you know how much faster vim was? 4.3 seconds! 4.3 seconds I saved every day! All those months learning were totally worth it."

square_usual 3y ago

Exactly. This post falls apart because it's predicated on the company not selling hammers anymore. That's not true about software: you have plenty of choices if you don't want to use a framework. People are happily string together libraries to make web servers in almost every language I know of, including the heavyweights like Java and C#.

_hcuq 3y ago

The thing is you aren't building spice racks at scale. Every program is handcrafted.

tripdout 3y ago
But your program needs to build spice racks.

hattmall 3y ago

I think you might actually be surprised at the level of non-sophistication of most of these factories. Especially for the "made in China" items, but even in the US. My friend works at Masterbrand, a HUGE houseware manufacturer and it is essentially a massive workshop of people using the most basic tools within reason for the job. This is specifically by design because they found that the more advanced tools required more advanced workers and upkeep that ultimately made them more vulnerable to labor and tooling disruptions. Now 99% of the jobs are setup where anyone can step in with very minimal training.

Roark66 3y ago
Indeed, but they don't just do basic items. They make huge industrial products the same way. See this video for example where they melt down steel scrap in arc furnaces covering their faces with just cloth and pour those huge steel gears.... https://youtu.be/2lrGQbMEHaQ https://youtu.be/2lrGQbMEHaQ

jameshart 3y ago

And the spice rack itself is just a container for preprepared ingredients from spice factories, to enable a cook to easily access them. The end product here is the food, after all. When you go to cook a meal you’re oblivious to the framework of abstractions that go to make it possible for you to obtain and store and conveniently dispense your spices - as well you should be.

DannyBee 3y ago

Spice racks are assembled by hand in factories. The pieces are mass produced, the assembly is done by humans. Because unlike software they are not insane. There is no at scale for 99% of companies. The break even point for a factory building spice racks buying machines instead of humans is an immense volume of spice racks - like 100+ spice racks an hour type thing. Maybe more. Just like software, the number of companies that need to produce spice racks at this volume is miniscule. Unlike software, the ones dumb enough to buy machines they don't need go bankrupt very quickly.