Re: Re: PHP Frameworks

haliphax wrote:

On Mon, Mar 9, 2009 at 1:26 PM, Jason Norwood-Young <jason@freespeechpub.co.za> wrote:

haliphax wrote:

    
Perhaps I should have phrased it a bit more concise: This has been

discussed many times--often, and RECENTLY. Anyway, since I'm already writing this, I'll say that overhead/bloat vs. productivity of the developer is a trade-off you're going to have to make for ANY of the frameworks out there.

I disagree somewhat. A good framework should actually reduce bloat. It encourages you to implement proper MVC architecture, helps you avoid those rambling "function.php" files, and if it's well built, things like DB connectivity should already be optimised. I like CI because it does all of that fairly well, and tends to perform faster than something some coder (like myself) hacked together in the smallest time-frame possible. I use it on some pretty big sites - one with DB's with 10's of millions of records, and one site with over 1.5 million users a month. Personal thumbs up for CI, but use whatever suits your skill level, timeframe and requirements. Some frameworks will increase bloat, but sometimes that's worth it to get the project out the door in a given timeframe. If you're doing a blog on caring for chickens, throw it up in an hour with WordPress. If you're planning on being the next NY Times, WordPress will not be a kind mistress. There are down sides to CI too, but it suits my needs for the types of sites I produce.

Framework = Overhead (when compared to vanilla PHP). Period. I'm not saying it's overhead that will cripple your application, or that frameworks should be avoided... quite the contrary, in fact. I have recently fallen in love with CodeIgniter myself--I'm just saying that one should be at least respectfully aware of the overhead that comes hand-in-hand with a(ny) framework, and weigh those against what you feel is acceptable for your purpose. And I'm saying that using vanilla PHP sometimes (I'd say more often than not - especially with a group of developers of varying skill and experience) leads to sloppy programming, bad architecture and monolithic libraries, which in turn can lead to more overhead than simply starting with a framework. Not that a framework will save you from bad code - but it should point you in the right direction and make it obvious how you *should* do things.