5 ms·

Wow. I bet these could even be grouped into one module with minimal size overhead by using some higher-order functions or something. https://github.com/blakee

• theverything 12y ago
  They are - https://github.com/blakeembrey/change-case https://github.com/blakeembrey/change-case
• mattdesl 12y ago
  To illustrate the problem: my dom-css module[1] needs a method to convert to camel case. I could copy-paste from stack overflow, but I would have to maintain/test that function. I'd rather depend on something. I could depend on a big "string-utils" library, but that would probably carry some useless baggage, and its scope may change or grow over time. Further, maybe it has a competitor module with a vehement following (like lodash vs underscore), which makes my module less appealing to them. This sucks for my module because I just want that one function. The better alternative is just to depend on the exact, clearly named "to-camel-case" function which is very unlikely to ever change or grow in scope. [1]https://npmjs.com/package/dom-css https://npmjs.com/package/dom-css
  • deleted 12y ago
    [deleted]
  • jesstaa 12y ago
    so you're just manually doing with a linker is supposed to do for you? I guess it goes along with manually doing what a scheduler does for you.
    • mattdesl 12y ago
      Linking functions; but also minimizing scope creep, API changes, opinionated libraries with a questionable lifespan, bit rot, and versioning woes (eg. a major change in to-dash-case may not represent a major change in to-camel-case).
  • nostrademons 12y ago
    If the to-camel-case function never changes or grows in scope, then you don't need to maintain or test it. If it does change, then you need to integrate & test your dependencies, same as if it were part of your own codebase. I think this point is often overlooked by the "I'll use someone else's code because I don't want to maintain it" folks. Code that is frozen doesn't rot: if you never change a piece of code and don't change its dependencies, it will continue working. Similarly, usually the reason you'd in-source a library is so you can change it at-will without getting some other maintainer to accept your patches. Most of the time, the effort that you save by using 3rd-party code is exactly equal to the time it would take to write & debug the library to get it to its current state, minus the time spent hunting for, learning, and integrating the library. Both of these are pretty easy to estimate when it's a one-line function; does it take you longer to find and npm install that one-line function than it does you to write a line of code?
    • williamcotton 12y ago
      There's a cohesive social element to "many small modules" that fosters a community. Module authors work with and respect each other. Most of the time, the effort that you save by using 3rd-party code is exactly equal to the time it would take to write & debug the library to get it to its current state, minus the time spent hunting for, learning, and integrating the library. There are plenty of small functions that might be a little trickier than is first imagined. Time isn't the only issue. There's also much less cognitive overhead in the two minutes it takes to search npm, figure out the interface, install the module, and use it. I'd much rather outsource my yak shaving.
• gdi2290 12y ago
  you realize each one of those modules are download rank top 1% of NPM