A while back, an interesting forum topic appeared on the CodeIgniter forums and was brought to my attention via a Reddit thread. It talks about CI adopting some modern PHP features, and shows the “council” and the “CI community” approve of many of them. (I imagine this council as a grove of century-old druids in a magical forest around which the rest of us buzz on highways and jets)
While it’s admirable that CI kind of wants to get into the 202nd decade and join the rest of us, the fact that using features that everyone else already uses needs discussion shows just how much behind the times its community really is.
Collectively, they seem to worry about backwards compatibility when discussing the viability of, for example, Composer and yet the docs and the forums say, on several occasions, that CI4 will differ from CI3 enough to warrant a separate repo, not just a branch. It seems like most people just want to stay out of date for the sake of staying out of date. Do they not realize that changing from CI3 to CI4 would take more time and effort than changing a PHP version from 5.2 to something like 5.6, or even 7?
At this point, it seems like CI4 will be a completely new project with the CI brand just slapped on top, but in my opinion (and the opinion of others), a CodeIgniter brand on top of anything just screams outdatedness and a blatant disconnect from reality. I mean, they’re on the fence about dependency injection - to them, it seems like a cool idea that might remove the need for the CI super-object (also known as the living demonstration of breaking of all five SOLID principles).
In a world where we have proper frameworks that endorse separation of framework and logic, what possible reason could someone have for using CI in a new project and just enslaving their app with the super object and all its other quirks? Why would one willingly enter an ecosystem which actively refuses modern features that make coding easier, more secure, and more pleasant for everyone involved? That would be like starting a new blog project on something like WordPress… oh wait…
Anyway, how do you feel about this? Do you agree or disagree with my disapproval of CI and its attempts at progress? Let me know.
Change is always hard, when the reasons for change aren’t clearly evident. Everyone will agree to that.
However, acceptance of best practices and agreed upon principles should be a no brainer for any developer. And more importantly, this acceptance is for the greater good of the overall developer community (in this case the PHP devleoper community).
Though, there are people, who like to fight the status-quo for the sake of protecting themselves from change. This is the totally wrong reason to fight the status-quo or to not accept the gathered intelligence of the community. In fact, I’d consider it complete ignorance and very close to the edge of stupidity. I’d also say clear “mistakes” should never be made twice. So, yes. You are definitely correct to have the perspective on CI’s “stagnated” development.
CI was kick ass. Could it be kick ass again? For sure!
One of the reasons PHP is so popular is because it’s easy to get into. You can bash new developers all day long and drill on about best practices, TTD etc but at the end of the day it puts up a barrier. The harder it is for new developers to get on board the smaller are numbers will become. PHP needs to be easy and accessible. If CI can offer a bridge for next generation then so be it.
Unwillingness to adapt to the times is the path to being obsolete. it seems far to often that stake holders and communities forget that. Though I myself believe old projects like CI are just about dead with evolution of dependency management (composer) in the php ecosystem.
It seems funny to me that the original creators of CI are pulling it from the next version of their flagship CMS, ExpressionEngine (at least, that’s my understanding). A welcome development, imho.
I have been a fan of CodeIgniter since about 2007 and still like the framework. It does what it says on the tin; “a powerful PHP framework with a very small footprint, built for developers who need a simple and elegant toolkit to create full-featured web applications.”
I have used Yii, FuelPhp, Laravel and also tried a couple of others. Most recent was the Silex installation. The mind boggles, over 40 megs to upload (on my very slow connection), CodeIgniter is 4 megs including the excellent documentation file
Is it really necessary to have feature-creep on the modern frameworks that now need Composer to track updates? On average just how many features do developers actually use and would it not be beneficial to have these features available as optional modules?
If upload time is your bottleneck, then Composer may actually be a huge help. You wouldn’t need to upload the framework at all, nor any other third party libraries. You would only need to upload the src files that you personally wrote and your composer file. Then from your server’s shell, you can run composer install, and the server will use its own internet connection to download the third party libraries, including the framework itself.
What you failed to mention was that the forum topic was written by James Parry, Project leader. I think it was very sensible to request and discuss ideas from experienced programmers as to what would be beneficial for the next CodeIgninter version.
I read the topic and did not see your post?
Why introduce a separate rant that does not help the original poster’s request?
Many thanks for the advice, I have managed without Composer for a long time and do not appreciate the benefits. I look forward to trying your recommendations.
If you’re using CI, then that makes sense. Admittedly, the primary benefits of Composer don’t appear unless your project cross-pollinates.
It used to be that every framework was an island with little or no shared code, and everything had to be re-implemented just for that framework, even the basics such as caching and logging. (CI largely works this way.) But today, it’s more common for frameworks, libraries and applications to use library code from a variety of other projects, such as Symfony, Zend, Doctrine, Monolog, Twig, Guzzle, and many others.
But this adds a new complication. If my project depends on projects A and B, and A relies on C and D, and C relies on E, F and G, and so on, then the dependency chains can get complex. Trying to manually track, download, and install every dependency can be tedious. Trying to watch every dependency’s project for bugfix updates is even more tedious. This is the primary problem that Composer solves. With Composer, you only need to specify the projects that you directly depend on, then Composer computes the complete dependency chain and makes sure you have everything you need. Then at some later time, you can run composer update and it can fetch all the bugfixes or feature updates for every one of those dependencies.
From what I can see, they are only removing references to CI from the code. EE3 is still built on what was CI at one stage. Just curious as to why you think this is a welcome development? And what issues have arisen because it is based on CI?
It’s felt to me like CI has been fading over the years, and I wasn’t too happy that a CMS that I use a lot (or was using) was built on a code base that the company itself was iffy about. I don’t really know what they are doing with EE now, but my impression was that they were going to gradually modify the code they have but break it way from CI and let it morph into whatever they need. I could be wrong, though.
No that’s fair enough. Was just curious as to why you thought it was a good thing. It appears to be doing what you say already, it is morphing into EllisLabs vision of what a CMS framework should be and they are unbound from any underlying PHP framework.
Because I don’t think it would make a dent. If the arguments I outline in my original post don’t make implicit sense to the project owner / leader and the community and the council, there’s little I can say to persuade them otherwise. From experience, projects that have old school protectors (like WordPress) are resistant to change for the sake of resistance, much like with religion - like I say in the first post, upgrading from CI3 to CI4 will be much more trouble than upgrading a PHP version, and yet it’s still up for discussion whether or not Composer should be added into the mix. To me, that’s folly, and my lone crusading against the druids would be met with a quick exile from the Ancient Forest that is the CI forums.
I opted for this approach instead where rather than ranting on a ground that is holy to those I’m ranting against, I ranted on neutral terrain where more objective feedback can be given by different parties with zero actual involvement with the project’s internal development. I believe such an approach will, in the end, yield far more productive and concrete arguments for upgrading anything and everything than a discussion on the CI forums ever could.
Another reason is my intolerance of forums in general - having to deal with Discourse is nightmare enough, wading through MyBB of a project I’m not really interested in (but would like to see upgraded for the sake of everyone else) would be too much work.
That said, I could have posted the link to this topic in their forums, yes. Dropped the ball there, thanks for jumping in.
After reading that thread, it is quite clear to me, as an outsider, a true and heartfelt attempt to make a great CI4 simply isn’t there or rather, jlp isn’t the right leader for them.
I mean, he did nothing really to show what the vision really is. The couple of things he noted are what any modern programmer would expect from a framework today. The fact he lists none of the community wishes CI4 will try to fulfill, shows he has no willingness or eagerness to build up excitement. His answer shows, there is no vision and leadership. That is, from my perspective, a pretty clear cause for the “decay”.
Yes, silence about the vision, until a vision could actually be produced, probably would have been the better alternative.
In end effect, he turns it around on the users to basically say, “asking for a vision is pretty much a stupid effort. Your asking for too much with too little information available. But, we’ll get you straightened out in the end.”
Many thanks for your verbose reply and I must agree with all the points mentioned especially since it has produced many explicit arguments for consideration.
I like their basic proposal and looking forward to the new version.
