[randyriegel]

I have been playing with CodeIgniter PHP framework just trying out some stuff and think it's pretty nice. I'm thinking of making my own set of classes that can do most of the things that I normally depend on. Might take some work to make my own generic classes that will work with any app i create but at least I'll know how they work inside and out. I'd just like to get some opinions on using CodeIgniter (or any other PHP framework) versus writing my own classes to do what I need done. Would like to hear about how a lot of you guys develop your apps.

Randy

[jason]

This is actually a topic that I'm somewhat passionate about. While I think the model-view-controller paradigm (or some variation thereof) is, in may cases, a sensible way to develop a site/application, I have yet to find a framework for which I can really get excited.

The reason for this is two-fold: For one, most frameworks require a rather steep learning curve. While I'm usually pretty comfortable in learning a new programming language, I've become somewhat set in my ways with the ones I already know. Frameworks require you to re-learn the language in a way--you have to learn the framework developer's take on the language to build proficiency in the framework. For me, if I don't know something I don't mind taking the time to learn it, but if I already know how to do it one way, I get bored trying to learn someone else's way.

Secondly, most of the frameworks that I've seen are full of bloat (I hear CodeIgniter is one of the less bloated frameworks, but I've never used it). Most PHP frameworks are build around some sort of object model. That's all well and good--I am a proponent of OOP--but PHP is an interpreted language. Since standard conventions dictate that you define each class in a separate file, each class the framework loads requires at least one file inclusion (and that number shoots up to two, three, or more once you start dealing with subclassing). File IO is one of the most expensive operations on the server. A typical framework may have to load 10-20 files just to display a single page, and since everything is interpreted in PHP, that means every single hit requires all of that file IO. Servers are fast these days, but keeping things well optimized may mean the difference between staying on shared our upgrading for a busy site.

That said, I have my own MVC-style "framework" that I have developed over the years. Mine isn't a formal software library, per se, just a style that I've developed that has proven to work well for me. In my system, I try to strike a balance between code efficiency and coding efficiency. Where it will help me out in development, I use OOP. For example, I make extensive use of PEAR's HTML_QuickForm (with a custom renderer--the default, table-based one is crap), because it really simplifies the process of pre-filling and validating forms, and I use classes for data models, as they provide easy reusability. But, if I don't absolutely need to be using an object, I don't.

I'd be happy to expand on this discussion at length, if you'd like. I was, in fact, supposed to present this very topic at a conference last fall, until my travel request got turned down.

For now, however, I'm going to go shovel snow. The airport reported today that a period of 116 consecutive hours of snow had come to an end. Granted, at my house we only received about a foot or so of snow in that time (areas closer to Lake Ontario got double that) and it's been consistently shoveled and plowed all week, but right now there are a couple of nice piles behind the cars that the plow left behind that I need to go make disappear.

--Jason

[JPC-Greg]

I tried to get into cake for a while, but that learning curve seemed like starting over after using php for 6years. I may revisit the idea though, I can see the benefits and frameworks are always advancing. I agree on the bloat and i/o, no doubt something that some frameworks are either working on or may have already. The speed at which you can build apps under a framework, once you get proficient in it, far exceeds the "old school" do it yourself model. That and the fact that I dont keep up on all the changes in php makes a framework appealing. Also one area they all have yet to address, and in fact every app in php needs to really start addressing, is making use of multi-core processors. Most code still does not do this at all which seems like a complete loss of the true potential speed and power of php. We are all still viewing most php app speeds from their potential 8yrs ago, back in the single proc days. Most apps would see a significant improvement today just by tapping all that unused potential.

[the_ancient]

For those of you that have tried other Frameworks and got discouraged, I STRONG urge you to try CI

Everything I have built over the last 2 years have been built Using CI,

I have Tried Cake, Zend, Kohana, pear, my own but I always end up back CI. There are some things I dont like (i.e Views not being Objects, and no Autoloading of Models, not modular, all of which I have corrected with my own extensions or extensions available in the community )

But is SUPER fast with little to no overhead.

GREAT documentation (which is by far the worst thing about every other framework out there)


I highly recommend CI as a base

[Gwaihir]

Originally Posted by jason

File IO is one of the most expensive operations on the server. A typical framework may have to load 10-20 files just to display a single page, and since everything is interpreted in PHP, that means every single hit requires all of that file IO.

Totally true, however largely a theoretical issue. A small site will indeed cause a relatively high load per hit, but it won't be much over all as it's a small site. Once your site starts to grow it is not really an issue anymore; as your pages get more and more hits, more and more of those files will be in the server's disk cache, which means no I/O, but reading from memory instead. If that's not good enough, you can add a cache such as APC that goes once step further and caches the compiled pages for you.

Originally Posted by JPC-Greg

Also one area they all have yet to address, and in fact every app in php needs to really start addressing, is making use of multi-core processors. Most code still does not do this at all which seems like a complete loss of the true potential speed and power of php. We are all still viewing most php app speeds from their potential 8yrs ago, back in the single proc days. Most apps would see a significant improvement today just by tapping all that unused potential.

I beg to differ. PHP does use multi-core processors quite effectively IMHO, with minimal developer effort and little chance of him screwing it up. Yes, each request is handled by a single thread. If that's not quick enough for your users, you're probably doing something wrong. However, each user request gets its own thread. So, if you have an 8-core machine, you can handle 8 requests at once without any slow down whatsoever. For pretty much every web hosting situation I can think of, this is what matters most: quickly handling many users simultaneously, with minimal fuss on the development side of things.

[That's for a pure PHP page, of course. Due to database use, apache serving images, etc, the one page request will in reality usually use more than one thread anyway.]

So, PHP's threading is IMHO only an issue if your application is meant specifically for a tiny number of users that exclusively need to run long and heavy tasks, such as report generation - exclusively: not in the background, but as the primary focus of your app. That however, is not really the market these MVC frameworks are in. You will indeed have to fend for yourself in this case and do your own thread management with the limited means PHP offers for it.