Hi Florin and thanks for reaching out.

First of all, I'm not sure why I am the one who's "reinvent the wheel", since procedural programming has been the default and most intuitive way to structure code since the 1970s.

It is exactly the opposite, it's the OOP gurus who have decided that instead of having plain code that can be easily understood from top to bottom, we now need to overly architect our code to the level of absurdity.

Your assumption that classes are "self organized" is totally unjustified, classes are meant to express an explicit association between data-types and behaviors - otherwise known as "encapsulation", so if some aspects of your code has clear association of that sort then yes, using a class could make sense (as in the case of the driver class for example).

But forcing every aspect of your code to classes when you don't really need them is a perverse idea.

Your advice to have the page object waiting for all the elements in the init method is not even possible as not all elements are available at the moment of inception, they are usually revealed after some action is committed.

Your remedial step of creating a new page object with each change to the state of the page means inevitably that you are going to have more and more objects of the same page or worse more different definitions of pages of the same sort, probably through a convoluted chain of inheritance or composition.

The consequence of that is that inorder to understand your test code, one would have to grind his or hers way through multiple definitions of classes, probably located in different files, and they would need to go into 3-5 layers of depth before they can reach any line of logic, such that the layers of abstraction make the code harder to understand, as the classes and method declare what they do, but the real work is always done elsewhere, the code becomes horribly cryptic and nebulous and badly structured.

Aside from the structural problem, waiting for all the elements at the init is a waste of time, because in most of your tests you're probably going to use only part of the elements so what's the point of having all that dead code that has no value to the logic of the test and can potentially lead to more flakiness?

Sure, you can always claim that my implementation of page object is "improper", however this leads to a totally circular argument, as you can always add more and more principles to the idea of page object and blame the coder for not following them through.

But to me, "you are not doing it right" is just an excuse that OOP gurus make when their ideas do not deliver the benefits they have promised.

In reality, these chaining actions are not fluent idioms.

Instead they are just a burden, imposing arbitrary limitations on the code that doesn't always fit the needs.

My take on this is that absence of structure is always better than bad structure, which the chaining syntax always ends up to be.

Lastly, you keep claiming that the procedural style will lead to failures, but what are you basing it on?

You did not offer any explanation to how your flashy page object code provides better protection against flakiness, if anything it will perform worse since the constant waiting for elements at the init and generating new states even when not really needed is much more prone to failures than a plain procedural code that performs the minimal amount of waiting necessary and at the more appropriate time than in the init.