re: The hidden cost of “don’t reinvent the wheel” VIEW POST

re: I think this issue transcends any language specific developer. This is business driven culture practices (it depends where you work). Although I ha...

If a library works and doesn’t negatively effect the production bundle, has a developer friendly API, integrates cleanly with your environments, and has a shallow learning curve go ahead, use it. When there are several options available but none of them provide those things, code your own implementation. Sounds nice but there really aren’t any hard and fast rules. As others have pointed out, it’s case by case. There doesn’t have to be a greenfield project though to implement something custom.

True story. I tried to use a plugin for a thing. It did what I wanted but found a nasty side effect that meant I couldn’t use it. I try another package that does a similar thing, but no way to integrate cleanly. I diagnose the bug and create an issue in the repo, author responds promptly. I dig in deeper while figuring out if I could just submit a pull request. I find a bunch of unnecessary code that would effect performance. Is it worth my time arguing with the author? I took a hour to learn how to develop the plugin and wrote one that did the same thing but with far less code, implementation was more performant. A few minutes later after testing it out, I npm publish and integrate the new plugin with my project. Done in less than two hours. Yes, I’ll be on the hook for maintenance, but there is hardly any to speak of. Oh well. In my opinion, we need more of that kind of mentality in web development, but in my experience engineers with a “can do it” attitude are few and far between.

code of conduct - report abuse