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…
Thing is, many of the concepts I’m considering are not actually orthogonal or in conflict with what I’ve seen cited as these “core things”. They’re not precluded by what you’re considering, nor are they the root cause of “maintenance hell”. In many ways, I think they’re just being over-looked, simply because they’re implicit or structural in nature instead of being explicit features. Think of it as a venn diagram of sorts - not all framework developers run said framework in large production scenarios, and not all application developers write framework code, while the middle tends to be a rather small minority. So one can see why different groups would value different aspects of the same codebase…
To that end, what is the current, best / definitive reference on the specific maintenance problems of Yii2 and the resulting mapping to the current solutions space? (i.e. what is wrong, and how do these changes solve the issue?). I’ve read what I can find, but perhaps I’m missing something.
One other thought: “maintenance hell” is virtually inevitable on long-term projects. Every change has an entropy cost, and so the more you change, the more disorder is created. Some changes move to disorder faster than others, but they all get there eventually. It is the same as the concept of the heat-death of the universe, just on a (much) shorter time scale. (Or, if the were not the case, would we still t be recycling old ideas all the time in new development…?) This is essentially what determines the useful life of a block of code, or a whole project.
The question isn’t whether it can be avoided, the question is at what point do you start over, and what do you take with you when you do? That’s what I’m really on about here - I need X capabilities which lead to Y requirements, and so how close is Z to Y, and what are the deltas required to close the gap…?
Sometimes those aren’t even technical, and/or aren’t even enumerated. (we need X resources to do Y in actuality, but no one ever bothers calculating X, and so Y is then by default impossible…)
So it just comes down to the trades and understanding the “why” behind them. That’s what I’m after here…
I’ve put together a document https://github.com/yiisoft/docs/blob/master/009-design-decisions.md
If you have specific questions, feel free to ask on why X was removed/changed. I’ll add to the document.
Correct. In Yii 2 design decisions such as service locator availability (when abused) or public properties (yes, you can use magic getters), result in exponential raise of entropy. These were observed in numerous projects. Of course, long term projects are entirely possible with Yii 2 but you should be careful with these handy ones that raise entropy significantly.
All these “problems” of Yii2 were a trade-offs for simplicity.
For me, it feels like that some fragility, some testing problems, and some tight coupling are plausible tradeoffs for development speed.
Most projects in PHP will not face those problems you described, but 100% project will face increased complexity.
In my opinion problems you described in “design decisions” do not really important
We still can use setters in dumb way. And public properties does not make our application to much fragile. Loose typing does it fragile.
Regarding testing. In “new” way we need to think how to instantiate all these service to test a single class. I personally do not see problem just to use Yii::$app in tests.
Extracting Yii packages just give possibility they become popular with cost of higher complexity for main users. For example you already need yii-dev to handle complexity, and it is just beggning.
In general I believe it is impossible to two sit on two chars: to make simple, performant and in the same time SOLID in PHP. For me Symfony is a good example, good coded, but I need at least double mental work to develop in it. Also I believe that there are god principles, for example DRY. In new Yii I need do same things over and over again, for example putting services in controller constructor.
That. Third generation of Yii is coming and for the third time nobody cares about migration path…
It would be hard but we do care. See https://github.com/yiisoft/yii2/pull/17607 for example. We’re trying to make it easier but since there are conceptual changes, it won’t be easy.
These were my sentiments as well when I saw the Yii3 plan. Yii3 will just become another “PHP framework” without any advantage or better features over other frameworks like Laravel or Symfony. If the goal is to make it possible to use Yii3 packages in other frameworks and vice versa, then what is the incentive for anyone to use Yii3 packages over Symfony packages or any other?
Yii3 will kill the Yii brand IMO…
Will see. Anyway, this time it’s impossible to move forward significantly without re-thinking fundamentals. Yii 2 is a good framework but it has flaws. As for Yii 3, we’re not focusing on making everything neat right away. Current Yii 3 state is the first iteration of changing the basics with very minimal usability concerns. It already comes together. We’re going to reach alpha state and polish usability then.
From the design decisions of Yii3, some very handy and easy to use features are to be removed because - “they were abused” . It will be good to understand why for example most devs preferred to use the service locator instead of the DI, and it’s because it’s convenient and sufficient for 99% of the devs using the framework.
It’s worth noting that a majority of PHP devs out here just want something that works out of the box without the bells and whistles of DIs, PSR compliance etc or lack of.
This is the same reason why a very bad framework like CodeIgniter is still used by many devs despite all its flaws.
What Yii3 is trying to accomplish is what many other former monolith frameworks have done to little success - there was monolith Zend which was broken up into packages and no one talks about Zend nowadays, there was Aura which broke itself into reusable packages and no one talks about it today, the Joomla core devs tried the same with their homegrown framework and broke it into reusable packages - they didn’t get traction and most are deprecated by now.
Let’s not dilute the value of a great framework like Yii2 that is the only remaining framework which beats Laravel in every category and comparison, by trying to bow down to the gods of “Reusability”.
If we’re talking about service locator, indeed it was abused and it won’t get back in Yii 3 (it’s one line of code to get it back yourself though…). It wasn’t too bad either if you know what you’re doing and accessing it in controllers and widgets only but commonly it was not like that and it was all over the code. For projects that do not last more than a few months or that are very simple it may be OK. Typically you won’t see any implications of technical debt in these but if the project is meant to be developed for a few years, using service locator wrong is a sure way to fail: you will get high coupling (not so related things will break a lot when changing code), you will get difficulties testing (yes, you can use acceptance or functional tests but these are usually too slow for CI/CD) etc.
DI was there in Yii 2 and Yii 3 just improves it. It’s not new.
As for Active Record and DB layer, I agree that it’s good one. The reason for not working on it is that we don’t have enough time/resources for it right now. If you want to, you can join the effort and work on it starting with DAO.
PSRs are mainly for maintainers of the framework. Many end users don’t care, that’s correct. For us it’s easier to maintain the framework adhering to PSRs, we can reuse good focused components such as nyholm/psr7. And what’s more, we’re getting ability to use tons of great tools such as RoadRunner or Swoole without spending much time on adopting our own code.
Yii 3 goal is not to be broken into individual packages. It’s secondary. The goal is to make it more maintainable, more suitable for long term projects, more compatible with overall PHP tools and libraries without the need of thousands of extensions doing nothing but wrapping existing code.
We’ll definitely spend time on polishing codebase usability-wise so it will be less complicated than it’s now.
Maybe I’m a little bit late and maybe that’s the totally wrong place to ask this. To be honest, I’ve tried to find an answer why you removed the service locator for over a month but I was not able to find a good answer. I know it’s a one liner to bring it back but I wonder how people abused it or how you can even do bad things with it. To be honest I really love the service locator and it’s a reason why I love yii2 so much because you have access to every component everywhere, without the requirement to pass something down even to the last class.
I still don’t really get what the benefits of the di should be. For me it seems like things are getting much more complicated. I’ve tried to use it over the service locator but failed many times (that could be as well because I use yii2 mostly via Craft CMS). I read everything in your git documentation and have no clue what the “bad practices” of others might be.
Again, sorry if this is the wrong place to ask. It’s my first post here 
It’s definitely possible to use DI in Yii 2 but it does not feel as well as DI in Yii 3. As for not allowing to use service locator, it’s because getting a service directly through service locator (at least in other services):
If you absolutely know what you’re doing and is fine to deal with possible consequences, you may get service locator easily as you’ve already found out.