4 ms·

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 wor

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.

lucideer 9y ago
> 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.
- Raphmedia 9y ago
  Fork, fix, create PR and point your repo to your fork until the PR is accepted. That's how you evolve open source projects. If everyone were to simply copy paste snippets in their projects for fear of library rot, every library would rot.
  - lucideer 9y ago
    This is the ideal. And I have done so when I can. But you're missing a step: > Fork, understand, fix, create PR That 2nd step is more time-consuming for some dependencies than others. I'm a strong proponent for understanding how your dependencies work, but there are always limits to the depth of knowledge of the internals of every one.

lucideer 9y ago

> 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.

Raphmedia 9y ago
Fork, fix, create PR and point your repo to your fork until the PR is accepted. That's how you evolve open source projects. If everyone were to simply copy paste snippets in their projects for fear of library rot, every library would rot.
- lucideer 9y ago
  This is the ideal. And I have done so when I can. But you're missing a step: > Fork, understand, fix, create PR That 2nd step is more time-consuming for some dependencies than others. I'm a strong proponent for understanding how your dependencies work, but there are always limits to the depth of knowledge of the internals of every one.