How well this works depends a lot on the ecosystem.
When working with Node.js or JavaScript in the browser, there's often a huge number of modules available. But even though there may be six different modules trying to solve the same problem, every one of those modules may be incomplete.
When working with Ruby on Rails, I find that regular Ruby gems are pretty safe. There's often one or two popular, well-maintained solutions to a common problem, and I'd be fool to reinvent the wheel. However, gems which extend Rails itself can be more problematic, and they often break during major Rails upgrades.
Rust crates have a few nice properties: The Rust language itself has near-flawless backwards compatibility, Rust crates are immutable once published, and almost everybody uses semver. Oh, and cargo is great at managing dependencies. What this means is that it's often worth depending on very small libraries. Sure, maybe it's only 30 lines of code, but it's the right 30 lines, thanks to a process of refinement and to PRs from several people.
So the exact trade-offs here vary considerably, depending on the details of a specific ecosystem and its tools. I do agree that for browser-based stuff—especially if you're targeting evergreen browsers—that it's often better to write a few lines of code yourself than to add a badly-maintained dependency.
Sorry, I’m gonna say it straight: this is bullshits.
A bad behaving dependency (has useless deps) doesn’t invalidates the whole idea of using a package manager.
Probably the author has not enough experience in maintaining projects written by smart people where they write by themselves all the collateral parts.
Using dependencies extends the “standard” library so that it increases global (extra team, oss) reuse and the probabilty to find something “known“ in your next project.
Could be wrong, in that case I’ll stand corrected.
That may be true for backend stuff, but not for frontend development. Adding dependencies means that the user is exposed to a lot more.
I am blocking Javascript vigorously allowing the occasional first party script, if I really value the site. If you throw me into a vicious cycle of forcing me to allow more stuff at each cycle, I go away, especially on retail sites.
As their projects grows, they will find the need to copy/paste their code snippet all over again. As time goes, they will move on to other projects and other devs will have to understand their implementation of the code. As new browsers (and mobile devices) come out, people will have to refactor and improve their snippet of code.
Their colleague's version of the task however will simply require to update "react-scroll-to-component" to get new fixes. The component has a few closed issues and some opened ones. As there is community activity on it, they might as well leverage it.
Any new developers on their team will simply need to read the repo's documentation and examples. I doubt their version is documented.
The package "react-scroll-to-component" also has the advantage of living in the react's ecosystem. It isn't a few line of hack'ish Javascript but an actual component that you can configure in a React application. Any next places they will need to add scrolling behaviors will be an easy job. His snippet however will require playing in the source JS over and over again.
While I agree that "INSTALL ALL THE THINGS!!!" is a bad philosophy, in this case I agree with their colleague. That component only has a few dependencies and add pertinent features to the project.
I love the extreme tension between "small, clean code you write/verify yourself" and "opaque-ish package for everything".
Because the latter is so much more productive, I think the real question is, how do we manage the undesirable side-effects of the package-for-everything model?
I see the major concerns as:
- Potential security problems that evolve over time.
- Reduced understanding of how the underlying code works.
- Reduced mental clarity of how the project as a whole works.
- Non-traditional approach to debugging. (Dig through foreign code, post GitHub issues.)
- Artifact size / performance / power consumption issues.
I'm curious about novel approaches to help manage these concerns.
Don't forget licensing issues, which a lot of smaller companies maybe just look the other way on. That code you just copied and pasted from the web--what was it licensed under? Is it compatible with your company's software licensing? That 3rd party package you just deemed a critical dependency, how is that licensed?
The "grownup" companies I've worked for either explicitly ban or discourage "Programming by copy/paste from the Internet" and have review processes to gate inclusion of 3rd party code so that the licensing can be reviewed.
Licensing issues aside, 1. as a tech lead, I would feel obligated to act as the gate for bringing 3rd party dependencies into the project, and 2. if you cut paste code into my project, then during code review, you should be able to explain in great detail what it does. If you can't, it gets reverted.
Make it easier to understand exactly what any library function does from its signature, i.e. strong norms of functional purity (perhaps at the language level) combined with some way of representing effects (language-level effect systems, monads and the various constructions on top of them, or something else).
Reminds me of the Go Proverb, "A little copying is better than a little dependency."
When I created a hello world app in React, it took what felt like several minutes to pull down what seemed like hundreds of dependencies. My uninformed opinion is that the standard operating procedure in Reactland is to pull in "well tested" dependencies, where "well tested" means "downloaded a lot" and you hope the two are correlated.
Most of the dependencies installed for a hello world React app are not runtime dependencies.
I don't know if there's a real "standard operating procedure" or not, but it seems to me that it's the responsibility of each project maintainer to evaluate the fitness of a particular dependency for that project.
Just like with every package manager that I've ever heard of, you're responsible for what you install. I'm sure you can get buggy packages with poor test coverage via apt-get install / brew install / gem install / whatever-else install.
I prefer not to copy-paste solutions from the Internet because the web and the browsers generally keep upgrading. And some solutions from the past no longer work in the future. Historically, it has been much easier to upgrade a library/package than to maintain the code myself. At least that's my experience.
> Historically, it has been much easier to upgrade a library/package than to maintain the code myself. At least that's my experience.
Everyone's experience is different, mine, in this case, has been the opposite.
Library/package breakages caused by browser updates often take longer for the maintainers to release fixes for than I'd like to wait. I can fix myself and submit PRs, but this takes orders of magnitude more effort than fixing a similar thing in a library you wrote yourself; you can't be familiar with the internals of every external dependency, particularly as they're often generalised and therefore larger and more complex than if you write them yourself for specific functionality.
There's a trade-off of course, but I'd definitely consider updating libraries in response to browser update breakages a "con" when listing the pros and cons of using external deps.
It doesn't seem that bad actually. I prefer a developer to add an existing well-proven package than copy and paste some lines from the internet, since many times these lines won't handle many corner cases. That's the strength of packages - they already handle the case of empty array, empty string, invalid data, utf-8, that glitch in Chrome and plenty of other "little" things that break Stackoverflow code snippets.
Your application, your call. The trade-offs between implementing functionality yourself or using existing solutions ( with their transitive dependencies ) are entirely for you to evaluate and judge.
This is the modern Javascript coding style - you install small packages that implement your required functionality. The idea is to not solve problems that were solved before by somebody else. After all, if you're going to include somebody else's code that you didn't write anyway, what's the better way to do it - copy & paste, or use a package manager with versioning and high degree of control over downloaded packages that lets you abstract the required functionality away into a single line?
What is to be avoided is inclusion of packages that implement a ton of functionalities, and then only using a very small subset of those. In these cases it's better to create your own solution.
This is what separates experienced coders from amateurs imo. I’ve seen newer programmers tend to always “find” a library that would implement their required solution even what they needed is a super small subset of that library which could have been better off by just writing their own function.
what's the better way to do it
copy & paste, or use a package manager
When you add a dependency, how do you prevent the maintainer of the dependency or any sub- or sub-sub-...dependency to break your system in the future?
> Why do we even need package managers to install stuff?
Because it's nice to not have to write every bit yourself and end up with your own package manager anyway. (e.g. I'm not going to rewrite a ProtBuf lib for each project, I'll reuse my same code, but want to propogate update and bug fixes between projects.)
I'm less annoyed by libraries and package managers and more annoyed by "libraries" like leftpad and package managers like....well, most package managers. Here's hoping Nix or an intellectual decedents take hold and become more useful and universal. (OK, OK Cargo and RPM aren't that bad. Apt is OK, but too often leads to inconsistent states.)
Don't mind me... I'm just rewriting the entire internet and getting laughed at while kids these days get 3x the money because they took seven external projects, linked them together in five minutes, and made a "website" (complete with all the UX dark patterns, half-baked functionality, and third-party-triggered version updates straight into a broken dependency and version conflict).
This will sound obvious, but this problem is not restricted to web development. Java applications are often plagued by transitive dependencies too. I had to deal with unwanted libraries breaking WebLogic deployments more often than i'd like, up to the point of having to disable transient configurations for some apps and force explicit declaration of each dependency.
[+] [-] ekidd|8 years ago|reply
When working with Node.js or JavaScript in the browser, there's often a huge number of modules available. But even though there may be six different modules trying to solve the same problem, every one of those modules may be incomplete.
When working with Ruby on Rails, I find that regular Ruby gems are pretty safe. There's often one or two popular, well-maintained solutions to a common problem, and I'd be fool to reinvent the wheel. However, gems which extend Rails itself can be more problematic, and they often break during major Rails upgrades.
Rust crates have a few nice properties: The Rust language itself has near-flawless backwards compatibility, Rust crates are immutable once published, and almost everybody uses semver. Oh, and cargo is great at managing dependencies. What this means is that it's often worth depending on very small libraries. Sure, maybe it's only 30 lines of code, but it's the right 30 lines, thanks to a process of refinement and to PRs from several people.
So the exact trade-offs here vary considerably, depending on the details of a specific ecosystem and its tools. I do agree that for browser-based stuff—especially if you're targeting evergreen browsers—that it's often better to write a few lines of code yourself than to add a badly-maintained dependency.
[+] [-] yuchi|8 years ago|reply
A bad behaving dependency (has useless deps) doesn’t invalidates the whole idea of using a package manager.
Probably the author has not enough experience in maintaining projects written by smart people where they write by themselves all the collateral parts.
Using dependencies extends the “standard” library so that it increases global (extra team, oss) reuse and the probabilty to find something “known“ in your next project.
Could be wrong, in that case I’ll stand corrected.
[+] [-] chopin|8 years ago|reply
I am blocking Javascript vigorously allowing the occasional first party script, if I really value the site. If you throw me into a vicious cycle of forcing me to allow more stuff at each cycle, I go away, especially on retail sites.
[+] [-] Raphmedia|8 years ago|reply
Their colleague's version of the task however will simply require to update "react-scroll-to-component" to get new fixes. The component has a few closed issues and some opened ones. As there is community activity on it, they might as well leverage it.
Any new developers on their team will simply need to read the repo's documentation and examples. I doubt their version is documented.
The package "react-scroll-to-component" also has the advantage of living in the react's ecosystem. It isn't a few line of hack'ish Javascript but an actual component that you can configure in a React application. Any next places they will need to add scrolling behaviors will be an easy job. His snippet however will require playing in the source JS over and over again.
While I agree that "INSTALL ALL THE THINGS!!!" is a bad philosophy, in this case I agree with their colleague. That component only has a few dependencies and add pertinent features to the project.
[+] [-] trevyn|8 years ago|reply
Because the latter is so much more productive, I think the real question is, how do we manage the undesirable side-effects of the package-for-everything model?
I see the major concerns as:
- Potential security problems that evolve over time.
- Reduced understanding of how the underlying code works.
- Reduced mental clarity of how the project as a whole works.
- Non-traditional approach to debugging. (Dig through foreign code, post GitHub issues.)
- Artifact size / performance / power consumption issues.
I'm curious about novel approaches to help manage these concerns.
[+] [-] ryandrake|8 years ago|reply
The "grownup" companies I've worked for either explicitly ban or discourage "Programming by copy/paste from the Internet" and have review processes to gate inclusion of 3rd party code so that the licensing can be reviewed.
Licensing issues aside, 1. as a tech lead, I would feel obligated to act as the gate for bringing 3rd party dependencies into the project, and 2. if you cut paste code into my project, then during code review, you should be able to explain in great detail what it does. If you can't, it gets reverted.
[+] [-] lmm|8 years ago|reply
[+] [-] sethammons|8 years ago|reply
When I created a hello world app in React, it took what felt like several minutes to pull down what seemed like hundreds of dependencies. My uninformed opinion is that the standard operating procedure in Reactland is to pull in "well tested" dependencies, where "well tested" means "downloaded a lot" and you hope the two are correlated.
[+] [-] rwbcxrz|8 years ago|reply
I don't know if there's a real "standard operating procedure" or not, but it seems to me that it's the responsibility of each project maintainer to evaluate the fitness of a particular dependency for that project.
Just like with every package manager that I've ever heard of, you're responsible for what you install. I'm sure you can get buggy packages with poor test coverage via apt-get install / brew install / gem install / whatever-else install.
[+] [-] trevyn|8 years ago|reply
[+] [-] calineczka|8 years ago|reply
[+] [-] lucideer|8 years ago|reply
Everyone's experience is different, mine, in this case, has been the opposite.
Library/package breakages caused by browser updates often take longer for the maintainers to release fixes for than I'd like to wait. I can fix myself and submit PRs, but this takes orders of magnitude more effort than fixing a similar thing in a library you wrote yourself; you can't be familiar with the internals of every external dependency, particularly as they're often generalised and therefore larger and more complex than if you write them yourself for specific functionality.
There's a trade-off of course, but I'd definitely consider updating libraries in response to browser update breakages a "con" when listing the pros and cons of using external deps.
[+] [-] laurent123456|8 years ago|reply
[+] [-] baby|8 years ago|reply
[+] [-] sorokod|8 years ago|reply
[+] [-] dawkins|8 years ago|reply
[+] [-] nukeop|8 years ago|reply
What is to be avoided is inclusion of packages that implement a ton of functionalities, and then only using a very small subset of those. In these cases it's better to create your own solution.
[+] [-] westoque|8 years ago|reply
[+] [-] get|8 years ago|reply
[+] [-] AnIdiotOnTheNet|8 years ago|reply
Unfortunately it seems that people with my mindset towards dependencies are a dying breed.
[+] [-] jimktrains2|8 years ago|reply
Because it's nice to not have to write every bit yourself and end up with your own package manager anyway. (e.g. I'm not going to rewrite a ProtBuf lib for each project, I'll reuse my same code, but want to propogate update and bug fixes between projects.)
I'm less annoyed by libraries and package managers and more annoyed by "libraries" like leftpad and package managers like....well, most package managers. Here's hoping Nix or an intellectual decedents take hold and become more useful and universal. (OK, OK Cargo and RPM aren't that bad. Apt is OK, but too often leads to inconsistent states.)
[+] [-] inetknght|8 years ago|reply
[+] [-] bananarepdev|8 years ago|reply
[+] [-] scottmf|8 years ago|reply
Then use the package.
1. https://bundlephobia.com/
[+] [-] romanovcode|8 years ago|reply
[+] [-] DCoder|8 years ago|reply
[+] [-] zichy|8 years ago|reply
[+] [-] DCoder|8 years ago|reply
"Can we make it scroll to section 1 slowly, so the user sees what's going on?"
"The heading of section 1 gets covered by the sticky top menu bar, change it so scrolling places section 1 just below the sticky."
[+] [-] megaman22|8 years ago|reply
[+] [-] shafyy|8 years ago|reply
[+] [-] Double_a_92|8 years ago|reply
[+] [-] benbristow|8 years ago|reply