I welcome people making actual suggestions on areas where Ext can be optimized, but I grow very tired of hearing people complaining about performance (like that one guy who wouldn't give up the mic at SenchaCon). I have built very large applications on multiple versions of Ext and I have not had any significant performance issues, even with 4.x. If a developer finds himself in a state where he can not overcome some issue with performance (or any other part of Ext for that matter) he should:
1. Be specific and try to identify the problem area
2. See if any workarounds exist
3. Seek out help from either forums/Sencha support/ or a third party consultant
4. Stop pretending 4.x is incredibly slow. Many people have written large 4.x apps.

4.x is miles ahead of 3.x. I enjoy working with it and find the improvements well worth the unnoticeable performance cost. And while I have seen some noticeably slow Ext code in the past, it has always been fixable and usually not directly caused by the framework, but by a developer blaming the framework. And if you do see something specific that is slow in Ext (in a realistic context - I don't care how many millions of times you can run something in a loop to show it is slow) you can work around it, or better yet, take advantage of the open source nature and provide suggestions/overrides to Sencha and the community.

Obviously you're not using IE 8. Both Chrome and Firefox have great performance with 4.x from my experience. Unfortunately many developers are still tied to IE 8. Given this, the performance difference from 3.x to 4.x was quite noticeable. I would imagine, however, that Sencha has squeezed every drop of blood trying to get IE 8 to be faster under 4.x. The only thing we can do now is wait for that browser to die, die, DIE!

There are a lot of haters around. I won't spend my precious time responding their stupid complaints about ExtJS Speed. They expect IE 6 to work as chrome. Such an idiots don't deserve an extjs forum account.

I welcome people making actual suggestions on areas where Ext can be optimized, but I grow very tired of hearing people complaining about performance (like that one guy who wouldn't give up the mic at SenchaCon). I have built very large applications on multiple versions of Ext and I have not had any significant performance issues, even with 4.x. If a developer finds himself in a state where he can not overcome some issue with performance (or any other part of Ext for that matter) he should:
1. Be specific and try to identify the problem area
2. See if any workarounds exist
3. Seek out help from either forums/Sencha support/ or a third party consultant
4. Stop pretending 4.x is incredibly slow. Many people have written large 4.x apps.

4.x is miles ahead of 3.x. I enjoy working with it and find the improvements well worth the unnoticeable performance cost. And while I have seen some noticeably slow Ext code in the past, it has always been fixable and usually not directly caused by the framework, but by a developer blaming the framework. And if you do see something specific that is slow in Ext (in a realistic context - I don't care how many millions of times you can run something in a loop to show it is slow) you can work around it, or better yet, take advantage of the open source nature and provide suggestions/overrides to Sencha and the community.

I'd suggest you actually *read* the numerous forum posts showing specific scenarios that have severe performance issues in v3. I find it very sad that post such as this are now showing up years after careful documentation of these problems have been posted, and acknowledged by Sencha as real issues. Sencha has promised to fix these problems and has yet to do so.

For a couple examples which have been acknowledge by Sencha to be problems:

I have on many occasions read useless rants about performance which are of no help. I never stated that no person has ever taken the time to point out why. Again, I welcome posts that make suggestions and pinpoint an area of concern. All I ask is that these things are handled in a professional manner. Part of that, is seeking out help or working around an issue rather than jumping on the forums and yelling about how slow 4.x is. It may often be user error. Not long ago I read a thread where a user was viciously attacking the framework for being buggy only to find out he was using the wrong stylesheet. Whether you want to believe it or not, many people have used the 4.x line with large-scale applications without issue.

I expect more features and more flexibility to come with a performance cost, but I also expect Sencha to push the limits for performance. Maybe they haven't addressed every single issue out there that you have run into, but performance is definitely something they continually work on.

It's also a bit disconcerting that we're now at 50 days past SenchaCon and there still hasn't been a single word from Sencha about Ext JS 5. Come on guys, we're dying out here. Pull back the curtain a little, please!

1. We've been down this road several times, and have come to the conclusion that performing layout calculations in JavaScript is always more expensive than achieving the same result with pure HTML/CSS. The tables you see in the markup are to achieve layout results that would otherwise require calculation in JavaScript.

If table is not an issue, then why do I see a 40-50% performance increase in render time when removing frames on tabs and buttons in IE7 and IE8?