Welcome Guest, Not a member yet? Register   Sign In
Is CI outdated ?

There where times in CI2 that I thought it might be best to look for an alternative to CI. But thankfully CI was turned over to BCIT and steered things the right way.

During that period of doubt I learned that Laraval wasn't the answer (at least not for me). To many changes to the core framework making me have to change the code in my (testing) project more then I'd like.

(This post was last modified: 01-31-2017, 09:14 PM by kilishan.)

Most of the times when I hear people complain about CI being outdated, here's their talking points.

tl;dr: most of them really don't matter. Smile

Doesn't Use Composer

There is such a large number of packages available that can be brought in with Composer that many people think that any framework that isn't built on top of, or at least isn't heavily integrated, with Composer is out-dated. In CI's case, it comes with a configuration element out of the box so that you can place your vendor folder anywhere on your drive that you please and use Composer. Even if it didn't, though, add one line to the index file and you're good to go. Any PHP script can load and create a new class, regardless of framework.

Doesn't have an Auto-loader

By which, they really mean, isn't built on Composer Smile And that's a fair argument, but the method that CI provides, while maybe "older", still works well. People just have a different preference nowadays.

Doesn't have a DI container

This one is absolutely true, and the lack of using a DI is probably the only valid argument people can bring against CI currently. When most people bring this up, it seems to be either because a) they're lazy and like the way the containers do the magic for them and b) they say it makes testing harder. While that can definitely be true, if you're careful with your own coding and use DI there, you can test all night long without a problem. For everything else, kenjis has done a fantastic job of putting together some great testing tools.

$this->model syntax

This one isn't specific to models, of course, but it's the syntax I've seen people complain about the most. Basically, referring to the singleton CI super object, and the whole get_instance() thing. While there might be some merit to these arguments, it goes back to testing, generally, which we've already said is more-or-less non-issue. If proper DI is being used, and something requires a shared instance, then you're passing it in the constructor and saving it as a class property, anyway, which leaves - you guessed it - $this->model, or whatever.

Doesn't support PSR-x

True. Many frameworks don't support all of them. They usually mean the coding styles, I think, which really, really, doesn't matter. Those coding styles are for the framework developers, anyway, to maintain consistent code internally. You're free to do whatever you want in your own code. If you like PSR-2, then use it.


At the end of the day, there's only 2 reasons to use a framework:

- Does it save you time and help you build your application.
- Is it easy/are there enough developers familiar with it that it's worth using.

The second one there is the only real reason I could see might be a knock against your application and selling to a government. If their staff is primarily versed in Ruby/Python/Java/etc, or heavily invested in another framework, they might be resistant. But that's going to happen no matter what your choice is. If you built it in Laravel and they're a Zend or Symfony shop, you've got the same problem.

So - try to sell it. If you keep hitting roadblocks due to the framework in your target market, then maybe consider it. At this point, though, it sounds like your time is better spent selling the product you've built than re-building.

(01-27-2017, 04:45 AM)ajabkalimaha Wrote: But, before doing that, I showed it to my friends. Here are the responses :

The responses you shared sound like follow-the-crowd reactions, not technical analysis. You need the latter, not the former. As others have said, every choice will have pros and cons, you should select the technology that best meets your needs. That includes "performance" (if you can accurately measure it), ease of coding, compliance with any pertinent requirements, etc.

Theme © iAndrew 2016 - Forum software by © MyBB