Thanks for posting this - What I have been concluding based on discussions here after studying the “history” of Yii3 posts and trying to sort out what’s where on github.
One other point I will add: while openness and maintainability are excellent goals, that has to be balanced by practicality in “real-world” projects. I once created a graph of a node.js project charting the full dependency tree - probably unsurprisingly, it was so complex as to be un-parasble. Now every time I install a set of node requirements for a project, I get all sorts of warnings about security issues in code I have no concept of or time to investigate.
Yii3 is headed down a similar path it appears. While I understand the reasoning, there is a very strong case for having a “core” project or codebase, or a small set of packages - fewer dependencies, and much lower risk from unintended consequences when doing updates. I have an application running in production today which handles 200-300k new database records a day, and can handle most user queries in under 100ms, and I have all of ~15 direct requirements in my composer.json. I know what all the packages are, what they do, and what the potential impacts are from running an update. I don’t know all their dependencies in detail, but at a high level I know what projects they come from and why they’re there, and could go spelunking if I needed to.
Contrast that with the 8+ hours I spent dealing with working around some node.js code that was crashing due to being unable to parse some file 12+ links deep in the dependency tree that came from a package whose function was not in any way germane to the code at hand.
I found Yii2 due to looking for something that implemented AR in PHP. I’ve used it for many years due to its superior architecture and design (somehow completely ignored in the “agile” world, but massively important on large projects), general simplicity of use, and high performance being able to be maintained at scale more effectively than other PHP or even non-PHP approaches.
So in the end, I need a framework that checks certain arcitectural / pattern boxes, like active record. If I can’t find such a framework, I’ll write one, or pick a different tool that does what I need.
I am actively engaged in the early stages of a major development effort now planned to target Yii2 (don’t think 3 will be released soon enough, which is fine). The current state of Yii3 discussions is giving me pause. I have already started a team off on a trade study to investigate alternates and have been leaning toward picking something other than Yii2, or forking it in such a way as to maintain some of the features above. The study is not yet complete, but I have been proceeding under the assumption that Yii3 will not meet our needs and will require too much extensive re-work of existing code to justify the investment in new development, especially as key architectural tenets are being altered. (architecture changes == expensive)
That is not to say that all the ideas are bad. But there seems to be such a great emphasis on addressing a specific set of challenges (maintenance issues, “portability” to other projects, etc.) that the core of what differentiates Yii (a particular approach to architecture) is being lost in the noise.
So if there is some room for debate on that point, perhaps it is worth re-considering, but until I saw this post I had lost all hope that there was any future in Yii or any point in pursuing further development.
Just my $0.02…