5 ms·

Why?

kakadoodle 3y ago
Maybe start explaining why not, and then ask why someone would? I think it would create a more interesting conversation.
0000000000100 3y ago
Less dependencies makes maintaining the project easier.
- erik_seaberg 3y ago
  Popular libraries have been battle tested in prod, and my teammates probably have prior experience with them.
  - darepublic 3y ago
    There are more than a few popular js libs that are pretty trash IMO. Though I would not count lodash among them. Battle tested can often just mean teams use them for better or worse, and I can often see in the code how bad frameworks cause juniors to contort their solutions in all the wrong ways to make them adhere to a framework instead of untie the knot and do it the right way. Sometimes it is the framework being used incorrectly. The devs should invest time to learn the API better. But often it's better to just learn how to do the solution sans framework rather than add to the stack of bespoke APIs to learn. And junior devs can become dependent on frameworks for every little thing to the point where they will always reach for one even if the choices are poor
- SkyPuncher 3y ago
  How? That’s more internal code with bugs.
  - sebastianz 3y ago
    Some internal code with bugs is way better than lots of external code with other people's bugs.
    - SkyPuncher 3y ago
      Pretty much disagree on every front. Particularly for a major library. There's a very good chance those "other people" have thought about the problem they're trying to solve way more than you have.
      - yakshaving_jgt 3y ago
        You don’t think this learned helplessness is depressing? Whether or not a team decides to own some portion of code is a complex topic. Sometimes it makes sense to leverage something external, and sometimes it makes sense to write it yourself. In my business, we had a [ostensibly senior] guy insist we use an external technology because it would be too hard for us to own that piece ourselves, despite it being a core part of the product. Technical due diligence on the external technology showed that it didn’t actually work as advertised. Six figure price tag and apparently millions invested for a thing that doesn’t work (and “doesn’t work” in this case meant “corrupted financial data”). Whether or not a team owns some technology is highly context dependent, and your comment comes across as reductive.
      - sebastianz 3y ago
        We are discussing lodash here. It's a javascript library with utility functions. The link we are discussing states they have just deleted 400 bugs declaring "bankruptcy". If you, like many people using lodash are using 10 util functions from it to iterate arrays or split strings, I'm sure you're better off just maintaining your own functions. And I say this as a user of prototype.js, another utility library, 18 years old, in a very old project. That lib is dead and unmaintained, and it's going to cost me a long time to remove. So now I've inherited all their bugs and code, and it's mine, just like if you use the old lodash, the "bankruptcy" bugs are now yours.
darepublic 3y ago
Because the surface area of lodash is so large and I need just a small fraction of it. And when I do need it it's easy to make a simple transparent version of the needed until rather than invoke a mystical black box. I admit this is opinionated and I have managed to work with lodash and keep my mouth shut about it
- BoiledCabbage 3y ago
  Thanks for sharing - I disagree with the approach, but understand it. Or rather, I feel that can work for individual coding, or possibly very small teams - but in the end I feel it usually works out to be unintentionally anti-team behavior. It trades off "I need to learn and understand this black box of behavior for instead I have this code that I know and can easily reason about". While for the entire rest of your team it went from "there is this common pattern that most of all 20 (or however many) of us know - and instead makes it 19 of us now need to learn this non-standard behavior/implementation, but at least one person knows well." Essentially everyone else has to learn more code, so that one person doesn't. Agreed it's usually not the most complex of code, but it's usually buggier and shifts to cost / burden to everyone else. The opposite of economies of scale and leveraging prior fixed costs of learning. But again, I don't know your situation and will readily admit my opinion above doesn't in anyway make it factually a better approach. Just my opinion on it same as yours.
  - rcme 3y ago
    It works perfectly fine. You just copy and paste the code you need. If someone else needs it, they search the code base first, which is normal in large code bases. There are tons of different libraries that provide deep equality checks for instance. When I work in a code base, I need to search for existing solutions in the code base before adding someone new. It doesn’t matter if the functionality is provided by a first or third part library.
- xeromal 3y ago
  I'm not sure if you're aware but lodash has individual packages for each of their functions.
mostlylurks 3y ago
Not super relevant for lodash in particular, but another reason for why someone might want to do this is dependency hell. At least with code you write yourself, you know that the author(s) won't keep changing the API (very common in the javascript ecosystem, unfortunately), forcing you to either waste time constantly changing your own code to match the newer APIs, or stick to a single version for a long time, which may become incompatible with newer versions of other dependencies, your build system, your language, your environment, etc, which will become an issue if you have something else that you want to update but that old version of the dependency doesn't support it. So in some cases it might be easier and more maintainable to just write your own version of whatever small feature of the dependency you might otherwise have used, but knowing when this will be the case is a skill of its own.

Why?

Maybe start explaining why not, and then ask why someone would? I think it would create a more interesting conversation.

0000000000100 3y ago

Less dependencies makes maintaining the project easier.

erik_seaberg 3y ago
Popular libraries have been battle tested in prod, and my teammates probably have prior experience with them.
- darepublic 3y ago
  There are more than a few popular js libs that are pretty trash IMO. Though I would not count lodash among them. Battle tested can often just mean teams use them for better or worse, and I can often see in the code how bad frameworks cause juniors to contort their solutions in all the wrong ways to make them adhere to a framework instead of untie the knot and do it the right way. Sometimes it is the framework being used incorrectly. The devs should invest time to learn the API better. But often it's better to just learn how to do the solution sans framework rather than add to the stack of bespoke APIs to learn. And junior devs can become dependent on frameworks for every little thing to the point where they will always reach for one even if the choices are poor
SkyPuncher 3y ago
How? That’s more internal code with bugs.
- sebastianz 3y ago
  Some internal code with bugs is way better than lots of external code with other people's bugs.
  - SkyPuncher 3y ago
    Pretty much disagree on every front. Particularly for a major library. There's a very good chance those "other people" have thought about the problem they're trying to solve way more than you have.
    - yakshaving_jgt 3y ago
      You don’t think this learned helplessness is depressing? Whether or not a team decides to own some portion of code is a complex topic. Sometimes it makes sense to leverage something external, and sometimes it makes sense to write it yourself. In my business, we had a [ostensibly senior] guy insist we use an external technology because it would be too hard for us to own that piece ourselves, despite it being a core part of the product. Technical due diligence on the external technology showed that it didn’t actually work as advertised. Six figure price tag and apparently millions invested for a thing that doesn’t work (and “doesn’t work” in this case meant “corrupted financial data”). Whether or not a team owns some technology is highly context dependent, and your comment comes across as reductive.
    - sebastianz 3y ago
      We are discussing lodash here. It's a javascript library with utility functions. The link we are discussing states they have just deleted 400 bugs declaring "bankruptcy". If you, like many people using lodash are using 10 util functions from it to iterate arrays or split strings, I'm sure you're better off just maintaining your own functions. And I say this as a user of prototype.js, another utility library, 18 years old, in a very old project. That lib is dead and unmaintained, and it's going to cost me a long time to remove. So now I've inherited all their bugs and code, and it's mine, just like if you use the old lodash, the "bankruptcy" bugs are now yours.

darepublic 3y ago

Because the surface area of lodash is so large and I need just a small fraction of it. And when I do need it it's easy to make a simple transparent version of the needed until rather than invoke a mystical black box. I admit this is opinionated and I have managed to work with lodash and keep my mouth shut about it

BoiledCabbage 3y ago
Thanks for sharing - I disagree with the approach, but understand it. Or rather, I feel that can work for individual coding, or possibly very small teams - but in the end I feel it usually works out to be unintentionally anti-team behavior. It trades off "I need to learn and understand this black box of behavior for instead I have this code that I know and can easily reason about". While for the entire rest of your team it went from "there is this common pattern that most of all 20 (or however many) of us know - and instead makes it 19 of us now need to learn this non-standard behavior/implementation, but at least one person knows well." Essentially everyone else has to learn more code, so that one person doesn't. Agreed it's usually not the most complex of code, but it's usually buggier and shifts to cost / burden to everyone else. The opposite of economies of scale and leveraging prior fixed costs of learning. But again, I don't know your situation and will readily admit my opinion above doesn't in anyway make it factually a better approach. Just my opinion on it same as yours.
- rcme 3y ago
  It works perfectly fine. You just copy and paste the code you need. If someone else needs it, they search the code base first, which is normal in large code bases. There are tons of different libraries that provide deep equality checks for instance. When I work in a code base, I need to search for existing solutions in the code base before adding someone new. It doesn’t matter if the functionality is provided by a first or third part library.
xeromal 3y ago
I'm not sure if you're aware but lodash has individual packages for each of their functions.

mostlylurks 3y ago

Not super relevant for lodash in particular, but another reason for why someone might want to do this is dependency hell. At least with code you write yourself, you know that the author(s) won't keep changing the API (very common in the javascript ecosystem, unfortunately), forcing you to either waste time constantly changing your own code to match the newer APIs, or stick to a single version for a long time, which may become incompatible with newer versions of other dependencies, your build system, your language, your environment, etc, which will become an issue if you have something else that you want to update but that old version of the dependency doesn't support it. So in some cases it might be easier and more maintainable to just write your own version of whatever small feature of the dependency you might otherwise have used, but knowing when this will be the case is a skill of its own.