6 ms·

> Frankly, copy/paste is a superior code reuse mechanism at this scale. The one advantage I see to having borderline-ridiculous packages such as this is that t

> Frankly, copy/paste is a superior code reuse mechanism at this scale. The one advantage I see to having borderline-ridiculous packages such as this is that they do One Thing Well [1]. Yes you may copy/paste an isObject() function or roll your own, but then it becomes your responsibility to make sure it works for your project, and arguably far fewer eyes on it when it doesn't. As long as the project's maintainer is dedicated to making this the best way to determine whether a variable is an object, I have no problem using it. Although, I do find the 57 commits irksome. Most of them are just upgrading dependencies (code style checkers, etc.), "fixing" indentation, and in one case 7 separate tweet-sized diffs to the README on the same day, as if this guy has git commit/push bound to Ctrl+S in his editor. [1] http://www.catb.org/esr/writings/taoup/html/ch01s06.html http://www.catb.org/esr/writings/taoup/html/ch01s06.html

js2 12y ago
Probably the README was edited via github's web UI.
slavik81 12y ago
It seems harder to verify that the module maintainer is competent and trustworthy (and to keep up-to-date on maintainer changes).
- mattdesl 12y ago
  In the case of is-object the api is frozen, and with any module it's assumed that any breaking changes would come in via a major version (ie not break your code). Yeah, sure, if the maintainer becomes evil overnight he can break a lot of apps. If you live in fear then you probably won't enjoy npm very much.
saurik 12y ago
In my experience, if these kinds of things break (whether due to a very esoteric corner case, a buggy browser that needs to be worked around, or a new version of the language specification), the person who discovered that it didn't work doesn't get it fixed upstream: they instead push a new module that they try to get people to switch to, talking about how much better theirs is (this happens partly due to the glory, but also partly due to it seemingly legitimately nonsensical to submit a patch to someone else's project that is "subtract your file and add mine", given that it is seriously a single line of code). Meanwhile, the original developer was usually part of the same community-bereft modern GitHub-era open source culture (where publishing code is the victory condition, as opposed to building culture), and isn't around to fix their library even if someone did submit a patch, so it becomes your responsibility anyway, only now it is to realize that the module you are using is "so last month" and figure out which replacement is the correct one. This is not much better than just copying and pasting code from Stack Overflow, yet frankly more infuriating as at least when you copy/paste it was more clear what you walked into.
- mattdesl 12y ago
  Has any of this actually happened to you with focused modules like to-dash-case? There is no reason for such a focused module to go out of style. As with many other small modules, the API and major version is locked barring some catastrophic event. Maybe there is a rare edge case that will break, and then you end up with two modules which are both useful in their own regard (like point-in-polygon and robust-point-in-polygon).
kyllo 12y ago
The one advantage I see to having borderline-ridiculous packages such as this is that they do One Thing Well Sure, but one function per package is silly. Why not just put all the related utility functions in one package? Underscore does One Thing Well too. And if I really, really care about optimizing for small JS file size, I can just go in my Underscore.js file and remove all the functions I don't want to use.
- insin 12y ago
  Or you could use Lo-Dash and require() the specific functions you actually used instead of the whole thing, after you're done: https://www.npmjs.com/browse/keyword/lodash-modularized https://www.npmjs.com/browse/keyword/lodash-modularized It's nice to have the option.
- vog 12y ago
  Or, use something like the closure compiler to remove unused code automaticaly.
xamuel 12y ago
They don't even do One Thing Well. The is-upper-case example checks uppercaseness by converting the entire string to uppercase and checking whether the result equals the original. What if the string in question is "xxx...x" (lowercase x repeated a million times)?
- josteink 12y ago
  Doing "One thing well" can be defined in several things depending on what you consider of utmost importance for wellness. I think that function does what it's supposed to "well" in the sense that 1. it works, 2. the code is clean and obvious and 3. it doesn't try to be clever and do "complex" things which can introduce bugs. I'm guessing from your complaint that you think it doesn't do things "well" because you prefer code to computationally efficient over conceptually and declaratively clear? You can argue that "But for -this- little thing I can afford to be a clever and throw the obvious-looking code out the window!", but then everyone else also gets to do the same judgement too. And then suddenly you're all using "clever" code all over the place with new ingenious ways to break everywhere in your code-base. And just like clockwork, your application will start breaking and nobody will know why without spending hours, days or even weeks debugging. Let's say I generally don't think computationally efficient code is worth that cost. I'll make exceptions for specific code-portions which needs to be fast, but for my bread and butter code? Make it plain and simple!
  - xamuel 12y ago
    If I'm importing a module for is-upper-case, it had better be for a reason: that someone actually did something significant on that problem and I don't want to reinvent their work. The module in question is nothing but a #define macro. Javascript lacks a preprocessor and this community's response is apparently to outsource #define macro's to a centralized server. >And just like clockwork, your application will start breaking The alternative is that just like clockwork, your application grinds to a crawl and practically freezes the browser. Because you outsourced every last thing to someone who doesn't care about performance. Sure, it's fine for the static-html-page-that-you're-doing-in-node-for-some-inexplicable-reason. Just hope you know what you're doing when you do something more complicated.

js2 12y ago

Probably the README was edited via github's web UI.

slavik81 12y ago

It seems harder to verify that the module maintainer is competent and trustworthy (and to keep up-to-date on maintainer changes).

mattdesl 12y ago
In the case of is-object the api is frozen, and with any module it's assumed that any breaking changes would come in via a major version (ie not break your code). Yeah, sure, if the maintainer becomes evil overnight he can break a lot of apps. If you live in fear then you probably won't enjoy npm very much.

saurik 12y ago

In my experience, if these kinds of things break (whether due to a very esoteric corner case, a buggy browser that needs to be worked around, or a new version of the language specification), the person who discovered that it didn't work doesn't get it fixed upstream: they instead push a new module that they try to get people to switch to, talking about how much better theirs is (this happens partly due to the glory, but also partly due to it seemingly legitimately nonsensical to submit a patch to someone else's project that is "subtract your file and add mine", given that it is seriously a single line of code). Meanwhile, the original developer was usually part of the same community-bereft modern GitHub-era open source culture (where publishing code is the victory condition, as opposed to building culture), and isn't around to fix their library even if someone did submit a patch, so it becomes your responsibility anyway, only now it is to realize that the module you are using is "so last month" and figure out which replacement is the correct one. This is not much better than just copying and pasting code from Stack Overflow, yet frankly more infuriating as at least when you copy/paste it was more clear what you walked into.

mattdesl 12y ago
Has any of this actually happened to you with focused modules like to-dash-case? There is no reason for such a focused module to go out of style. As with many other small modules, the API and major version is locked barring some catastrophic event. Maybe there is a rare edge case that will break, and then you end up with two modules which are both useful in their own regard (like point-in-polygon and robust-point-in-polygon).

kyllo 12y ago

The one advantage I see to having borderline-ridiculous packages such as this is that they do One Thing Well Sure, but one function per package is silly. Why not just put all the related utility functions in one package? Underscore does One Thing Well too. And if I really, really care about optimizing for small JS file size, I can just go in my Underscore.js file and remove all the functions I don't want to use.

insin 12y ago
Or you could use Lo-Dash and require() the specific functions you actually used instead of the whole thing, after you're done: https://www.npmjs.com/browse/keyword/lodash-modularized https://www.npmjs.com/browse/keyword/lodash-modularized It's nice to have the option.
vog 12y ago
Or, use something like the closure compiler to remove unused code automaticaly.

xamuel 12y ago

They don't even do One Thing Well. The is-upper-case example checks uppercaseness by converting the entire string to uppercase and checking whether the result equals the original. What if the string in question is "xxx...x" (lowercase x repeated a million times)?

josteink 12y ago
Doing "One thing well" can be defined in several things depending on what you consider of utmost importance for wellness. I think that function does what it's supposed to "well" in the sense that 1. it works, 2. the code is clean and obvious and 3. it doesn't try to be clever and do "complex" things which can introduce bugs. I'm guessing from your complaint that you think it doesn't do things "well" because you prefer code to computationally efficient over conceptually and declaratively clear? You can argue that "But for -this- little thing I can afford to be a clever and throw the obvious-looking code out the window!", but then everyone else also gets to do the same judgement too. And then suddenly you're all using "clever" code all over the place with new ingenious ways to break everywhere in your code-base. And just like clockwork, your application will start breaking and nobody will know why without spending hours, days or even weeks debugging. Let's say I generally don't think computationally efficient code is worth that cost. I'll make exceptions for specific code-portions which needs to be fast, but for my bread and butter code? Make it plain and simple!
- xamuel 12y ago
  If I'm importing a module for is-upper-case, it had better be for a reason: that someone actually did something significant on that problem and I don't want to reinvent their work. The module in question is nothing but a #define macro. Javascript lacks a preprocessor and this community's response is apparently to outsource #define macro's to a centralized server. >And just like clockwork, your application will start breaking The alternative is that just like clockwork, your application grinds to a crawl and practically freezes the browser. Because you outsourced every last thing to someone who doesn't care about performance. Sure, it's fine for the static-html-page-that-you're-doing-in-node-for-some-inexplicable-reason. Just hope you know what you're doing when you do something more complicated.