So a few thoughts -
- “Separated libraries allow to use it without big core” => I don’t mind this, as long is there is also some place a common set of these libraries are tested and released as a versioned whole. But make no mistake - you’re trading increased risk of emergent / unintended bugs for the “composability” of the libraries. There isn’t a right or wrong answer, but at least be aware of the downsides too. There are good reasons to keep things in a “core” package, but that isn’t the only way to do it. However, without some level of integrated testing, all I have is a bunch of libraries that will likely break something somewhere every time I run “composer update”. I already have that with the core vs packages external to yii. So this is likely to make that issue worse, not better.
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…