3 ms·

"...It'll be quicker and you'll learn more...." - Not to be snarky, but yeah - it'll be quicker to write up front, but you'll learn more...from finding and debu

by xweb 10y ago

"...It'll be quicker and you'll learn more...." - Not to be snarky, but yeah - it'll be quicker to write up front, but you'll learn more...from finding and debugging all the edge cases the library authors may have already dealt with. And there goes the time you "saved" up front.

lj3 10y ago
"may" being the key word here. The library you choose "may" have already dealt with those edge cases. Or you may spend hours or days debugging the god damned thing. In my experience in javascript development, the latter is far more likely.
Chris_Newton 10y ago
but you'll learn more...from finding and debugging all the edge cases the library authors may have already dealt with. And there goes the time you "saved" up front. That’s a common argument when you have a build-or-import decision, but that doesn’t necessarily make it correct. If you’re talking about importing a well-established library that has substantial functionality and a large user base with a lot of collective experience then yes, if the functionality is a good fit for your project then it could be a big time-saver. Likewise if you’re talking about importing libraries from a carefully curated repository with good review, testing and maintenance practices. However, in the modern JS world, many of the libraries that get pulled from GitHub/NPM and incorporated into projects are neither large and well-established in their own right nor part of a well-curated repository. In fact, many of them are written and (maybe) maintained primarily by a single developer, and in turn depend on other libraries also written and (maybe) maintained primarily by single developers. In that case, it seems optimistic to assume that everything you’re bringing in will necessarily have higher quality than anything you’d write yourself. Certainly it might, but on the other hand, you could just be trading debugging someone else’s code for your own, and with someone else’s code you’re working with one hand tied behind your back. It might still be a good trade, depending on how much functionality the imported code offers and how much time it will save you, and depending on how much overhead you’ll incur finding and importing that code and adapting and maintaining your own code to match. Or it might not.

by xweb 10y ago

lj3 10y ago

"may" being the key word here. The library you choose "may" have already dealt with those edge cases. Or you may spend hours or days debugging the god damned thing. In my experience in javascript development, the latter is far more likely.

Chris_Newton 10y ago

but you'll learn more...from finding and debugging all the edge cases the library authors may have already dealt with. And there goes the time you "saved" up front. That’s a common argument when you have a build-or-import decision, but that doesn’t necessarily make it correct. If you’re talking about importing a well-established library that has substantial functionality and a large user base with a lot of collective experience then yes, if the functionality is a good fit for your project then it could be a big time-saver. Likewise if you’re talking about importing libraries from a carefully curated repository with good review, testing and maintenance practices. However, in the modern JS world, many of the libraries that get pulled from GitHub/NPM and incorporated into projects are neither large and well-established in their own right nor part of a well-curated repository. In fact, many of them are written and (maybe) maintained primarily by a single developer, and in turn depend on other libraries also written and (maybe) maintained primarily by single developers. In that case, it seems optimistic to assume that everything you’re bringing in will necessarily have higher quality than anything you’d write yourself. Certainly it might, but on the other hand, you could just be trading debugging someone else’s code for your own, and with someone else’s code you’re working with one hand tied behind your back. It might still be a good trade, depending on how much functionality the imported code offers and how much time it will save you, and depending on how much overhead you’ll incur finding and importing that code and adapting and maintaining your own code to match. Or it might not.