I have been thinking the past few days about two particular competing articles I read from Twitter. The first article was by Thomas Fuchs, Prototype.js team member and script.aculo.us creator, and it argued the perils of large, underutilized frameworks (e.g. jQuery). The [article](http://goo.gl/RKeii) boils down to this: >I for one welcome our new micro-framework overlords—small frameworks and libraries that do one thing only, not trying to solve each and every problem, just using pure JavaScript to do it. Easy to mix and match, and to customize to your needs. Now the article did make some good points, but I came away from it feeling that his assertion is that large frameworks are essentially evil. The next day I read an article ([Imagine a Beowulf Cluster of JavaScript Frameworks](http://tomdale.net/2011/04/imagine-a-beowulf-cluster-of-javascript-frameworks/)) with an opposing viewpoint by Tom Dale, a SproutCore team member (SproutCore is a large library), which argues that Thomas Fuchs' ideas sound nice, but they aren't practical for the reason that amassing several smaller dependencies in software as opposed to one large dependency doesn't really solve anything, and in fact can introduce problems of incompatibility. It recommended that larger frameworks should be used instead of several smaller ones. So who is right? I decided to broach the subject with my colleague, [Nate Taylor](http://blog.palelocust.com/), to get his thoughts, and he made an excellent point: >Neither of these positions is correct. Holding to one viewpoint may not be the correct choice in every situation. That's right, neither viewpoint should be constantly adhered to. In good software engineering, it's important to always evaluate the tools needed to do the job well and efficiently. If you are writing a large scale application, chances are you are going to need a more fully-featured JavaScript application stack to get the job done, whereas a small mom-and-pop website may only benefit from a few helping libraries. So come away from these two articles with this: there's no need to demonize large OR small frameworks, don't pit them against each other. Rather, carefully evaluate what tools are best suited to solve your problem for the current situation and I guarantee that the decision you come to will be the correct one, whether it's a large framework or several micro-frameworks.
