Thread

What are the advantages of Codeigniter against frameworks as of zend, cakephp, and symphony?
i need some opinion !!!! 😊 thanks

IMO, the simplicity of CodeIgniter is one of the most advantages when compare to other frameworks. It helps us easy to learn, extend,...

Thanks I appreciate your opinion

These are the factors why I used CodeIgniter.

1. Simplicity - Very easy to use (This is the right framework it simplify things not complicate)
2. Documentation - Very very nice documentation.
3. No commercialism - It’s 100% free and they don’t offer to force you to buy products/services. (Unlike Zend Framework)
4. Massive community - Really…
5. Tons of resources
7. Very popular
8. Very stable framework

I will tell you… I almost tried all the framework.
Zend, Symfony, Cakephp etc…

But only CodeIgniter makes me happy 😊

i also tried laravel and joomla. but nothing beats Codeigniter for simplicity robustness. The documentation is so straightforward.

As always, it’s about picking the right tool for the job, considering the person holding the tool…

CodeIgniter is simple, easy to learn, easy to understand, well documented, and reasonably well suited for beginners and the simple work. It’s been around for dogs years, and hardly changed in that time, so there’s a lot of info around.

CodeIgniter is crap if you want to make something big, complex, modular and extendable. And in terms of evolution it’s stuck in PHP4 days, and dead (as any work to modernize it will not make it CodeIgniter anymore).

Having “tons” of external stuff just makes it worse, it increases the complexity, things don’t work together, and before you know it you’re extending half the core. Which makes the end result bloated, big, slow and impossible to maintain.

ymmv, see line 1… 😉

@WanWizard
Are you still using CodeIgniter dude?
I use WireDesign HVMC that is why I’m still loving CodeIgniter.

I’m thinking to use FuelPHP or Laravel.

No, not for application development. We still have a few Pyro based sites that we maintain, but nothing new anymore.

We switched more then two years ago, because we’re into “big, modular and complex” (we do corporate applications, not public websites), and CI simply didn’t cut it. Since we’ve switched (to Fuel) our productivity nearly doubled, applications are faster and use less memory, and with namespacing and modules/packages there’s a lot more separation and reusablility.

HMVC is one of those typical “bolted-on” solutions in CI, that only makes things more complex, replaces a fare chunk of the core (and thus collides with other stuff that has to do the same). And it isn’t proper HMVC, as it doesn’t isolate the request. It can’t, because everything is CI is global (an HMVC call for example should have it’s own HTTP request, HTTP method and Input).

@WanLizard,

Once again your understanding of the HMVC design pattern fails you.

HMVC has nothing to do with the Http request or response objects in web applications. Isolation of the request is irrelevant and I believe you just made that up.

HMVC concerns itself only with delegation of responsibilty. Routing or “Forwarding” to the appropriate controller is all that is required to facilitate the HMVC design pattern.

I was waiting for you to appear, did I step on your toes again? Did I offend you, Or your precious piece of code?
Good to see you haven’t changed, and still remain predicable. There are still certainties in life.

@WanLizard,

You’ve only offended people who might expect more from you.

It’s a pity you can’t offer facts to support your original diatribe and sad that you choose to attack me personally.

I would have preferred that you defend your comment about “Isolating the request” in terms of HMVC and showed everyone how clever you really are.

CodeIgniter is crap if you want to make something big, complex, modular and extendable. And in terms of evolution it’s stuck in PHP4 days, and dead (as any work to modernize it will not make it CodeIgniter anymore).

Can you give an example of a design pattern you were unable to build with CI? I’ve only recently started using CI and found it easy to setup a controller inheritance chain. If I need bulk functionality shared between different tiers I use a library and for one-off functions you can use helpers. Unlike most frameworks CI stays out of my way when I want it to, a big plus in my opinion.

I think the PHP 5.3+ hype is blown way out of proportion. I’ve been developing with PHP for over 15y and I’ve never run into a situation I couldn’t solve because of language constraints. Anyone who jumps frameworks because of a language version barrier is either living on the bleeding edge (maybe 1% of devs are actually there) and have very niche use cases for their app, or they don’t understand the problem they are trying to solve well enough (the other 99%) and think a new version/framework will make it easier. It won’t.

We switched more then two years ago, because we’re into “big, modular and complex” (we do corporate applications, not public websites), and CI simply didn’t cut it. Since we’ve switched (to Fuel) our productivity nearly doubled, applications are faster and use less memory, and with namespacing and modules/packages there’s a lot more separation and reusablility.

HMVC is one of those typical “bolted-on” solutions in CI, that only makes things more complex, replaces a fare chunk of the core (and thus collides with other stuff that has to do the same). And it isn’t proper HMVC, as it doesn’t isolate the request. It can’t, because everything is CI is global (an HMVC call for example should have it’s own HTTP request, HTTP method and Input).

I’ll give you name-spacing, but I don’t understand your second point. If you are “bolting on” an HMVC addition, and editing the core (never a good idea in any framework), then complaining about code you wrote… how is that the frameworks fault?

Having “tons” of external stuff just makes it worse, it increases the complexity, things don’t work together, and before you know it you’re extending half the core. Which makes the end result bloated, big, slow and impossible to maintain.

It sounds to me like your app fell into a trap that a lot of large projects do. Without someone managing code quality, steering the ship and rejecting the barnacles, you end up with a house of cards waiting to collapse upon itself. To defend the pile of hacks layered on top of one another, someone is quick to call out the framework as the problem. You build it again, this time with all the foresight you gained building it the first time, and reaffirm that belief.

Was the framework really the problem? Maybe, but probably not. It is more likely that the developers were short sighted and didn’t stop to think about the maintenance nightmare they were building under the guise of saving time in the short term. In the long term it always costs you and usually ends in a rebuild of the entire app.

—-

@luisvallin My suggestion is try as many frameworks as you can and select the best fit for your task. Every framework is different and has it’s own strengths and weaknesses. There isn’t one golden framework that solves every problem and there never will be.

What I like about CI:
- Doesn’t try to be an all-in-one solution
- Very little bloat, only load what you need
- Easy to extend
- Doesn’t force any design patterns on your app
- Great documentation
- Great community

One of the joys of IT is it never stops changing. The framework you develop on today is not the framework you will be using in 5y and is one of 10+ more that you will learn throughout your career. Pick one that helps you solve your current problem and you enjoy working with. Don’t worry about what everyone else is doing, your problem is not theirs, and every problem requires it’s own solution. And most importantly, have fun while you do it!

I didn’t say there is something you can not build with CI. In the end it’s PHP.

As everything, it depends on where you stand. For me it’s easy, my developers cost money, so the faster they are, the more profit I make and/or the more competitive my business is. So for me it’s not a question of “can I make it with CI”, but “is CI the most efficient tool for the job?”. Which might (and probably is) different for me then it is for you, hence my “ymmv” in my first reaction.

My point about external libraries (the “bolting on”) is that I have to (either 3rd party or self-made), because of the fact that the core (again, for me) lacks functionality. And with that process (trying to make CI work for me) comes the complexity of each of these libraries wanting to alter the core. No, not editing, extending. But if you have your 4th library that wants to extend the Loader class, you really are in deep dodo, especially if they extend the same methods, but with conflicting functionality.

I never said that that is the frameworks fault. The framework (CI in this case) is a specific tool, for a specific job. And my job requires a different tool.

Yes, the framework was the problem. Just because you couldn’t separate, modularize and abstract out of the box, because we had to come up with clumsy ways to deal with class name collisions, because of the global scope of the entire framework with all it’s singletons, the list goes on, we ended up with a monolith that was unmaintainable and slow. In the end we decided to ditch over a year of work, and restarted, with a better tool for this particular job.

Having run software development projects for almost 30 years now, I think I have some idea of how it works, and what doesn’t. (like for example 1000 man-day project, using the waterfall method, like it was common in the 80’s and 90’s 😊).

Again, that might not be an issue for you, or the TS. Your final suggestion was the same as mine: find the right tool for the job, taking into consideration the person holding it. 😉

I didn’t say there is something you can not build with CI. In the end it’s PHP.

Then why making sweeping generalizations like “It’s dead” in a thread asking for advantages of CI over others? Surely as someone had been using it for a number of years you can provide a less bias opinion then that.

As everything, it depends on where you stand. For me it’s easy, my developers cost money, so the faster they are, the more profit I make and/or the more competitive my business is. So for me it’s not a question of “can I make it with CI”, but “is CI the most efficient tool for the job?”. Which might (and probably is) different for me then it is for you, hence my “ymmv” in my first reaction.

Out of curiosity are you a developer or do you manage a team of developers?

My point about external libraries (the “bolting on”) is that I have to (either 3rd party or self-made), because of the fact that the core (again, for me) lacks functionality. And with that process (trying to make CI work for me) comes the complexity of each of these libraries wanting to alter the core. No, not editing, extending. But if you have your 4th library that wants to extend the Loader class, you really are in deep dodo, especially if they extend the same methods, but with conflicting functionality.

I’d seriously question any dev who thinks using multiple libraries from different authors all attempting to modify one set of functionality is a good idea. Why wouldn’t you just write the code yourself, or at least a bridge to manage cross talk, and save yourself the headache in the long run? Yes it’s faster up front, but maintaining that mess will cost you way more in the long term.

I never said that that is the frameworks fault. The framework (CI in this case) is a specific tool, for a specific job. And my job requires a different tool.

Then perhaps offer an objective opinion with examples instead of bashing it and other posters?

Yes, the framework was the problem. Just because you couldn’t separate, modularize and abstract out of the box, because we had to come up with clumsy ways to deal with class name collisions, because of the global scope of the entire framework with all it’s singletons, the list goes on, we ended up with a monolith that was unmaintainable and slow. In the end we decided to ditch over a year of work, and restarted, with a better tool for this particular job.

I disagree. I’d say whoever’s job it was to manage scope creep failed miserably and should be fired for letting a years worth of work go to waste. The developer should have seen it, unless they really didn’t know what they were doing, if they did they wouldn’t need to layer on external libraries like that. Or would at least know going down that path was the wrong decision and would ask for help from the team. Talk about cutting corners to the limit.

Again, that might not be an issue for you, or the TS. Your final suggestion was the same as mine: find the right tool for the job, taking into consideration the person holding it. 😉

Then why hate on for CI? I’m guessing one of your dev’s burned you and somehow managed to convince you that CI was the problem when really they were talking out of their behind.