I'll mock a large example up over the weekend. Can you give commitment that when 4.1 is GA, there will be a definite answer either way on the framework?
It is safe to say that we are extremely focused on performance in this release and I don't see that focus shifting until we are happy with our performance. That said, quantifying the measure of success I think would benefit from community input. Hence the request for more representative use cases. Having concrete examples of performance numbers like what you describe would go a long way to help focus attention.
@Don I'm feeling ignored
You answered all other posts except mine. My suspicious mind makes me wonder why Sencha has consistently requested complex examples of performance problems, but ignored the posts showing that only a very simple page is needed to see the difference clearly. Please take a good look at the post I mentioned earlier, which I will provide again. I'd very much appreciate feedback.
One of the items on my list to check is if we can simplify field layouts in particular because it has "work around" code in it currently to measure each element and sum their individual widths. I don't think that is needed in 4.1 and it should help a lot to remove it. Also, since fields typically show up in multiples, I have been considering a FieldGroup container (name TBD) that uses tables to achieve alignment (and auto labelWidths) which should avoid even more calculation. I believe there was such a ux in v3 (table form or something).
I guess that your post (because it is field related) fell into my "more research required to provide details" filter, but I do apologize for the silence. No slight intended.
Thanks for posting code to help illustrate the issues you are seeing by the way! It is helpful and is not being ignored, despite all evidence to the contrary.
@Don, thanks for the reply. I actually only added text fields to the simple example to extend it a bit. The performance difference is quite visible by simply creating a viewport with no fields or labels at all. That is the first of the test cases in my earlier post.
While we are looking at those fixed costs like load time, class definition/processing and onready detection (esp in IE), we are more focused on costs that grow with UI complexity. Things like component creation, container initialization, rendering and layout. Then there is intelligent layout invalidation (to only recalculate what is necessary) to ensure a responsive UI.
A few milliseconds of extra fixed cost is not nearly as important when compared to even a small cost that gets multiplied by M*N (M=# of containers, N=# of components) or something like that.
Hopefully that helps explain why we are mostly looking at and asking for larger examples. If we make those perform acceptably, the small ones should come along for the ride
What would be nice is to have some guidelines on how to make an fast ExtJS application.
What parts of an application makes it slow ?
Is is the number of components ? The complexity of the layout ?
Are some components slower than others ? Could it be mentioned in their documentation ?
As a side note I think ExtJS is great, it made me love web programming. I hope it will be fast, reliable and successful