Say No to Composer! - Printable Version +- CodeIgniter Forums (https://forum.codeigniter.com) +-- Forum: CodeIgniter 4 (https://forum.codeigniter.com/forumdisplay.php?fid=28) +--- Forum: CodeIgniter 4 Feature Requests (https://forum.codeigniter.com/forumdisplay.php?fid=29) +--- Thread: Say No to Composer! (/showthread.php?tid=62108) |
Say No to Composer! - MatthewSchenker - 06-10-2015 Greetings, I'm very happy to see all the great CodeIgniter developments and discussions, and I am confident about the framework's future. Which brings me to my point. Please, let's not go down the Composer road with CodeIgniter. Here's my reasoning... 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. 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. 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. Of course, I may be completely wrong about everything! But I just wanted to put this out there and hear what others have to say. Thanks, Matthew RE: Say No to Composer! - sv3tli0 - 06-10-2015 At the moment composer is massive used so it should be supported so that CodeIgniter is easy for use by developers. Of course this shouldn't be 100% required as always there should be an stand alone version which doesn't need composer. In 2-5 years there will be newer versions of CI and if at that point composer is not used any more it can be fully removed. RE: Say No to Composer! - mwhitney - 06-10-2015 (06-10-2015, 07:40 AM)MatthewSchenker Wrote: 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. Quote: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). Quote: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). RE: Say No to Composer! - ivantcholakov - 06-10-2015 @MatthewSchenker Just saying "No" is the easiest thing. Is there something positive you can propose? You wrote "I am confident about the framework's future.". Ok, but do you see any details about this future? Or just CodeIgniter 3 is perfect for you? ------------------------------------------------------ There are two major problems to be solved: 1. CodeIgniter must recognize that PHP has true class autoloading feature. Its benefit about human productivity is obvious. How to be implemented? Not in the way Kohana tried in the past, they have invented their own autoloading system. Where is Kohana now? Composer gives a de-facto standard. ZF3, Laravel, Symfony use it. You say "I am pretty confident that 5 years from now the development community will be done with Composer". What is the ground of your prediction? The analogy with PEAR is a quite weak argument. How the guys that have invested too much efforts will say "we don't like Composer" just like that? 2. The "God object" pattern - this is another topic. Here is my alternative prediction: CodeIgniter will have its future if it has the desire to address at least these two key problems. The ground of this prediction is what competition achieves. They get improved, we think and talk too much about trivial things. PS: For achieving autoloading, if somebody finds a way to trick $this->load->lang('language_file'); he/she will be the master of the Universe. :-) RE: Say No to Composer! - MatthewSchenker - 06-10-2015 Hi ivantcholakov, I understand what you're saying. Of course, I think CodeIgniter needs to move forward. My point is more specifically about Composer. I just don't like what I see there, both with Composer itself and the general idea of key pieces of our applications being magically managed. You cite Laravel and Zend. Both of those are, for me, proof of the problem. In a short time, Laravel has become a bloated monster with all kinds of magic going on. It's starting to look a bit like Drupal. I'm sort of kidding, but not really. OK, I acknowledge that the future will include package management, but I don't think Composer is the solution that will last. And no, I have no simple way to prove this. As I mentioned above, I admit I could be totally wrong here. Thanks, Matthew RE: Say No to Composer! - kenjis - 06-10-2015 What do you mean by `magic` or `magically managed`? I don't get what is magic. RE: Say No to Composer! - ivantcholakov - 06-10-2015 @MatthewSchenker Sharing a hunch is not bad, sometimes decisions are made on this basis. To prove something is often hard and expensive. Let me propose a speculation of mine. Many systems are using Composer and their architectures are quite different. To blame Composer for their success or failure seems to me exaggerated. Here is some criticism about Laravel http://archived.shift8creative.com/posts/view/thinking-about-using-laravel.html I don't see something that is caused solely by Composer (Edit: maybe "slow bootstrap" is for one). On other place (I can not find a link now) I saw that Laravel is criticized about its service locator pattern, which makes not easy to locate a certain fragment of code that actually does the real job. My hunch is that mess (yes, I agree, there is mess) is caused not by Composer, but by patterns used. With or without Composer a critical architectural mistake might happen. RE: Say No to Composer! - MatthewSchenker - 06-10-2015 Greetings, ivantcholakov, thanks for the link to shift8creative! Mr. Maiaroto hits on most of my issues with Laravel. I am glad he and some others are brave enough to speak out about it, because most people who criticize Laravel are slammed for it (everyone in the PHP community seems to have stopped analyzing that framework honestly). I don't necessarily think that Laravel's mess is only because of Composer. But I do believe Composer is a big part of the problem. kenjis, The "magic" I was referring to is the methods that are "installed" and proliferate "assumptions" throughout the framework. This is supposed to "make it easier for you" but in fact just makes it harder to trace where and why something happened. As I said before, I fully admit I might be wrong about all this, and maybe I will be convinced otherwise soon! Thanks, Matthew RE: Say No to Composer! - wolfgang1983 - 06-11-2015 (06-10-2015, 07:40 AM)MatthewSchenker Wrote: Greetings, I like the simple usage of codeigniter just fine the way it is. I do not like composer and never use it. RE: Say No to Composer! - no1youknowz - 06-11-2015 (06-10-2015, 07:40 AM)MatthewSchenker Wrote: Here's my reasoning... 1. Nope. I have many composer libraries. I import them into the vendor folder. I then instantiate them into my code and I'm done. I can now use the library. Takes me 2 seconds to use something. I don't need to maintain that library and I have saved myself a ton of work by not developing the wheel again. 2. Every library that I install. I go through the code and I throughly test and ensure its working completely. I haven't come across any instances where it's a blackbox/magic or doesn't work. Maybe I'm using high quality packages? 3. Doubtful. There are reasons why PEAR was abandoned. But what is next? The League? I don't understand the rational here. Really, I don't. |