There is no “best” in software
Dave Rolsky wrote a [fantastic article](http://blog.urth.org/2008/12/the-many-axes-of-software-development.html) on the many different criteria on which you can choose your software to use. For example: > # Easy to integrate - Some libraries are designed to be integrated with other modules (Catalyst), some want you to embrace their world (Jifty). > # Complete - Some libraries come with a complete solution (Jifty) and some require you to put together a bunch of pieces into a whole (Catalyst). Which is better? The answer, of course, is "it depends." Is the project for in-house use, or will it be distributed? Is it a one-off, where the base install will do most of what you want? Or are you likely to want to extend beyond those constraints? Most importantly, Dave points out: > I'd like to see people state their priorities up front, and explain why it's important for the work they do. Often this gets left out of the discussion. Without this information, we often end up just talking past each other. The extension of that is that many people may not even have thought about what their priorities are. Consider how often you'll see a question, such as at Stack Overflow, that asks ["What's the fastest way to do X?"](http://www.google.com/search?q=site%3Astackoverflow.com+fastest+way) Most of the time, the querist hasn't even thought about that "fastest" part; it's just assumed. (For that matter, that's like assuming that the most important part of a new job is how much it pays, but that's a topic for [another blog](http://theworkinggeek.com/).) Make sure you know what your priorities are. Question your assumptions. Your project will thank you for it.