What do you mean by that? The fact that list of available attributes in AR depends on state of DB is not a feature for me - it is a problem. AR is usually a base of model layer in the app, it is not good if you canāt relay on it as a type and its behavior depends on DB (and cache) state. In practice it is just another thing to worry about, because in most cases app will not work if DB state (or schema cache) is not in sync with PHP code (you may try to read value from non-existing column).
There is more code in Yii3 version because several issues that were in Yii2 were fixed. The code is the same except those fixes.
What issues? If there are bugs in Yii 2 implementation, they should be fixed there too. But Iām seeing mostly redundant keys and ttl normalization.
Iāve meant that schema introspection and dynamic properties is one of the core concepts of Active Record as a pattern. Iām not saying itās good. Itās, indeed, brings some problems.
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ā¦
No. Not that extreme. We arenāt going to have leftpad. We arenāt going to depend on many external packages that are of questionable quality.
Isnāt it better to maintain these without forking?
I completely agree with you @rob006. @samdark weāve to balance between having every part of the framework can be used in different php projects which are not necessarily Yii, and between keeping the spirit of Yii.
IMO as @rob006 I donāt need to write a fast code in Laravel that will take me weeks to maintain.
And on the same time the framework should keep the framework nature, itās not just a collection of libraries, if our goal is to just have list of libraries we can go with a composer based php project from scratch.
@samdark one more point as many folks mentioned regarding the Java / Spring Boot Style for code, thatās really an old fashion, unreadable / and boilerplate style. IMO the component-based style of Yii2 is a good thing and provides uniqueness / control for our code. Actually even in Java to avoid these parts thereās now libraries / annotations like Lombok which will implement the setter/getter nature for you. Another point really that Yii2-rest is one of the greatest rest framework ever among multiple frameworks / languages.
The main lesson in Yii 1 and 2 was to kill routine jobs, and that appears in multiple areas in the framework, but in Yii 3 I can confirm that many routine / repetitive will happen starting from setters/getters.
I believe weāve to keep the uniqueness of Yii 2 features to keep as is in Yii 3, and for junior / middle level developers its their responsibility to have more effort following best practices, thereās no guarantee at all that you can prevent / limit less skilled programmers doing bad practices and no framework can guarantee that.
I love the monolithic approach of Yii2.
I love Yii2 magic, primarily for AR.
I love Yii2 API.
But I agree source code splitting, autoloading, application configuration, separation libraries and as @anasjaghoub says:ākeep the uniqueness of Yii 2 features to keep as is in Yii 3ā¦ā
Now Iām worried about loosing many of the features of Yii2 in the next Yii3.
Many of us have Yii2 projects in production and many new projects to start and the more we have consciousness of what and how will be the transition, the less we will have problems to apply It.
Balance, balance, balance!!
@samdark less is more! 
@anasjaghoub, @mikem If you like Yii2 and it enough for us, maybe you donāt need Yii3 ? Yii2 is not dead, but it hit a wall.
Yii3 doing good step forward. Separated libraries allow to use it without big core, and build app with only necessary dependencies without overhead, for ex as api or console. PSR-standarts allow to use more libraries without adapters. It donāt be same as nodejs modules. As i know Cycle ORM can be used as AR and it less complicated then Doctrine at whole. Also yii2 AR can be ported too, but may be later or as third party. I think after then yii3 became more stable and some starter-kits and scaffold-generators will be adapted, it can make better impression.
About magic getters/setters in some cases, for ex. DTO, etcā¦ these are not bad. But when it in even core class - sometimes it make a pain. And also with good IDE getter/setter generation is very fast.
So a few thoughts -
That doesnāt mean that it shouldnāt be done, that just means that the implicit benefit of having a core library must now be made explicit in some other manner. This is a key benefit to having a framework in the first place - stability / reliability of non-application-specific foundational code.
But as it is structured now, not yet a step forward - though it could be eventually.
āPSR-standards allow to use more libraries without adaptersā - thatās great in principle, however of the 37 sub-packages I have in @common\components right now which also had public libraries I could have used instead, lack of āPSR-standardsā compliance was not the driving issue in any case for why a class was added to the app vs. just using github. That may or may not be common experience, but in all the years Iāve used Yii2, I have yet to come across PSR compliance as a show-stopper for using a third-party component. Feels like a problem in search of a solution. PSR compliance is not bad, but if I have to give up the AR library or being able to go to functioning app logic in minutes to get it, Iām not going to care much about PSR compliance. Again, everything is a tradeā¦
āIt donāt be same as nodejs modulesā - I used very early versions of nodejs. It didnāt start out the way it is now either, and the current state wasnāt exactly planned. Iām not worried about this at launch, Iām worried about it when I run ācomposer updateā a year from now. Look at the length of the list of dependencies installed in Yii2.0.1 vs. now. Iām not sure it has gotten shorterā¦
āAs i know Cycle ORM can be used as AR and it less complicated then Doctrine at wholeā - Sure, except I already have 200k+ lines of Yii2 AR code AND a custom AR generator that works off of swagger files. The issue isnāt whether or not Cycle ORM works or how complicated it is - Iām not comparing it to Doctrine, Iām comparing it to my production code that I will end up having to port. The comparison / issue that matters here is the fact that you are deprecating a key component of the framework, which happens to be where a good portion of application code tends to live, and with no clear path to port to the next version to boot. Iām not demanding 100% backward compatibility, but when you make architecture / pattern level changes, the cost of migration for users is significant. These sorts of concerns seem to be being dismissed out of hand, as if there is no value to the current AR library and no impact to changing patterns.
āI think after then yii3 became more stable and some starter-kits and scaffold-generators will be adapted, it can make better impression.ā - deferring stability and integration to later stage / third party starter kits and code generators does not tend to give one confidence in what should be foundational, reliable code. Again, a large part of the rationale from my perspective for using Yii is that there is a first-party, core / tested library and application management framework (basic / advanced template). Handing me a list of dependencies to install is not the same as handing me a tree which I know has tested all those dependencies in a common set of use cases / an integrated manner that is known to work āout of the box.ā
" And also with good IDE getter/setter generation is very fast." - If I wanted to use Visual Studio to write PHP, I wouldā¦ This was tried over a decade ago - In my opinion it doesnāt work, and turns into an unmaintainable mess over time. Having lived through both options, the current approach is superior in almost every way. In fact, I recently completed a PoC using Yii2 that finished almost a week earlier than a similar effort in .Net to implement the same use case, and the lack of getter/setter maintenance and mapping requirements was actually cited as a key reason why we were able to move faster.
Again, just my $0.02ā¦
āNo. Not that extreme. We arenāt going to have leftpad. We arenāt going to depend on many external packages that are of questionable quality.ā
But if youāre starting to pull in a number of external libraries with their own dependency trees, Iām not sure this is up to you any longer, especially if each library is now maintained independently with minimal integration / testing against other componentsā¦
āIsnāt it better to maintain these without forking?ā
That depends. If porting from Yii2 to Yii3 exceeds the cost of maintaining a fork, then fork it is. Better is a question of ācan I deliver for my customers / users?ā. If I spend all my time / budget on a port instead of delivering the features theyāve requested or Iāve discovered they need, or fixing existing bugs, then thereās little point in doing a port to Yii3.
Or, if Iām going to have to re-architect anyway, might as well spend that effort looking at it more broadly than just porting between framework versions. (The cost will generally be the same between porting and doing a next version on a different stack, given the fundamental nature of the proposed changes)
Completely agree. I think revolution instead evolution can kill the Yii.
Yii has great ideas. Why to kill something that works.
Instead of being practical yet simple, it tring to be follow āacademic correctnessā. But PHP does not work like this, for example until 7.4 Interfaces did not have covariance, which made them impossible to use in real life. I feel that Yii2 follows āPHP spiritā, being resonably magical. But in current state Yii3 becomes to look like Java, with one exeption, it does not have same level of type safety, what makes impossible to create complicated constructions.
Iāve meant maintaining Yii 2, not porting things to Yii 3. Yii 2 is currently maintained and will be maintained for some years so there is no need to fork it: https://www.yiiframework.com/release-cycle
Overall I understand the concerns but, despite that I was originally planning Yii 2 evolution, some very core things in Yii 2 leading to code that is hard to test and eventually (could be avoided with experience) to maintenance hell in long term projects. Fixing these resulted in all the changes you now see.
I understand that releasing a new version that mostly built on new concepts may drive many community members away but I still think thatās the right direction to move to.
I think it was a good idea to evolve Yii2, you just need to call it Yii3 
Your arguments only confirm my point that you donāt need upgrade to Yii 3. Many projects also stayed on Yii1 with same reason - because profit from upgrade was less than upgrade expense. It is ok. And even Yii1 alive till now. So you donāt warry about Yii2 it has enough community and it will be alive as good RAD framework. Yii3 can bring something more for those that ready to get it.
It was a great idea until it proved to fail solving some very important issues Iāve described above.
Except of course I wouldnāt be here having the discussion if I were intending to stay w/ Yii2 for new developmentā¦
I am in the midst of planning a new development project which will require significant investment - so it only seems prudent to ensure I understand and have considered all aspects of what is happening within the various frameworks and languages, up to and including building a new framework even.
On the other hand, with significant code re-use and such from Yii2, thereās also savings to be realized under certain scenarios. So just trying to balance everything.
Please donāt mis-understand - Iām not arguing for staying with Yii2 or keeping things static, or even attempting to be critical. Iām trying to understand the thinking and rationale behind the changes for Yii3, and the resulting cost/benefit/risk analysis. Having read much of what I could find on the background between ā2.1ā and Yii3, Iām just not seeing the upside to the changes, and so the underlying rationale makes less sense as a result.
Similarly, when I see statements about how āYii2 hit a wallā, and then going on to explain how it will be supported and maintained going forward, it seems something of a contradiction from where Iām sitting. If it has hit a wall and can progress no further, how will it be maintained in a reliable mannerā¦? If the changes are a necessary outcome from this fact, then it would seem that staying with Yii2 is a foolās errand - it cannot be fixed, radical architectural changes are required, and so the probability of it being successfully supported over the next X number of years is low.
But I should stay with Yii2ā¦? Perhaps you can see the basis of my confusionā¦
An analogy might be having a document titled āStrategyā containing a list of low-level tactical decisionsā¦
