Yii3 Properties

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…

3 Likes

“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.

1 Like

I think it was a good idea to evolve Yii2, you just need to call it Yii3 :slight_smile:

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.

1 Like

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…

2 Likes

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”.

1 Like

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.

5 Likes

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 :sweat_smile::pray:

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):

  1. Makes your real dependencies hidden. It becomes very easy to overlook the moment when there are too many dependencies.
  2. Ties you to a certain name or interface within the container.
  3. Ties you to container itself.
  4. Makes testing harder. You’ll need a container, and a set of certain components in it.
  5. Your services are starting to care about getting their dependencies. That may make them more complicated.

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.

1 Like