Hi Mezasong, I read very carefully your article. I think you are misunderstanding the architecture of Flutter.

There is 3 trees: Widgets, RenderObjects and Elements. The element tree is making the link between the widget and the renderObject.

This is all "matter of user interface" ? Yes of course. The real question should be why are these 3 trees ?

Why widgets shall have final attributes ?

Because they do not render UI themselves (in general). They are only data (information and behaviour). Rendering UI is done by render objects. These objects are mutable, updating on widget attributes changes.

In that case, build context is there to make a connection between Widgets and RenderObjects.

The widget itself doesn't know its size. The associated RenderObject does. Same thing with the Theme. That's why a lot of developer are using it this way: because it has been designed to be used like this.

This design, mixing different type of data is the widget tree, also has more advantages than your idea. How do you handle memory usage ? When can you free memory of your objects ? At the opposite, putting your data into the widget tree define its lifetime. When the widget is disposed, your data is freed.

In a small application, it should not be a problem to have a lot of global objects, but in a big application handling thousand of big objects ? As suggesting by Get package, grouping all data as a giant singleton can resolve that ? Well, Yes and No. Yes at the moment, No for the guy that will maintain the application.

What about lazy instantiation (for big objects) ? Scope of the objects (not accessible anywhere) ?

dependencies injection mechanism ?

All these (non exhaustive) questions have been answered by the actual Flutter architecture design ;)