Also convenience is not always the best reason to pick up a package, I've had way to many problems for adopting a package without thinking much about it. Great, it does what I want, and it does it really nicely. But after some time I needed to remove or change packages, because they do not update as quickly as you need them, they miss some critical feature, issues take way to long to be fixed... so you're stuck 5 versions behind (version in whatever framework/context), or need to re-write some part of your system with an alternative package.
Nowadays I follow these steps before adopting a package:
Could I implement it well in less that 2 hours? If yes, I will.
Who maintains this package? Is it a company, or an individual?
How easy is it to maintain and update?
How big is it?
How many opened issues are there, and how fast they are solved?
I could go on, but I think you get the gist of it
It all depends on what the context in which you use them is, for example for a personal project I will most likely try this kinds of libraries, but in a professional project I would evaluate really thoroughly if we integrate them or not.
I talk from experience here, as I've had to spend weeks solving problems caused by premature adoption of a package/library/whatever...
Could I implement it well in less that 2 hours? If yes, I will.
I know this can feel wrong, but if I spend 2 hours on this, I will have complete control over it, and will not depend on other people to update or fix bugs. In the end it makes my life easier.
Though this only applies to small packages, like the ones features in the original post. Otherwise I will research what the best package is, and check with my colleagues to see if they have not issues with it.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I totally agree.
Also convenience is not always the best reason to pick up a package, I've had way to many problems for adopting a package without thinking much about it. Great, it does what I want, and it does it really nicely. But after some time I needed to remove or change packages, because they do not update as quickly as you need them, they miss some critical feature, issues take way to long to be fixed... so you're stuck 5 versions behind (version in whatever framework/context), or need to re-write some part of your system with an alternative package.
Nowadays I follow these steps before adopting a package:
It all depends on what the context in which you use them is, for example for a personal project I will most likely try this kinds of libraries, but in a professional project I would evaluate really thoroughly if we integrate them or not.
I talk from experience here, as I've had to spend weeks solving problems caused by premature adoption of a package/library/whatever...
I know this can feel wrong, but if I spend 2 hours on this, I will have complete control over it, and will not depend on other people to update or fix bugs. In the end it makes my life easier.
Though this only applies to small packages, like the ones features in the original post. Otherwise I will research what the best package is, and check with my colleagues to see if they have not issues with it.