In part one of the series, I wrote about the advantages of CodeIgniter. I will say that there are quite a few. It is a matter of perspective and I don’t want to do CodeIgniter a disservice by not mentioning a few of them. Perhaps you have more and can comment on that post.
What I want to write about now is rebuttals to several messages mentioned on the CodeIgniter site. It is mean to do so, because I get upset when people point out my idiocy on this blog and elsewhere when I wrote something I think is witty. It is humiliating to find otherwise, but I hope they grow a little from the criticism (or probably die a little inside like I do). Addendum: It was mentioned that many of the arguments are “straw men” and thus weaker than I had originally planned. I resolved to edit and clarify certain positions.
Ripping “Who is CodeIgniter for?” Section
I’ll tell you who CodeIgniter is for. CodeIgniter is for those who want to get shit done and don’t care if the framework they are using is shit. Doesn’t mean the end product is going to be shit, you can avoid the more shitty parts of CodeIgniter (which I’ll get into in Part 3). Just means that if your product doesn’t require more advanced features required for open source or professional web application development, then CodeIgniter is for you. Just don’t expect to create WordPress, unless you plan on reimplementing some of the more worthless parts of CodeIgniter.
I forgot to mention that the other parts in the list, I have no problem with. CodeIgniter does have a relatively small footprint. It doesn’t require a lot of configurations, which is nice because it helps to not have to jump through hoops to get started.
- “You need exceptional performance.”
CodeIgniter mentions that it asks for a framework with better performance, I will mention Yii Framework. You could make CodeIgniter faster by requiring the files you need manually. Dynamically loading files does not improve performance. I take issue with the state based on the fact that Yii Framework is faster based on it not dynamically loading every file it needs in the framework.
While it is true that CodeIgniter is faster than the other frameworks it competes with, it is not faster than Yii. Still there are ways to get around performance bottlenecks in any framework. Dynamically loading files negates the advantages of opcode caching like APC, XCache, etc and you can download Yii Framework library that doesn’t use the dynamic loader. (It is unfortunate that the benchmark I link to pretty much fudges the results by offsetting the real world performance and thus, most be taken carefully.)
CodeIgniter probably gets away with reducing overhead through its architecture which violates much of what well written code should be. It is an advantage for performance, but you lose maintainability and extensibility. I think this has been my argument against CodeIgniter, is that it sacrifices, so much for simplicity and perhaps performance if it was planned from the beginning to use anti-patterns in its development.
I could also list many instances where the code is unoptimized for the feature set and could be written to preform better. However, it would be better serve to either submit a patch for those parts or just write my own and learn from those (potential) bottlenecks. I will give it that having less methods and classes is probably giving it a boost over those who use smaller methods and more classes. The speed benefits are minimal and the disadvantages with less extensibility and poor maintainability with larger methods and less classes far outweigh the small performance benefit.
- “You need broad compatibility with standard hosting accounts that run a variety of PHP versions and configurations.”
This should be rewritten as, “You need a framework that works on PHP4.” True, I still don’t put much respect on frameworks and code bases that maintain backwards compatibility with past dead PHP versions. However, there is something to be said with staying the course and making those developers and customers happy that are still on those versions. It is most likely a very good advantage to those who haven’t upgraded their servers or are on servers that haven’t, won’t, or can’t upgrade to PHP5.
The company probably stands behind this statement based on the software they maintain and build. Therefore, while I did put less emphasis on the company and their goal to reach as many potential customers as possible. I might very well be wrong, because they’d be in a better position to ensure that the library runs on more configurations than some of the other open source frameworks who either didn’t realize it doesn’t work or don’t really care about that configuration.
Still, I look at Zend Framework, Yii Framework, and don’t see many configurations that those do not run on. Of course, not everyone is running on a dedicated server with full control over what they have and even those who are have to weight the advantages over changing their server and configurations for a mere framework. Still, code wise, I’m not seeing many configurations that other frameworks won’t run on. Props on the PHP4 support, although, it is holding the framework back in terms of what they can do.
I will mention that the statistics for PHP4 and PHP5 had it about even October of last year (2008) and almost a year later, the adoption of PHP5 should have grown considerably. The emphasis on PHP4 has yet to die, but well, if your customers or users ask for it, it is probably a good choice to use an existing framework instead of rolling out your own to support PHP4.
- “You want a framework that does not require you to adhere to restrictive coding rules.”
I would rather CodeIgniter adhere to strict coding rules like coding standards as to not have to worry about spaces vs tabs, which it uses both. The statement doesn’t make any sense to me as “rules” can be anything. Restrictive coding rules is not defined. What exactly does it mean? Which framework requires that you adhere to strict coding rules when using the framework or class library? This should be a given. A framework should allow me the option to code how I want within the domain of the framework without restricting my design and coding. Any framework that does, probably isn’t going to be used except by the developer that wrote it.
As an addendum, the only frameworks I’ve worked with have been Zend Framework and CodeIgniter, and I’ve only looked at the code bases of the others. I think it is reasonable to restrict controllers for various reasons, as well as models. Every framework is going to have restrictions on directory structure, some more asinine than others. CodeIgniter is definitely one of the less asinine with restrictions on directory structure.
- “You are not interested in large-scale monolithic libraries like PEAR.”
I’m not sure how PEAR has anything to do with a framework. As well as to the statement that PEAR is large-scale and monolithic, that really depends on which library you are using. Some have more features than others and therefore are large-scale and monolithic to fulfill whatever problem the developer had to solve.
PEAR is a repository of class libraries. You can use it or not, or use some classes or others. Some classes do have dependencies which require downloading. The advantage is that PEAR class libraries are usually system wide, meaning you only need to have it once. You do have to set the include path for this to happen and as well, if you have many web applications on your server using CodeIgniter, it is completely possible to include it in the PHP include path as well.
- “You do not want to be forced to learn a templating language…”
The frameworks and class libraries I’ve looked at and worked with do not require learning a templating language, nor do they even include one. Templating languages are a dime a dozen and including, separately, into your project is something that can be done external of the framework.
As an addendum, I have finally discovered MVC frameworks that do include templating engines. However, it is fortunate that they will never be used outside of the original developers.
- “You eschew complexity, favoring simple solutions.”
Yes, if your solution requires simple for the duration of the project, then CodeIgniter is great for your project. I’ll get into the design flaws of CodeIgniter later. Different projects have different needs and complexity. Some solutions aren’t going to need hooks, theming, etc and are just the model, views, controllers, and some helpers and, or libraries. Others that do, are going to find complexity over what other frameworks do. So I mean, the bootstrapping, models, views, database active record, and controllers are simple enough.
The problem is that, you are going to miss out and it seems the developers are geared toward simple in some parts, like the Controller, Model, and Views, but retarded in other less frequently used parts. The hook system is a joke, as well as other architecture mishaps. The hook and plugin system are far from simple in any practical terms. Why should I have to jump through hoops when it is done far better in other systems?
- “You need clear, thorough documentation.”
If you want to know how well documentation can be, then you need to look at the Zend Framework with both the tutorials that covers almost everything you’ll ever want to use the components for. Also it includes a class reference for all the rest of the missing bits not in the user manual. This happens from the strict coding standards which states that all components require inline documentation and DocBook XML describing how to use the component. Most of the professional, group frameworks and class libraries will have well written detailed documentation, both tutorial and class reference.
I will say that some is enough. That said, if you can provide the foundation for people to improve upon (and hopefully contribute back) and get started, then the developers should be able to run with it. The hardest part is knowing where to start and once that is realized it is simple enough to figure out the rest.
Source: CodeIgniter User Guide Start Page.
It is of course partially marketing, because you won’t find many frameworks worth using that don’t have these to some degree. I will also say that I have no problem with the other items in the page. CodeIgniter does in fact live up to those statements.
Edit: There isn’t going to be a third part. It was going to go into the architecture flaws, but meh, my fire for dissing CodeIgniter has died. Perhaps I’ll go back to it after I write my own and show how it should be done (or if the case might be, how it shouldn’t be done). I will contend that implementing anti-patterns in a project is a tragedy that should not be. To do so is to burden the maintainers that come after.
Possibly Related Posts:
- Easier APIs for WordPress
- Libraries Should Use Liberal Licenses
- Why Writing Documentation Wasn’t a Waste of Time
- Contradiction of Good Object-Oriented Design
- WTF Are People Still Writing PHP Template Engines
I’ll give you that codeigniter has some flaws…of course it does. I’ve tried LOTS of frameworks though, for lots of languages, and the reason I chose codeigniter was because of flexibility. I think by “restrictive coding rules” they mean things like naming your databases tables and fields certain ways so that they work well with your chosen framework. This is one of the biggest reasons I use it. I work for webservices at a university. There are HUNDREDS of databases that we use constantly to grab data from other departments that have TERRIBLE design, and no hint of following any standard when developed at all. Most of these databases have live apps hooked up and running off of them, with tons of new data hitting them every day, so it’s not a simple matter of making new databases that aren’t terrible. No, we need a framework that is both simple and easy when things are built right, but flexible enough to let us easily get down to bear metal without putting up a fuss when we have to do something completely unorthodox. Codeigniter has been marvelous for this purpose. Oh…and just so you know, cakephp, an extremely popular php framework, is also php4 compatable, probably for this very reason. I personally dislike cakephp, mostly because it’s query results are just a bunch of nested arrays rather than the objects you would expect from a decent framework, and also because it’s inflexible unless you want to pull teeth. We looked at zend. We decided it’s way to heavy. We are running quite a few web apps for different departments that we develop for, and we couldn’t justify the overhead. That, and zend tends to load way more crap than is necessary if I remember right (I may be confused).
A developer on a project might get by hacking a script together that combines presentation and business logic together just fine. It will be quick, simple, easy to do. The problems come later and that is where I contend CodeIgniter falls short.
I think the problem is that some developers put far too much emphasis on getting shit done, which is fine. If you are coming up against a deadline, doing it the “right” way isn’t in the roadmap. For what it is, it does well, but from the parts I’ve seen and what I’ve would like to use CodeIgniter for, I can not because its architecture does not allow it.
I do not think replacing large parts of a framework is a better use of my time. I’ll rather write my own in the way I would like to see it done than to rewrite parts of an existing one. Sure, I’ll most likely end up spending more time on it, but mine will be far more extensible than CodeIgniter could wish to be.
To answer your question, you can use whatever parts of the Zend Framework you need. If you need the controller, DB, and views (but you can use anything for the views), then that is all you need to use. For example, I have a project only using the controller and some of the security code. That is probably less than a percent of what is in there. Zend Framework does not require loading everything or using everything. You can use one part, 10 parts, or every part (which I doubt). It is more of a class library than a framework though.
The way CodeIgniter returns objects is by casting the arrays to objects. You can do that in any framework that doesn’t do so. Likewise, I believe they get the whole model paradigm wrong. The model can be anything, but they emphasis too much on DB data for the model which is unfortunate. Separation of the code base has its advantages, but only as far as the information is correct.