Jason Norwood-Young 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.
I agree with you're disagreement, a good framework will indeed reduce
> fork post >
*jumps on* the MVC thing, you can't just say "mvc" is the appropriate
architecture for php applications; true many the frameworks follow the
whole pythonesque MVC thing; but that doesn't make it any more the
correct choice than any other architecture or design pattern. There is
no "fits all" and all too often you see people trying to overstretch
there framework of choice to something it just doesn't do and wasn't
designed for (not as common as trying to fit drupal in a square hole
However IMHO there are other benefits which outweigh this:
- multi other developers will be familiar with the codebase and be able
to on board rapidly should the project expand
- the client won't be left with some unknown codebase that only you
"really" know (unless of course you want to tie the client in)
- you learn well known re-usable code that you can take to other
projects (and add to the cv)
- bugs in code move from being a headache to an opportunity for
improvement and benefit the "community" (and often fixed by others)
- your code base is ever improving without you doing any work
- and all the obvious stuff..
"If you're planning on being the next NY Times, WordPress will not be a
kind mistress." - lol, I wish all clients understood this.
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php