VERY SLOW behavior of fields in nested panels (compared to extjs 3)

here is an exemple to show how SLOW can behave extjs 4 (the same type of code is IMMEDIATE in extjs3)

in the code below, I create 4 comboboxes that I put in multiple nested panels (7 levels of nested panels)
complex applications can easily reach this number of nested panels
selecting an element in the first combo, will show / hide the others. this operation can take several seconds even with chrome, it's crazy.

I'm sure someone will come along to slap your wrist about the evils of "overnesting", but i get it - sometimes you need to deeply nest to get the extensibility you're after.

Anyway, not my real point. There are a few posts about performance, so I think the issue is getting attention - one member posted profiler timings at various levels of nesting to illustrate the point. I was told last week to expect a 4.01 sometime soon (possibly this week), and another maintenance release later in the month.

in my example, for sure it seems "overnested", but extjs is designed like this, and in a real application, if you just setup a form panel, containing a tab panel, in wich you want to put dynamic and custom controls that fit in a column layout and so on ..... I can tell you that you reach these levels
and it is very surprising that extjs3 could handle this well, but extjs4 won't

also, I noticed that in tabPanels switching from a tab to another is also very slow, (while, again, it was immediate in extjs3 as it was just a matter of show/hide a DIV)

to me, this is a blocking issue, I cannot switch to extjs4 until it does at least what extjs3 did

I also mention slow work of ExtJS 4.0.
At the moment I don't know use ExtJS 4.0 or not.

And what is bad it is very slow even in Chrome.

I think more about why it is so and come to coclusion.
(I don't know am I right or not.)
MVC technology slows code in 2.5 times.
For that reason MVC is not used in client side.
I was very supprised that ExtJS 4.0 use MVC.

Also I did many works in Raphael. Unfortunately, it is too slow.
At the moment there is not alternativa to actionscript.(((
I wish that broweres increase their perfomance.

So I don't know shoud I use in future ExtJS 4.x or not.
But I was really upset when learn more about ExtJS 4.0.
I waited another...
Two weeks ago I did a decision that in 2 years I will not use ExtJS 4.x.
I will use ExtJS 3.3.1 and 3.3.3.
And I will change my decision only if Sencha increase perfomance or invent something more.
I also think about "Light ExtJS".

In fact ExtJS at the moment is used only for ERP/CRM.
I did not face another progets.
I very want to use ExtJS for alternativa to JQuery in doing sites.
But even if we use JSBuilder(ExtJS 3.x) for generating framework with only Ext.Window we get
about 200~300 kbs.

I know that in ExtJS 4.0 it is possible to use Ext.Loader.
But real working sample I didnot face to.
I usually use all widget of ExtJS on one page.
Grid,charts,trees,panels, windows, forms and so on.

I think that Sencha should think more about devision of points to use ExtJS.
1 - For ERP/CRM at the moment only this is possible
2 - For sites.

If Sencha will do it I am sure ExtJS became very popular and replace JQuery and other frameworks.

We started four years ago with ExtJs 2, we migrated to 3 now I am busy for some days with migrating to 4. The first problem is run into is that it is very difficult to get the same look and feel on small issues as in ExtJs3. Now I read also about performance issues, I am getting worried.

- Event handlers on keymap and navs are completely changed.
- Events in ExtJs 3 are simply missing in Ext Js , like the beforeselect event.
- Every added css in our application must be altered and must be put on other elements than before. - Resizer behaviour is totaly different on FormFields, it simply works slowly and difficult on a Anchor Layout.
- Why the Form layout is removed?
- Look at the class hierarchy at http://docs.sencha.com/ext-js/4-0/#/api/Ext.grid.Panel. An OO fanatic is doing overtime. OO programming is known to get things slower if it becomes a mission on it own. The only thing they had to do was just cleaning the number of output divs/elements at dom level.