View http://www.rachelandrew.co.uk/archives/2012/03/21/stop-solving-problems-you-dont-yet-have/
This article is a bit old but in my opinion still rings as true today as it did when it was written. We have so much stuff to work with as front end developers it’s easy to get lost in the shuffle. As a byproduct of that, so many libraries and frameworks and classes make it into our “boilerplates” there comes a time where we’re simply introducing bloat.
If I’m honest, I rarely if ever need to use Modernizr. The project is awesome and has proven to be a game changer but in reality the only thing I’ve utilized it for in production is it’s built in html5shiv. It might be a shortcoming of my workflow, but I tend to use progressive enhancement techniques as opposed to Modernizr’s philosophy. I recognize that some of the probing Modernizr does can make or break your app, but in my average project those things don’t come into play. I’m just trying to illustrate that even though something like Modernizr is wicked awesome, it’s also wicked overkill for me the majority of the time. I’m sure we can all extrapolate that into other things we bundle with each of our projects as a starting point, and do some effective trimming that will save both on complexity and bandwidth over time.
I specifically like the example in the article of tackling CSS3 implementations in older browsers. I’ve used the CSS3 polyfill libraries in the past but some time ago simply defaulted to writing my own via jQuery and in doing so minimizing the overhead to support legacy rendering engines.
As programmers we should strive for the bare minimum, as counter-intuitive as that sounds. Wait until you’ve actually got a problem before you try to solve it. Your experience will be worth it’s weight in gold in figuring out where to draw that line, and you’ll get better at it with each project.