Say No to Composer!

1. Although I like the idea of help managing libraries, the implementation of Composer adds extra work which, in many cases, ends up costing more time than just managing your libraries.

While it took me a little while to figure out what I was doing in my composer.json file, I really haven't had to do much in the way of extra work and time since then. For the most part, a framework could reduce or eliminate the need for extra work on the part of its users by supplying a default composer.json which configures autoloading classes based on the framework's conventions.

2. I do not like the "disconnect" that happens with Composer.  One of my main reasons for using CodeIgniter is that it keeps you in touch with the code, and "install" just means placing code where you need it.  With Composer, there is a black-box sensation, where you install software and lose track of what's running on your application.

This doesn't really make sense to me, unless you're dealing with libraries which have a lot of their own dependencies, all of which are being managed by Composer. Another possibility I could see might be the "files" option to load files for every request in the composer autoload configuration, but that's as visible to users of Composer as the autoload configuration in CodeIgniter.

In any case, what's running on your application when you use Composer is exactly what you tell it to load, plus any dependencies for whatever you loaded. In CI's loader, you're calling $this->load->{class_type}('class_name'), and it's hiding the instantiation of the class (and potentially loading a config file, if it's a library, or possibly loading the db library if it's a model). When using Composer, you just instantiate the class, instead, and it loads the class (and its dependencies).

Having written a little code which permits loading some Composer-oriented libraries when Composer isn't present, there certainly is a tendency (in some cases) towards using more files, and it can make loading the same classes without Composer (or some other dependency manager) painful, but using more files for a library and managing the loading of dependencies is only going to cause you to lose track of what's running in your application if you choose to ignore the library's dependencies (which are clearly defined in that library's composer.json file).

3. I am pretty confident that 5 years from now the development community will be done with Composer, just as we are now done with PEAR.  I've been coding for 25 years, and Composer feels to me like so many "breakthroughs" that are not destined to last.

While I've only been coding for 19 years, I don't believe that this trend is really going anywhere, regardless of whether Composer itself sticks around. After all, package/dependency managers are common in many operating systems and programming languages (e.g. NuGet, npm/Bower, RubyGems, Maven, Apt, etc.), and solve a number of very real problems which currently have no other viable solution (other than spending your time manually managing your dependencies, which will tend to reduce them, even if you don't explicitly work towards that goal).

Bonfire

Practical CodeIgniter 3
CodeIgniter Testing Guide