Have you been to someone’s GitHub, looking for that little module you need to solve a problem, only to have to sift through forty thousand files to find it? Or you are told that this one little thing has a dependency or two that are easily three or four times the size of the thing you actually need?
Of course, you should never shy away from laziness . . . I mean, “efficiency” in programming, but what I like to advocate is portfolio-first programming. If you start every single project you do with the assumption that you’re going to be depending on Node, React, jQuery, Bootstrap, and whatever else, all you’re doing is adding a thousand solutions to a project that may only have a handful of problems to solve. What good is the rest of it then?
If your timelines allow it, start with nothing. Nothing but a list of requirements and whatever problems those requirements present. Solve those problems first by thinking about how you would do it, and only after that by looking for existing solutions. By building your own tools, you not only strengthen yourself as a programmer, but you give yourself complete control over your project and what goes in it. Why include jQuery if all you need is a DOM selector? Why use an imposing MVC/routing framework on a site with only a few pages? Your project is now 35 to 145kb lighter on every individual page, not counting any code necessary to implement these libraries.
In addition to the immediate benefits, you also build a healthy portfolio of solutions to problems. That is our job as programmers, after all: solving problems. The best programmers are not ones that say “Well, if I had X framework, I could do it,” but the ones who casually drop “I’ve got a few solutions for that in my GitHub depending on what we need.” Be the person with the toolkit, not the person who only knows how to use a hammer.