A very common programming tip is "Don't reinvent the wheel". If there's already a library that already does the task you need, why don't you just use that library instead of writing your own solution?
Many times, it's a sensitive thing to do: importing third-party libraries lets you focus on other tasks. Also, if you're using a popular library that has been stable for years, it probably does the task better than you! However, using third-party components have drawbacks.
The authors might deprecate the library or even delete it. Or the library (or any of their dependencies) might have a security problem and you have to wait until the authors fix it. Or they might even decide not to fix the security issue.
In 2016, there was an NPM JS package called "left-pad", which was used as a dependency for thousands of projects. One day, the original author deleted it and broke every single project that depended on it.
Another drawback may happen when your project changes after you used an external library. You may need to add new functionality that doesn't work with the library you added. Generally, this kind of problem can be solved, but it adds complexity to your project.
I think "don't reinvent the wheel" is a good approach, but you have to be careful every time you add an external library to your project:
- If the library you're adding is very big and you need a small part of it: it's probably a better idea to do it yourself or look for a smaller library.
- If the library has been popular for a long time, that's good. If you run into problems, you'll have a lot of documentation and help online.
- If the task is small or simple, it's a better idea to implement it yourself.
- If the task is very complex, looking for a library might be a good thing to do.
- If you have to do tasks involving security (cryptography, passwords, hashes, etc) it's very recommended to use a trustworthy, third-party library. Cyber security is a very complex field, if you try to create your own security-related tasks, it will be insecure.
To sum up: can "don't reinvent the wheel" be bad advice? The answer, as always, is: "it depends".
If you liked this article, you'll love my JavaScript Newsletter.
Every other Monday, I'll send you easy and actionable steps to level up your JavaScript skills. Check it out: https://nicozerpa.com/newsletter
Top comments (15)
If you think about it, a wheel, consisting of a rim with some sort of fastenings or fittings to an axle, depending on the vehicle, spokes or similar supporting structures, in some cases a tube and a tire made of a matrix of a carcass of special threads wrapped by a special mix of different rubbers, in many cases with some puncture protection, that could be fixed by a thread or wire to a hooked profile or in case of race bikes be glued to the rim, is actually a surprisingly complex device, even though it looks really simple.
On the other hand, a lot of things that look pretty complex, for example date manipulations in JS, are in some cases actually simple using native functionality.
So the main issue with the advice not to reinvent the wheel is that you need to be a good judge of actual simplicity, which requires a lot of experience, because you need to know about the edge cases and limitations, both of your own and the external solutions.
That being said, reinventing the wheel can be a great learning experience. Just be prepared to throw your code away in favor of another solution, which is not a bad advice in any case.
Thank you! I'm always defending the native Date object when talking to colleagues. I agree, using it natively is actually simple, no library needed.
On the other other hand some things in JS that look simple are very complicated, like copying a deeply nested object....
developer.mozilla.org/en-US/docs/W... to the rescue!
But before that was supported, it was really a difficult problem. I should know this, because I wrote a different proposal to support an extendable Object.clone() method, which was rejected in favour of structuredClone.
But that aside, you're obviously right.
This is a very good topic for discussion. My 2 cents here.
First factor to consider is your own level of expertise - If you are not expert enough to understand the inner workings of the wheel, I'd say it is better to simply use it as a black box and do not try to reinvent.
Second factor to consider is the use case - If the readymade wheel package does 100 things and you only need 1 thing out of those 100 things, I'd say go ahead and re-invent that 1 thing. Why let your use case carry the baggage of 99 things that are not going to be used?
Third factor to consider is what stage your project is in - If your project is in its early stages, requirements are not fully understood, say you want to quickly build an MVP, then you may not want to reinvent. Use whatever is readily available, stay lean and push ahead. But maybe a few iterations later, when you better understand the requirements and have a firmer grip on the problem you are trying to solve, you may want to consider removing dependencies and writing your own code.
I agree!. We should be more careful about this approach. Having external dependencies can be a huge tech debt to the team.. Plus, if people (mostly newbies) want to learn something in depth, reinventing wheel is a good idea.
I’d say, when you are learning, yes, it’s helpful to learn the basics.
However, on company time, I’d say no. The only piece that really matters is business logic, that part should be custom as much as possible. For example, do I want to write a library to handle rrules myself? If my company/project core feature is scheduling/calendar, then sure, otherwise no, I’d use something off the shelf.
i think that in so many cases remaking the same thing as someone else isn't productive, but if you make the same product with extra features or by making the product or service better then that's perfectly fine and i encourage it.
Sometimes you can learn alot from building your own custom solutions, but for production I would always recommend to use existing libraries for one simple reason: you're not responsible for maintenance. If you build a custom solution, you're responsible for maintaining it and if you're not careful it can start eating up a lot of time. I've seen big organizations (200+ people) grind to a complete halt, because they made everything custom and in-house and when it went into production they lost any kind of ability to improve their product, because all their dev teams eventually became preoccupied with fixing bugs. Obviously you need to be critical about which 3rd party libraries you use though. It's not a good idea to use all kinds of obscure libraries that are only used by a handful of projects and haven't had any activity for years.
I think most developers, given the choice, would much rather build everything themselves. I certainly much prefer to do this. Depending on the situation however, this isn't always possible, or indeed practical.
The benefits of 'reinventing the wheel' are numerous... to name just a few:
I think most developers just want to be productive, otherwise we wouldn't be using React (insert your preferred front end here ...), Laravel (insert your preferred backend here), MVC / repository pattern, serverless functions, CICD test runner, 3rd party APIs for maps, Auth, SMS
In my opinion reinventing stuff is fine, but it should be a requirement to unit test it as well.
Just recently I needed to debug/fix some reinvented HTTP client which was basically a PHP function calling the system's Curl command and parsing it's output. There were no unit tests, no linters and no readme. After talking to the original developer, he said "the other libraries are also just wrappers". He is right, but those other libraries are also tested xD
Yeahp! Nothing is just black and white! I do a lot of research before choosing libraries/frameworks due all the reasons you listed. Nice post 🎉
If you never grab the opportunity to reinvent your product/code/solution, it will eventually turn into legacy that nobody can or will work with.
I think you raise an important question that must be considered for each change in the team or in the product.
Jones