Welcome Guest, Not a member yet? Register   Sign In
Our reasons to stay away from CodeIgniter 4
#1

Please do not take this the wrong way. We appreciate the efforts that have been made to provide a brand new version of CodeIgniter. It is simply that some design choices make adopting CI4 economically impossible for our company. I originally documented the reasons why that is for our internal info, but later we decided to share our reservations with the community for it might be of value to someone.

After writing commercial applications based upon CI for 13 years we consider ourselves somewhat versed in the topic. So it saddens me personally that I don't have much positive to say about the latest release of my favorite framework.

1. Non-compatibility with CI3 whatsoever
The total disregard for established CI advantages (such as load only what you need) and especially the removal of the Load-Class makes "upgrading" to CI4 very hard. Effectively moving to another framework (e.g. Symfony) would be of equal trouble as "upgrading" to CI4 while I don´t see anything remotely worth making that trade. It goes this far as if we were to change everything that we dislike in CI4 we would end up with something that might have been a CI 3.2 more or less.

2. Less stability / less php compatibility then CI3
It is not a good thing that CI4 has such a narrow range of supported php versions. It is in fact by far less compatible and also less stable than CI3 is. We tried a brew-based MAMP-stack at first and a virgin Ubuntu 20 after that. In both cases CI was not launching before changes were made to the CodeIgniter base classes. In both situations CI3 would come up reliably as expected without any changes even to config files. We are mentioning this as a point of comparison of what we are used to with CI3 and what CI4 painfully lacks.

3.The env file
I personally despise the idea of having configurations outside of PHP files. It is such a step back when you cannot use the full power of the scripting language to make self-adapting directives. I am aware that one does not have to use env but it still bothers me.

4. Compulsory Namespacing
Rasmus Lerdorf famously said that he liked CI because it is "faster, lighter and the least like a framework". This has always been very much a core idea in CI (as far as it concerns Ellis Labs' idea of it) and now being required to namespace everything although PHP does not even require it seems to be pure overhead if you simply do not intend to use namespaces.

5. Abundant infantilism in code commentary
It is very very annoying when working with a new framework to have to wade through a swamp of childish humoristic attempts by inhibited comedians in the code's commentary. This is really not the place to be funny especially when the administrators of the customer will sooner or later stumble upon one or another comment reflecting poorly on us as developers. It is hard enough to defend using CI against more established frameworks as it is and this regression into infantilism is not helping.

6. No Customizer option
In commercial usage it is very common to install a customized product on a client's server as an extension of the base product which in itself remains unchanged to make room for the local configuration as well as possibly required customizations to the code logic and more importantly to stay release capable. In CI3 this was missing, too, but due to the flexibility and extensibility Load-Class this disadvantage was easily remedied. I do not see that CI4 does really take this (at least commercially) very important scenario into consideration even though the directory structure was fundamentally changed.

At this point we stopped trying get along with CI4 since it was not promising a good enough outcome to warrant the necessary man-days to accomplish even a semi satisfactory code base for our needs.

Thanks for your time. Any comments on this are appreciated of course but apart from mutual exchange of view points we do not expect anything remotely eligible for us to continue with CI4 as it is.

Have a nice day anyway and be safe.
Reply
#2

1. As far as I understand, a clean separation was needed to ensure CI4 was feasible and had a future. The incompatibility has been known for a long time.

2. CI4 supports modern PHP versions. Older versions are not maintained or supported by PHP and do not receive security fixes. In the real world I know it's not always possible to have the latest all the time, but using unsupported versions of PHP isn't advised either.

3. Personal preferences, but as you say, it's optional. And using it will helps with (6).

4. Using namespaces will solve the problems you mention in (6).

5. I haven't witnessed this but don't check the CI4 code unless I really need to, and probably wouldn't bother me anyway.

6. See 3+4 Wink


There's nothing forcing you to upgrade to CI4 and you're free to continue using CI3, fork CI3, or move to a different framework entirely.

From my perspective, having worked with CI since version 1, I think CI4 is the natural successor to CI3. Even though it's not a straightforward upgrade, the effort to upgrade will be likely be worth it for most existing CI3 projects I maintain.
Reply
#3

You have valid points but there's probably more constructive ways to try to improve things such as PR requests but for the most part you're right.

We've been a CI 2 and CI 3 shop for 10+ years. Unfortunately it's just waaaay too outdated nowadays and we're almost done converting everything to symfony and laravel apps. I had several conversations with jim a few years ago about how CI4 should have been something more like symfony, as in just set of components we could import, but he insisted on having it as a framework ala Laravel, Symfony.

Unfortunately, as hard as Killishan has worked on CI4, it's just physically impossible to keep up with the bug fixes, feature releases, and general community of a super well funded laravel or symfony.

I've loved CI for what it's been, but at some point people will simply start realizing that there are way better and more efficient ways to create larger applications especially when you have more than a few developers working on it.
Codeigniter is simply one of the tools you need to learn to be a successful developer. Always add more tools to your coding arsenal!
Reply
#4

(This post was last modified: 01-05-2021, 04:43 PM by wdeda.)

1. Non-compatibility with CI3 whatsoever
The world turns, CI4 runs!

2. Less stability / less php compatibility then CI3
It is a matter of vision and, mainly, of direction. CI aims at the future, I do not believe in "Museum of great news".

3.The env file
The 'env' file has a very specific use, among others.. For example, when you enter data via Config and assuming you are part of a team on GitHub, when uploading to GitHub all of that information will be "visible" to team members.
If this information is filled in the 'env' they will not be shared because the 'env' file is listed in the 'gitignore'.

4. Compulsory Namespacing
Think COBOL!

5. Abundant infantilism in code commentary
I believe in freedom of expression.

6. No Customizer option
Be happy, man, there are plenty of other frameworks
Reply
#5

(This post was last modified: 01-05-2021, 05:32 PM by schertt.)

This feels more like a personal outburst than any kind of real criticism, and it seems predicated on the fact that moving from 3 to 4 isn't as simple as dragging and dropping files between installs. 

That idea is admirable but it's just not the case here. The CI framework went through major design changes between these revisions; it sounds curt but that's a part of life in this business. Sometimes it hits the fan and you have to put the work in to adapt. It's not even like it was a surprise; as other users have pointed out, this was known for some time. 

In reality, the amount of work it takes to port code from 3 to 4 isn't overwhelming; it just seems that once people realize there is some work rather than none, it becomes an issue. Truth is, if you actually understand CI3 and are willing to put the time in to learn CI4, it shouldn't be that daunting of a task. 

Obviously a framework that has only been around for a year is going to be less stable than one that's been around for ten. If the issue was purely "stability" then you could stay on CI3; no one here is forcing you to upgrade. In truth I don't know what stability issues you speak of but if you were modifying the framework's system files who knows what problems could have occurred. 

Decrying a lack of PHP compatibility is a nonsensical argument. The oldest minor version of PHP still maintained is 7.3; in other words, the oldest minor version of PHP that you should be using anywhere in production is 7.3. CI4's minimum version is 7.2, which itself is already EOL. Complaining that CI4 can't support earlier versions is to say that you're perfectly fine exposing to the web versions of PHP that have been EOL and vulnerable for 5, 6, 7+ years. Purporting to stand for the average enterprise user but happily accepting these kinds of vulnerabilities is questionable, if not ironic. 

Beyond that it seems mostly opinion (sentences that start with "I personally despise" typically don't contain much objective detail). .Env have a narrow, specific purpose and are not the only way to configure the framework yet you have a personal distaste for them; that's not an issue with the framework. Complaining about namespacing OOPHP code is another dose of irony, coming from an "enterprise" user; that one of the most fundamental OOP practices, especially at the enterprise-level, would be seen as a problem rather than good practice is extremely telling. 

For the record, I've dug through a lot of the CI4 system code since its stable release; I have never found a single comment that was even remotely funny let alone infantile. Sounds more like you just wanted to use that word.
Reply
#6

Well - Superficially jhennike may have some points although it seems to reflect frustration rather than that's the way things are - As someone who first got my hands on in Mini days Vax 11/750 - Prime mini then moved on to micros - then Lisa/Mac's and onto PC's with DOS then Windows - NO software or indeed hardware stands still for long.

I came to Codeigniter looking for a framework to satisfy specific needs without bloat for a Town History archive that had been poorly written with PHP 5.xx - 100+ pages of Spaghetti OOp's that crashed when the hosting moved on to PHP 7.xxx The original developer just walked away leaving us high & dry - Looked at Laravel - Symfony - CakePHP - Zend and CI - decided CI would satisfy requirements - Lightweight Framework, cleaner code, reasonable support available and if properly written able to be passed on to other programmers for updates as time goes by.

Schertt has a valid point,  hanging on to outdated and unsupported versions of PHP is problematic

I personally like .env as its specific to CI4 and easy to manage settings.

Dave Hollingworth's - Codeigniter 4:Build a Complete Web Application from Scratch on UDEMY.COM - a thorough and comprehensive course on CodeIgniter4 is worth a look - Quick to reply to questions if you've signed up.
Reply
#7

Using Codeigniter4 is not Composry it a letter of options and choice!. One man hated food is another man best choice. I really fall in love with this framework. Flexibility and Simplicity.
Reply
#8

(This post was last modified: 01-09-2021, 06:45 AM by MGatner.)

Good discussion here that I’m glad to see happening. I’ll reserve my opinion for now and make what I hope is mostly an objective observation that doesn’t usually get mentioned in the CI3/CI4 conversation...

CodeIgniter 3 went to great lengths to be backwards-compatible with CI2 and make the upgrade process quick and painless. It did a good job of this: I can upgrade old CI2 projects in less than an hour, but it set up the next major version for some difficult choices. Imagine assigning major releases a scaled value (1-10) of “backwards-compatible versus adopting modern practices and new features”, so a 1 would be an easy upgrade with less big adjustments and a 10 would require practically a rewrite but embrace a whole new approach. A theoretical average project might look like this:
v1 5 v2 5 v3 5 v4
We could assign this project an overall difficulty of upgrading from version 1 to version 4 a value of 15, and the theoretical adoption of modern practices and new features a value of 15. Now if you graph CodeIgniter’s history it might be something like:
v1 2 v2 3 v3 _ v4
I’ve made these numbers up, but I’ve also done a lot of CI project upgrades. You can check the docs too for a general idea (https://codeigniter.com/userguide3/insta...ading.html). If you agree with the idea, CodeIgniter is at about a 5 for difficulty & adoption, which is super nice for backwards-compatibility but you can see how it is starting to accumulate some debt on the other end of the spectrum. What’s more, this debt is cumulative so it adds weight onto developers of each next major version.

I left the scale from v3 to v4 empty on purpose. The most consistent criticism I hear of CI4 is (in these terms) that it’s number is too high. I’m curious what participants think that value actually is.
Reply
#9

I love all versions of CI, they are all great with their bugs and improvements, what I see is that CI3 is well documented, but CI4 is created for a Laravel developer or a Sinfony programmer ("correct me if not"), I know that this is an improved version, which uses all the standards, but for programmers who develop over CI3 seeing an almost unknown change is totally different.
Although many will say that it is outdated, I think CI3 is great, has many virtues and for many this statement would be almost funny, but it should be noted that it would be of great importance to give a quick advice guide on how to migrate to CI4.
I propose the following thread to apply to us CI3 users that we must learn to adapt it quickly in an understandable way.
I also propose that the documentation be improved, because if they took the time to perform a framework they should as a minimum create workshops to further understand the CI4.
I speak because I am not an expert in programming, I have an knowledge of the PSR Compliance.
The question to ask would be "if you were a person with no knowledge that you would take to learn how to handle CI4", in a way of understanding how to apply man hours and the use of time that is a limited resource in the real world. To answer this, I leave a thread for you to explain in a simple way to a member who is somewhat lost in these matters.

I apologize to all veterans for everything, but apparently it's not easy for some to go out and drive "composer" that wasn't needed before and fewer servers that are "considered for advanced users". I personally have taken 3 years to learn how to use them and put them into production, both from instance resolution and everything else and it is understood that it is not a simple task, it requires a lot of dysipline to carry it forward and I have learned it to kicks through different situations "of which I have received many criticisms from some colleagues", example: "for you to want a ferrari" and to this day abarato costs in production saving on expensive licenses , but luckily he survived. Adapting requires great sacrifices, it's not something that's really a simple task.

Example in 2013 I was taken on a stretcher by a crisis of hypokalemia caused by overwork, They are geniuses the guys who saved me! in the shock room 1 of the hospital madariaga from Posadas, Misiones, Argentine, learning to manage servers on my side has taken me great sacrifices / (Literally I almost died), but but you finished the second, you do not know of engineering and you learn it by being self-taught, that is why guys it is important to repeat, we all make great sacrifices and we love CI, "technically I have no idea why I like it but I prefer it"

Please helpme to know whats is way more simple to migrate CI3 to CI4 my apps
https://forum.codeigniter.com/thread-78385.html
Reply
#10

Stop crying.

Composer has long been a standard in php development and a couple of hours should be enough for a basic understanding of usage.

The language has not changed. The basic design patterns for CI3 and CI4 are the same.
If you don't understand how CI3 works, then you will have problems understanding CI4.
Wake the f*** up samurai. 2021 year has come.
Reply




Theme © iAndrew 2016 - Forum software by © MyBB