I wish more attention would return to Kohana (kohanaframework.org), which is basically CodeIgniter done better by a community of coders, except the documentation for 3.x is sparse and IMO certain things in 2.x were better.
This idea for CI is nice, but the video reminded me of one of the more annoying parts of CI: $this->load->whatever()ing everything, which should be rightfully obsoleted for everybody running PHP5 as it is in Kohana, because PHP can autoload classes with your own custom __autoload() function. It's wasted effort to manually load everything and the collisions created in the local namespace are intolerable.
Kohana 3.x has nothing to do with the Codeigniter framework. Even Kohana 2.x was a complete rewrite from Codeigniter.
Kohana is indeed a much modern PHP MVC framework. It supports a cascading file-system and HMVC out of the box. There is a lack a polished documentation but I've been working with Kohana 3.x since it's release and the documentation hasn't been much of an issue.
However, if you're new to MVC and/or programming Codeigniter might be a better choice.
Concerning the post. I'm not sure how useful this is. The amount of time you spend installing modules/plugins is disproportional to the amount of time you spend on building your site. Normally you end up using a handful of modules over and over again anyway.
While I do have to agree with pak about the ugliness (and annoying semantics) of $this->load->thing(), it was something the CI team had to keep around since the framework was already very successful in the wild, and the devs had their backs against the wall to support PHP 4. The Kohana team (or any newer framework) had the benefit of initially not needing to appease anybody when they wanted to build something for pure PHP 5.
Kohana had great beginnings, and I used it to develop a major website owned by NBC. The most annoying part of using it? The documentation was sorely lacking, and class names were inconsistent at best. At least docs are something that can change for the better quickly, but broken docs are something that have persisted through 2.x and 3.x.
Beauty is not something CodeIgniter has going for it. In fact, if you agree with that, you're likely to agree that PHP in general in an ugly language. But CodeIgniter has gained it's loyalty and reputation because of:
1. Speed - It's always at the top of PHP framework benchmarks, and use of minimal resources is ingrained in it's design philosophy
2. Documentation - It has the best documentation of any framework that I've seen or used
3. Principle of Least Astonishment - There is little magic in CodeIgniter, and things in CI only happen because you told CI to do it. Like $this->load->view(). It means more typing, but it's logical, and explicitly stated.
CodeIgniter has a big user-base, and it's weathered time, which is more than other frameworks for the language can say. Now, users are begging the Reactor team to add libraries and helpers to the framework as features. The Reactor team's goal is to keep CI light and fast — the idea is to pack a lot of power in a small footprint.
That's where Sparks comes in. It's not just about easily installable libs (@pan69), it's about keeping the core framework ultra-light and doing what a framework should be doing.
I think sparks is going to help CodeIgniter cement its place as a staple PHP framework, which really doesn't exist for the language. Newer frameworks with snazzier syntax and cool features will always pop up, but the Reactor team plans to make it /the/ primary framework to use for PHP.
I hope they add db migrations soon, the reactor has really breathed life back into the CodeIgniter community. However, I'm still in love with FuelPHP for PHP Frameworks.
This idea for CI is nice, but the video reminded me of one of the more annoying parts of CI: $this->load->whatever()ing everything, which should be rightfully obsoleted for everybody running PHP5 as it is in Kohana, because PHP can autoload classes with your own custom __autoload() function. It's wasted effort to manually load everything and the collisions created in the local namespace are intolerable.