5 ms·

Roll your own, untested function vs a small, widely used library with a well-understood, well-tested API that your devs have a good chance of being familiar wit

Roll your own, untested function vs a small, widely used library with a well-understood, well-tested API that your devs have a good chance of being familiar with already. I too want to avoid bloated npm dependencies but this seems like a fair engineering trade-off..

anonytrary 8y ago
This is a trivial function, your argument applies to complex utilities. It is piss easy to roll your own, and it's not worth introducing a potential attack vector via a new dependency. In this case, if your devs can't keep up with your classNames function, fire them, because it's trivial. it("should work with no classes", () => { expect(classNames({}).to.be.false }) it("should work with a single class", () => { expect(classNames({a:true})).to.equal("a") }) it("should work with booleans", () => { expect(classNames({a:true, b: false}).to.equal("a b") }) it("should work with falsy and truthy values", () => { expect(classNames({a: 5, b: ""}).to.equal("a b") }) This isn't redux. It's a trivial utility function. Your kind of thinking is too often applied without thinking. Before depending on someone's code, ask yourself if you can roll your own in under 5 minutes. The answer could easily be yes. There is no good reason to depend on someone else's code if it's trivial. Having more dependencies than you need is a cardinal sin that way too many javascript developers commit.
- rckclmbr 8y ago
  it("should work with booleans", () => { expect(classNames({a:true, b: false}).to.equal("a b") }) Shouldnt this just equal "a" though? See, already a bug in your homegrown solution!
  - anonytrary 8y ago
    My test would fail, and I would fix it. + 2 seconds. Actually, the next test has the same problem. 2 more seconds. I'm gonna be in trouble with my boss!
    - littlecranky67 8y ago
      No, your test wouldn't fail because you wrote your code already being confident it is correct and went on. The bug would surface later in your team, somebody else in your team not familiar with your code would spent hours figuring out what is wrong, will consult you about your intentions when you wrote the code etc.
      - anonytrary 8y ago
        No, the test would fail in this case because the code was written properly because it was a TRIVIAL 2-line function (see above). A few people in this thread have regurgitated the same reasoning you have. The problem is that your reasoning is NOT an invariant under complexity. This reasoning does not apply nearly as much to trivial utility functions such as: const isObj = o => !!o && typeof o === "object" and classNames, etc. as it does to larger, more complex code. > will consult you about your intentions when you wrote the code etc. No, no they won't. No one will consult me on what my 2-line classNames functions does. It's 2 non-obfuscated lines. These aren't undergrads in CS101.
- jhall1468 8y ago
  If you write 100 ~50 line "trivial functions" you've now written 5000 lines of code that doesn't actually solve your underlying problem, it just makes it slightly easier. And you can't write this particular utility function in 5 minutes and support all the uses-cases, particularly if you are going to write a bunch of unit tests. The reason to depend on someone else's code in trivial use-cases is entirely because they are trivial. There's nothing you're doing aside from wasting time by writing it. lodash is literally a massive library of mostly "trival" functions that no one is every going to write themselves because WHY waste the time? The only cardinal sin at play here is thinking that wasting your time reinventing the wheel is time well spent. This approach is what I'd expect from either a very young developer or a very self-centered one.
  - BigJono 8y ago
    Yeah and if you've analysed 100 sets of docs for 100 dependencies you've done a ton more work than writing 100 trivial functions. Why does everyone in JS land treat dependencies like they're just some free magic, as if an intimate familiarity with the source code is injected into your entire team's brains the moment you type 'npm install'? I've worked with far too many people that blow out the package.json file for every little thing then wonder how every other dev on their team seems to be paralysed by the smallest task. Every time someone on your team runs into a dependency boundary they need to stop reading code, pull up a browser, and start reading docs. You can't trace the path of execution through a black box dependency, which means if you use a bunch of them in one place your developers are going to have to hold a hell of a lot of information in their head while they analyse that code. If they drop something, it's back to the docs again. At the extreme, it's a context switching nightmare. Dependencies cost time, effort and brain power. Make sure you're getting enough in return.
    - jhall1468 8y ago
      You're absolutely wrong. If reading the docs were harder/more work than writing the code we'd have 100s of implementations of lodash. Instead people use lodash. Dependency boundary? If you can't figure out what a function called classNames does in the context of a React render function in which the output of classNames is put as a value in to "className" attributes, you need to find a new job. Dependencies cost time, effort and brain power when they actually require those things. Be thoughtful when using something that actually requires investigation. But honestly, a trivial function should be self-documenting or it really isn't trivial, is it? If I had an npm library called array-flatten are you seriously going to read the docs, or assume it flattens nested arrays?

anonytrary 8y ago

This is a trivial function, your argument applies to complex utilities. It is piss easy to roll your own, and it's not worth introducing a potential attack vector via a new dependency. In this case, if your devs can't keep up with your classNames function, fire them, because it's trivial. it("should work with no classes", () => { expect(classNames({}).to.be.false }) it("should work with a single class", () => { expect(classNames({a:true})).to.equal("a") }) it("should work with booleans", () => { expect(classNames({a:true, b: false}).to.equal("a b") }) it("should work with falsy and truthy values", () => { expect(classNames({a: 5, b: ""}).to.equal("a b") }) This isn't redux. It's a trivial utility function. Your kind of thinking is too often applied without thinking. Before depending on someone's code, ask yourself if you can roll your own in under 5 minutes. The answer could easily be yes. There is no good reason to depend on someone else's code if it's trivial. Having more dependencies than you need is a cardinal sin that way too many javascript developers commit.

rckclmbr 8y ago
it("should work with booleans", () => { expect(classNames({a:true, b: false}).to.equal("a b") }) Shouldnt this just equal "a" though? See, already a bug in your homegrown solution!
- anonytrary 8y ago
  My test would fail, and I would fix it. + 2 seconds. Actually, the next test has the same problem. 2 more seconds. I'm gonna be in trouble with my boss!
  - littlecranky67 8y ago
    No, your test wouldn't fail because you wrote your code already being confident it is correct and went on. The bug would surface later in your team, somebody else in your team not familiar with your code would spent hours figuring out what is wrong, will consult you about your intentions when you wrote the code etc.
    - anonytrary 8y ago
      No, the test would fail in this case because the code was written properly because it was a TRIVIAL 2-line function (see above). A few people in this thread have regurgitated the same reasoning you have. The problem is that your reasoning is NOT an invariant under complexity. This reasoning does not apply nearly as much to trivial utility functions such as: const isObj = o => !!o && typeof o === "object" and classNames, etc. as it does to larger, more complex code. > will consult you about your intentions when you wrote the code etc. No, no they won't. No one will consult me on what my 2-line classNames functions does. It's 2 non-obfuscated lines. These aren't undergrads in CS101.
jhall1468 8y ago
If you write 100 ~50 line "trivial functions" you've now written 5000 lines of code that doesn't actually solve your underlying problem, it just makes it slightly easier. And you can't write this particular utility function in 5 minutes and support all the uses-cases, particularly if you are going to write a bunch of unit tests. The reason to depend on someone else's code in trivial use-cases is entirely because they are trivial. There's nothing you're doing aside from wasting time by writing it. lodash is literally a massive library of mostly "trival" functions that no one is every going to write themselves because WHY waste the time? The only cardinal sin at play here is thinking that wasting your time reinventing the wheel is time well spent. This approach is what I'd expect from either a very young developer or a very self-centered one.
- BigJono 8y ago
  Yeah and if you've analysed 100 sets of docs for 100 dependencies you've done a ton more work than writing 100 trivial functions. Why does everyone in JS land treat dependencies like they're just some free magic, as if an intimate familiarity with the source code is injected into your entire team's brains the moment you type 'npm install'? I've worked with far too many people that blow out the package.json file for every little thing then wonder how every other dev on their team seems to be paralysed by the smallest task. Every time someone on your team runs into a dependency boundary they need to stop reading code, pull up a browser, and start reading docs. You can't trace the path of execution through a black box dependency, which means if you use a bunch of them in one place your developers are going to have to hold a hell of a lot of information in their head while they analyse that code. If they drop something, it's back to the docs again. At the extreme, it's a context switching nightmare. Dependencies cost time, effort and brain power. Make sure you're getting enough in return.
  - jhall1468 8y ago
    You're absolutely wrong. If reading the docs were harder/more work than writing the code we'd have 100s of implementations of lodash. Instead people use lodash. Dependency boundary? If you can't figure out what a function called classNames does in the context of a React render function in which the output of classNames is put as a value in to "className" attributes, you need to find a new job. Dependencies cost time, effort and brain power when they actually require those things. Be thoughtful when using something that actually requires investigation. But honestly, a trivial function should be self-documenting or it really isn't trivial, is it? If I had an npm library called array-flatten are you seriously going to read the docs, or assume it flattens nested arrays?