1. #91
    Sencha - Ext JS Dev Team Phil Guerrant's Avatar
    Join Date
    May 2011
    Location
    Colorado
    Posts
    336
    Vote Rating
    93
    Phil Guerrant is a glorious beacon of light Phil Guerrant is a glorious beacon of light Phil Guerrant is a glorious beacon of light Phil Guerrant is a glorious beacon of light Phil Guerrant is a glorious beacon of light

      4  

    Default


    Quote Originally Posted by jchau View Post
    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?
    Yes, if you remove the framing completely your app will perform faster in IE That's kind of a apples to oranges comparison though, because it doesn't isolate how the table itself affects performance. A better comparison would be using tables for framing vs. using divs for framing. I think you will find that emulating CSS3 effects in IE is always costly whether you use tables to achieve it or not. BTW, Ext 3 buttons used tables for framing as well.

    The advantage of using tables for framing in tabs and buttons in particular is the "shrink wrapping" effect that the table has on the content. A table is the easiest way to make an element size to its content in browsers that don't support "display:table" or "display:inline-block" (IE6/7 strict mode, and IE6-9 quirks mode). If we used divs for framing buttons we'd have to fight with "inline-block" emulation in these older versions of IE, which presents its own set of problems and side effects, and does not provide any noticeable performance gain.

    My earlier comment was referring to places in the layout system (e.g. autocontainer layout, box layout) where we insert tables into the DOM to help us achieve effects that would otherwise require calculation in JavaScript. In areas like these you may see tables in the dom (or divs with display:table in modern browsers), where there was none in Ext 3. The reason for this is because the Ext 4 layout system is far more capable and flexible than Ext 3, so in many cases it needs to perform extra calculations. These JS calculations are expensive and so we try to reduce the amount of calculation needed by adding extra markup and styling and letting the browser's rendering engine handle the layout where possible.

    In summary, our thought process on deciding whether we need to use a table usually goes something like this:

    a. If we need feature "x" in the framework (e.g. framing, or shrink wrapping layouts)
    b. AND if there's only 2 ways to achieve feature "x" in old IE browsers - use a table, or perform expensive JS calculations.
    c. We use a table, because it's usually less expensive than calculating the desired layout result in JavaScript.
    Phil Guerrant
    Ext JS - Development Team

  2. #92
    Sencha User
    Join Date
    Jun 2008
    Posts
    138
    Vote Rating
    7
    jchau is an unknown quantity at this point

      0  

    Default


    Thanks Phil for the great explanation. I definitely see why you would want to use tables in layouts. Would a possible optimization be disabling some of the other features for older browsers? If you are using IE8 and prior, remove framing all together from tabs and buttons. That's what I am doing now manually but it's more of a hack.

  3. #93
    Sencha - Ext JS Dev Team Phil Guerrant's Avatar
    Join Date
    May 2011
    Location
    Colorado
    Posts
    336
    Vote Rating
    93
    Phil Guerrant is a glorious beacon of light Phil Guerrant is a glorious beacon of light Phil Guerrant is a glorious beacon of light Phil Guerrant is a glorious beacon of light Phil Guerrant is a glorious beacon of light

      1  

    Default


    Quote Originally Posted by jchau View Post
    Would a possible optimization be disabling some of the other features for older browsers? If you are using IE8 and prior, remove framing all together from tabs and buttons.
    Just curious, what version of Ext JS were you using when you saw the 40-50% performance improvement by disabling framing? In Ext JS 4.2 we reduced the number of calculations needed to determine the "frame size" of components, by caching them by component/ui (previously frame calculation was done per-instance), so hopefully you should see a bit of an improvement over 4.1
    Phil Guerrant
    Ext JS - Development Team

  4. #94
    Sencha User
    Join Date
    Jun 2008
    Posts
    138
    Vote Rating
    7
    jchau is an unknown quantity at this point

      0  

    Default


    Quote Originally Posted by Phil Guerrant View Post
    Just curious, what version of Ext JS were you using when you saw the 40-50% performance improvement by disabling framing? In Ext JS 4.2 we reduced the number of calculations needed to determine the "frame size" of components, by caching them by component/ui (previously frame calculation was done per-instance), so hopefully you should see a bit of an improvement over 4.1
    I am using 4.2 already. Another major pain point for us is the table wrappers for a formfield. Each formfield is wrapped in a table. On our form, we have over 30 fields. Alot of them are comboboxes, which renders out two tables. I can see why you need tables to support fieldlabel, help text, and indicators and such, but it really is much slower to render vs divs.

  5. #95
    Sencha - Ext JS Dev Team Phil Guerrant's Avatar
    Join Date
    May 2011
    Location
    Colorado
    Posts
    336
    Vote Rating
    93
    Phil Guerrant is a glorious beacon of light Phil Guerrant is a glorious beacon of light Phil Guerrant is a glorious beacon of light Phil Guerrant is a glorious beacon of light Phil Guerrant is a glorious beacon of light

      1  

    Default


    @jchau I'm looking into implementing support for making framing optional in IE in a future release. I know you've already found a workaround, but It'd be nice to have an officially supported way of doing it for those that value performance over pixel-perfection.

    Regarding form fields - your concern is noted. Speeding up the rendering and layout of large forms is already on our hit list. In the mean time I'd suggest trying form layout. It still needs some work, but the idea was to speed up large forms a bit by making each form field be a table cell in a larger table, and let the table handle the layout instead of sizing the individual form fields in code.
    Phil Guerrant
    Ext JS - Development Team

  6. #96
    Sencha User
    Join Date
    Jan 2008
    Location
    Los Angeles
    Posts
    149
    Vote Rating
    1
    radtad is on a distinguished road

      0  

    Default


    Quote Originally Posted by xjpmauricio View Post
    I really hope sencha creates somekind of responsive ui features into Extjs otherwise this framework will slowly die.
    Agreed. I've came closing to using something other than ExtJS for this exact reason.

  7. #97
    Sencha User
    Join Date
    Jun 2008
    Posts
    138
    Vote Rating
    7
    jchau is an unknown quantity at this point

      0  

    Default


    Quote Originally Posted by Phil Guerrant View Post
    @jchau I'm looking into implementing support for making framing optional in IE in a future release.

    Regarding form fields - your concern is noted. Speeding up the rendering and layout of large forms is already on our hit list.
    Great to hear! Looking forward to the enhancements in future release. I will check out FormLayout too.

  8. #98
    Sencha Premium Member
    Join Date
    Feb 2009
    Location
    Amsterdam, The Netherlands
    Posts
    245
    Vote Rating
    6
    Grolubao is on a distinguished road

      -2  

    Default


    I just wanted somebody to clarify how am I going to convince the shareholders of my company on purchasing ExtJS 4 when ExtJS 3 does everything that 4 does plus it's faster on IE 7 which 100% of my clients use. Again, 100%!

    People stating that one shouldn't use IE have no clue on corporate business, but are too busy developing small scale applications.

  9. #99
    Sencha User xjpmauricio's Avatar
    Join Date
    Jul 2009
    Location
    Portugal, Setúbal
    Posts
    88
    Vote Rating
    1
    xjpmauricio is on a distinguished road

      1  

    Default


    I've stopped a current project developed with ExtJs 4.2, because of the lack of responsive features with ExtJs. It's very sad for me having to quit the best framework in the market because of this reason. Very very sad.

    I've restarted the new app using of course bootstrap+knockout and others. My current opinion of this new thing using bootstrap+knockout? much more lighter and responsive in every aspect.

    The drawbacks? well...with extjs you have everyting in one place so...It's sad...I'm very sad to have to quit extjs...

  10. #100
    Sencha Premium Member
    Join Date
    Feb 2009
    Location
    Amsterdam, The Netherlands
    Posts
    245
    Vote Rating
    6
    Grolubao is on a distinguished road

      -1  

    Default


    Quote Originally Posted by devtig View Post
    What's in a number? What's special about 5? Transition the product from 4 to 5 should be done because of marketing or commercial considerations.

    I expect improvements to the product are done regardless of the version the product lives in.

    In other words. The speed of evolution of ExtJS should not be influenced by the number of version the product lives in.
    For licensing point of view. The company is not going to purchase a license for ExtJS 4 only to have ExtJS 5 released couple months ago, is like anything, really.