That is one extra line of code.
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…
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…