Is CodeIgniter any good?

[woolyg]

I'm looking at getting my head into it, but sort of evaluating whether I'm better off just doing the lug work and writing the code myself.

 

Does anyone here reckon it's super-duper?

Does it have any major drawbacks?

 

Opinions please!

WoolyG

[sunwukung]

the value of using a pre-built framework

 

a) common standard that can be shared between developers

b) code you write can be picked up easier by subsequent developers

c) documentation is better

d) good quality components already available

e) component have been tested in superior number of projects

f) access to community with common knowledge

g) learn a great deal about application architecture by studying someone else's work

 

disadvantages:

a) learning curve

b) can be rather bloated for task at hand

c) different frameworks excel at different types of application - but you won't know that until you've used them for a while

d) can be tricky to implement AJAX functionality at first pass

 

 

The only real value in writing your own is that

a) you learn a lot from doing so

b) the framework you write may be a lot more lightweight since it is custom built for your way of working

c) it does something that no other framework does

 

However, as your homebrew gets bigger, you will find yourself maintaining that code over time too.

[woolyg]

That's an excellent synopsis, sunwukung - thanks.

 

I'll be looking to incorporate scriptaculous JS framework too, can anyone tell me if codeigniter has an issue with it?

[RIRedinPA]

I've started using it and though I wouldn't call myself the greatest programmer ever I have enough coding experience to hold my own. The two frustrating parts for me where getting my head wrapped around the MVC model...I'm still not entirely sold on the necessity of a framework/MVC model over rolling your own but it's the trend du joer in development these days and if the people want cake then you give it to them...so as much as I love writing my own code padding the skills and resume with some frameworks doesn't hurt.

 

The other thing that has annoyed me is having to learn in essence a kind of sub language of the language you already know. It hasn't been that big a hill to climb but my head can only hold so much and since I am whining I'm throwing it in... : D

 

On the plus side for CI is that it doesn't care if you're running a database or not, so you could build just a VC style site without the models, you could even build just a VC site even if you're using a db. It's also, IMO, a simpler MVC package, easier to install than Cake or Zend was and is, how to word it, much more bare bones PHP, less of a sub language (which are really just functions/methods and understanding how to pass data to them).

 

It's a good starting point for using a framework and jquery meshes nicely with it. I would recommend starting here first before venturing into Cake or Zend or something else, you might never have to leave. But if you want/need more complexity then you won't be venturing into either of those apps blindly, which can be frustrating.

 

As for documentation, CI's is ok, better than others but I would love to see more tutorials (links please if they are out there).

 

HTH

 

 

[ShoeLace1291]

I have to disagree with sunwukung.  All of the advantages you listed are also advantages that you have with plain old php.  Except for points d and f(f not so much because there are alot of php communities out there, including this one), frameworks and barebone php share all of these advantages.

 

One huge disadvantage is that if you ever want to go back to plain php, say to help with a project that doesn't involve code igniter, it will take some time to get used to not working with controllers, models, views, libraries, plugins, etc.

 

However, I do agree with the disadvantages that he listed.  As I stated above, it is a learning curve as he had put it.  Even though it may get simple database and even file oriented applications finished quickly, there are restrictions to it that may keep you from using your full programming potential. 

 

Summary:  If you know CodeIgniter completely, inside and out, yes, it is a good thing to learn because it will help turn multi-month projects into a project that will only last a few weeks, depending on how much free time you have

[woolyg]

Good input, Hybrid. Thanks for that. I'm tiptoeing around the possibility of getting into it. I like the MVC model, and I have a feeling it will take the bulk out of my usual way of coding. I'm definitely going to read a bit more into it.

WoolyG

[keevitaja]

i have been playing around with it couple days and it looks great. learning curve isn't hard at all! there are lot of tutorials linked in the wiki!

[petroz]

Once you know CI, the biggest tradeoff is the time required to complete projects, and the MVC makes alot of code very reusable unlike most plain PHP work.

[pkphp]

i prefer cakephp cause it is based on the ROR's Design pattern.

[trq]

i prefer cakephp cause it is based on the ROR's Design pattern.

Ruby on Rails is NOT a design pattern.

[ignace]

i prefer cakephp cause it is based on the ROR's Design pattern.

 

CakePHP is sloooowwwwwwwwwwwwwwwwww.

[matildaronald2010]

I agree that cakephp cause it is based on the ROR's Design pattern.

[trq]

I agree that cakephp cause it is based on the ROR's Design pattern.

 

Are you on crack?

[petroz]

I agree that cakephp cause it is based on the ROR's Design pattern.

 

Are you on crack?

 

LOL... Seriously! What is a ROR design pattern? Please enlighten us!

 

[sKunKbad]

I use CodeIgniter, and have for a little over a year. It has really helped clean up my code, which used to be a bunch of procedural garbage. I didn't have a lot of experience with OOP before using CodeIgniter and Kohana, and I suppose OOP alone could have helped me clean up my code, but OOP was hard for me to grasp without having a reason, and the two PHP frameworks I mentioned are both a bunch of OOP, so my reason for using a lot more OOP was to learn the frameworks. MVC also helps organize my code, which may not be the reason for MVC, but it sure does make things more organized. Another thing that helped clean up my code is that I decided to follow CodeIgniter's Style Guide. The Style Guide is here:

 

http://codeigniter.com/user_guide/general/styleguide.html

 

One thing that I like about frameworks is that other people are constantly looking at the framework, finding bugs that get fixed, finding security issues that get fixed, etc. If I was to make my own "framework", then who will fix my bugs and security issues? Me. Well, me if I find them.

 

I will say that because I've been using frameworks for all my projects, some standard PHP knowledge of mine has sort of been tossed in the trash. For instance, all of the mysql db connection stuff, as well as queries, updates, inserts, etc. have now been replaced by Active Record and a config file.

 

I could babble on for a while about CodeIgniter and my experience with frameworks. I think for super small projects I would not use CodeIgniter, but I use it for almost everything. It is good and supposedly one of the fastest frameworks.

[gizmola]

I agree that cakephp cause it is based on the ROR's Design pattern.

 

The framework that is the most like Ruby on Rails (and I must agree strongly that it is not a design pattern) is Symfony.  The team that put symfony together did so largely as a way of emulating what they liked about RoR, only using various pieces of projects they found available in the PHP world.

 

One part of RoR that is a design pattern is "Active Record" and often when people talk about what is good about RoR, they are talking about "code generation" using database introspection and RoR's implementation of "Active Record".  Well, quite frankly, nearly every framework has some form of "Object relational manager" for working with the database.  Symfony has these same features in terms of comes with integrated MVC, ORM and code generation to build the ORM mapping classes and generate CRUD.

 

You can debate the strengths and weaknesses of the various PHP ORM's plenty.  When RoR came out, Ruby didn't have ORM options, so "Active Record" was a big step forward.  PHP has several ORM's to choose from.  Java advocates will be happy to tell you that in terms of ORM's Java was way ahead of Ruby and PHP, and often the ORM's in these languages are ports or copies of a well known Java ORM's.  There are actually a fair number of PHP ORM's right now, with the two best known being Propel and Doctrine.  If you take a look at Symfony, while they started with Propel support, they quickly added support for Doctrine.  This is a trend (decoupling the ORM from the rest of the framework) that even has been adopted by the Ruby on Rails people.

 

I find myself being somewhat dogmatic about this, but I just don't like any of the circa PHP 4 frameworks.  Kudos to them for being forward thinking in the days when PHP oop was garbage, but CI, CakePHP etc, were all written in PHP4 days, and while they may have gotten cosmetic upgrades, are still PHP4 for the most part.  In some cases, the ORM choice does not work for everyone, and some of the frameworks were only written to their ORM choice, whether that be an integration or a custom built ORM. 

 

Of course there is nothing preventing you from writing nice clean PHP5 classes on top of them, but I'm not impressed with the claims of "hey this is so much faster because we have lean high performance implementation" when what they really mean is that their framework isn't oop, and hasn't been rewritten from the days when everything in a php4 class was public, and you couldn't use object access syntax embedded objects, and PHP made a copy of the object when you did new() or a simple assignment.  .

 

I had a gallery plugin that was highly used in the Joomla 1.0 days.  When Joomla 1.5 was released it was no longer compatible -- and since neither I nor anyone else with the project was interested in investing the time to do the extensive rewriting needed to make it work with the significant API and structural changes for 1.5, that project is now kaput.  And I would be the first to say that it needed to go away, and be replaced by a project that was coded to these new standards.  Some of these ancient PHP frameworks probably should also ride off in the sunset, but the adherents, who won't take the steps to redo them other than bandaid them, are quick to defend them hiding behind spurious performance claims, using benchmarks that are atypical to the extreme, and really besides the point.  It's easy enough to research the frameworks and take a look at the code you write and ask yourself if on a longer term project, where you forsee yourself doing extensive customization and enhancement, whether or not that framework is structured in a way that the investment will result in robust software that will be maintainable and bug free.  Often I believe that what people gravitate towards in some of the older frameworks is their surface level simplicity.  They're struggling just with how you get started, and something like symfony or Zend framework is daunting to them, because there's a larger investment in time required.  I worked with a guy on a project where he had a prototype of it and it was just a mess, and I suggested we rewrite it in a framework, so I did a quickie zf version of it.  He was intimidated by ZF, and so he rewrote it in Cakephp, which was fine for the superficial issues that I'd enumerated, but then when we got into some of the things that he actually needed to do to really solve his business problems, not only was there no documented CakePHP solution, but he was actually having to go in and hack the framework itself, and after a bit I finally said.. this is why I didn't use CakePHP from the get-go.  But to him, he was wedded to it, despite the fact that it wasn't really a good platform for him to build upon, simply because he didn't want to learn something he saw as more complicated, purely because he didn't really understand OOP or design patterns enough to see a difference.

 

On another project, there was an app that was again a complete mess, with everyone agreeing that it was unmaintainable, needed an MVC badly, as well as a lot of other structure, and features to get it ready for market.  As I was one of the first people to bring this up and say.. ya know we could shoehorn in ZF here, and then I went and actually did some proof of concepts, and implemented a required feature using a ZF class, I found that there was a number of other engineers, all of which from my point of view were the most knowledgeable and productive who agreed that ZF made sense, especially because it could be used ala carte and have things migrated in piece by piece rather than having to do a big bang conversion. 

 

Then there was a long really annoying debate with some of the least productive people complaining about how "big" ZF was, and how other frameworks were "faster" even after I repeatedly pointed out that just because ZF has classes to do all sorts of things that the other frameworks didn't and that this didn't matter at all because we would include exactly what we needed and nothing more, I eventually lost the will to continually defend my position.  Eventually people began to write their own version of an MVC and config classes and other crap that was easily available in ZF with unit tested code of decent quality, rather than stuff that did 1/10th of what we could have had from ZF without us writing any code.  I had even done a view class and pointed out that it had functionality out of the box to support customizable templates, along with a proof of concept.  I then had to again endure discussions of how ZF was too heavy and they heard that CI was much faster, even though nobody would ever get off the dime and actually do a version of any of the apps or modules in CI.  Ironically, i went on to find other ways to invest my time other than work on that project, and now that some months have gone on now, they still have yet to implement the customizable templates that supposedly were a must have for customers.

 

There's nothing worse than working with people who naysay solutions that provide flexibility and good functional design, and set people up to succeed, all in the name of "that's going to be too slow."  These same people never ever profile code, and are almost inevitably are completely wrong about all their assumptions in regards to the eventual bottlenecks of the application.  They do manage to be incredibly successful at building really crappy and limited applications that can't be enhanced because they were designed in really convoluted and limited ways, all in the name of "good performance".

 

I'd opt any day for a framework that has really embraced oop and implemented design patterns, rather than one that is antiquated, and has limited support for PHP5 oop.  I've worked on some really large (large number of simultaneous users) applications and scalability is a lot more complicated than an mvc, and typically the frameworks that argue that they are "faster" do so, because they're very limited, and work great for simple applications but leave people flailing once they realize that there's no flexibility to them.