Shortly after programming was invented, someone noticed that it involved many repetitive operations. And shortly after that, someone else—maybe it was Ada Lovelace, spanner in hand, adjusting Babbage's differential engine, or maybe it was Alan Turing at Bletchley Park—decided to modularize code, so you only had to write certain chunks once, and could then re-use them. PHP programmers are used to writing separate chunks of code in functions, and then storing those functions in include files.

At one level, a framework is just that: lots of chunks of code, stored in separate files, which simplify the coding of repetitive operations.

In the examples above, connecting to the database or building HTML form elements are abstracted and simplified for you. You call a function in the framework, which is easier to handle than the original code.

It goes beyond that. Writing code involves continuous choices between the many ways of tackling the same problem; so most frameworks also impose a set of choices on you. They've started to handle the problem one way, so you have to go that way as well. If these are sensible choices, this makes your life much simpler too. (If not, it's like trying to write a sales brochure using Excel, or do cash-flow projections using Word. Both can probably be done, but neither is the best use of your time.)

Sensible design decisions make sure that the things you need are accessible, but prevent them from spilling over into each other. A good framework makes those decisions for you, starting you off with a sensible foundation for your program and guiding you through the next steps.

Mention frameworks nowadays, and people think of Ruby on Rails.

Rails has become the success story of the last year or so, because it apparently offers effortless and rapid website development, with a minimum amount of coding. Essentially, it is a structure and a set of tools, built for use with the Ruby language, that allow you to build certain types of Ruby programs more quickly. It's not the only framework for Ruby, but it is very effective and, deservedly, very popular. On the other hand, if you have put in the time and effort to learn PHP, starting over again in Ruby is a long haul.

There are several frameworks available for PHP as well. CI is only one of about 40. They include the Zend framework, Cake, Trax, and others. There's a handy chart at http://www.phpit.net/article/ten-different-php-frameworks/ that compares ten of the most popular.

If you look at them, you'll notice that postings on their user forums get very heated about which framework is the best. The truth seems to be that each has its strengths, and none is without its own weaknesses. My touchstone is that I'm busy; so frameworks should save me time, and having found one that works for me, I am sticking to it. That's why this book is just about CI.