Blog

With the recent announcement of the first public Ext JS 5 beta, we thought it would be cool to take a look at it and take it for a spin. Since we’re a group of seasoned Ext JS developers, we’re very interested in the under-the-hood updates and technical details. We thought we would take a look at memory footprint, performance and breaking API changes. Additionally – since we rely heavily on the Grid component we are also curious about any changes to it, and its performance benchmarks.

A First Look

Screen Shot 2014-04-08 at 17.06.22

The first thing we notice is that the ext-all-debug.js file looks very small. And in deed it’s not the real ext-all-debug.js file, and your application cannot use it out of the box. If your application uses one of the ext-all-XXX.js files, you need to update your include paths to point to /build/ext-all-XXX.js instead. Same goes for the CSS all-file, the ext-all.css can now be found in /packages/ext-theme-classic/build/resources/ext-theme-classic-all-debug.css. Now when we know where to find the relevant files, let’s create a simple sample and investigate the memory usage.

Memory Footprint

Including ext-all.js on an HTML page has the following memory footprint in Chrome on a MacBook Pro we used.

Ext JS 5.0.0.736

Ext JS 4.2.2

The memory footprint of including the entire Ext JS library has doubled. Note, that this is not likely something your application would suffer from since Sencha Cmd will help you custom build the minimum footprint by inspecting the Ext JS classes your application uses.

Grid Performance

We continued to look at the grid performance and tweaked one of the locking grid examples and opened it in a newly restarted Chrome. You can see the test case in this Sencha Fiddle. We added 1000 records to the store and measured the rendering time. After rendering we inspected the number of elements created when rendering such a large grid. The Ext 5 grid now uses a table for each row, to avoid putting too much pressure on the browser when laying out and updating a huge table. The ‘cost’ is naturally more elements in the DOM as can be seen in the comparison below.

Ext JS 5.0.0.736

Ext JS 4.2.2

Based on these numbers, the render time has improved slightly. Just as the grid in 4.2.2, the new grid renders really fast even with 1000 rows and buffered rendering disabled. Though even with a faster grid rendering, when using deferInitialRefresh : true (default), there seems to be some post processing (either in Ext JS or the browser layout) and the grid doesn’t respond to scrolling for another second or two. When we set this flag to false the grid is responsive immediately after rendering.

Another important aspect of the grid is how responsive it is when data changes. We added a button to our sample which does 200 record updates.

Ext JS 4.2.2 takes 126 seconds (!) to complete this task. The browser is completely frozen and unresponsive during this time. With Ext JS 5, the update task takes 13 seconds. About a 10x speed increase for this case. This is of course an extreme scenario, you should not render this many rows to the DOM, instead you should use the buffered rendering feature in Ext JS.

Backwards Compatibility

Another area which is particularly interesting to monitor in the case of a major version upgrade is the backwards compatibility. Remembering the messy Ext JS 3 to 4 upgrade, we were hoping for a clean and simple upgrade process this time. Then again, since we know we have a few overrides of private methods and use a few private properties we were expecting to find a few hurdles to jump over. To better prepare ourselves for the upgrade, we decided to build a simple diff tool which compares two versions of Ext JS and highlights removed and changed class properties. This turned out to be a quite easy task which gave us some interesting information. You can see the results here.

Screen Shot 2014-04-09 at 10.38.26

The tool inspects all Ext JS JavaScript symbols, classes and prototypes to see what has changed. It makes no distinction between private and public properties, so most of the information it shows will be irrelevant to you. It will be interesting however, if you rely on some private Ext JS methods or properties, and such properties are removed or changed in Ext 5. This should not be considered a breaking change, Sencha refactoring private code is expected and your application code should naturally rely as little as possible on undocumented parts of the framework. The output from this tool should not be considered as the full truth, and may contain errors or missing changes. If you want to try it out yourself, you can find this tool on GitHub and hopefully it can help you find vulnerable parts in your code base before you start your upgrade process.

Breaking Changes In Ext JS 5

We have mainly looked at issues we found when trying our own upgrade. Mainly we have inspected the GridPanel class, its related classes and the data package so far, so this list is most likely incomplete. Here are a few things to look out for if you want to try to upgrade to the Ext JS 5.0.0.736 build.

Ext.data.Model – fields. This property has changed from being a MixedCollection and is now a native Array.

Ext.data.Model – modified. This property has changed its default value, from being {} and is now undefined. If you check this modified object in your codebase, you now first need to check for its existence.

Ext.grid.View – itemSelector. Grid rows used to be rendered as a simple TR node, this property is now “.x-grid-item” and if you have CSS styling relying on this selector you need to update your CSS.

Ext.fly(el).on. In Ext 5, you cannot use a FlyWeight element to attach event listeners. You now need to use Ext.get instead.

Unique Model Names. In Ext 5, you cannot currently have two models in different namespaces with the same suffix. Example: Defining Foo.bar.Model and later Foo.other.Model will throw an exception in the current Ext JS 5 beta. This has been reported here.

Ext.util.Observable – addEvent. addEvents has been deprecated and will lead to an exception if called. Calls to addEvents can be safely removed (even in Ext 4.x).

Conclusion

Overall, the Ext JS 5 package looks solid. New great looking themes, new features and only a few glitches detected so far. We were actually able to get the Scheduler component rendered and working within a few hours which is very promising – screenshot below.

Screen Shot 2014-04-04 at 16.34.01

We’ll continue to monitor the coming Ext 5 betas and update our tool to show the latest changes in the framework. If you have any feedback of how we can improve the diff tool or if you have found any other breaking change we should know about, please post in our comments or forums.

Additional Resources


 
 
  1. Don Griffin 04/10/2014, 5:36 am Reply

    Great write up – thanks for digging in and helpful us shakedown Ext JS 5 (even prior to public beta)!

    Thanks also for pointing out the importance of Sencha Cmd because indeed as Ext JS gains more capabilities (like momentum scrolling and multi-input device support, MVVM etc), the size of “all things” will increase. Using Cmd to gather only what your app needs is increasingly important.

    We will be publishing performance measurements as well as we approach GA but glad to see that the grid updates are showing off well in beta 1. :)

  2. Don Griffin 04/10/2014, 5:37 am Reply

    On the case of event names… it is case sensitive in Ext JS 4.x in MVC but not for Observable directly (listeners, on or addListener – see https://fiddle.sencha.com/#fiddle/4v6).

    We are looking at how to make it universally case insensitive on the cheap. Failing that we may pick case sensitive (since that is cheapest). Either way resolving the inconsistency is something we’d like to do in v5.

  3. Westy 04/10/2014, 8:06 am Reply

    Very interesting post Mats.
    Look forward to hearing further insights.

    Currently wrestling with 4.1-4.2, so happy to hear that the upgrade to 5 is less painful.

    Cheers

  4. Brian Moeskau 04/12/2014, 4:53 am Reply

    Defaulting model.modified to undefined feels like a bug. If intentional I’d love to hear the rationale.

  5. Don Griffin 04/13/2014, 6:07 am Reply

    The behavior of “modified” is basically the same as in v3 (see http://docs.sencha.com/extjs/3.4.0/#!/api/Ext.data.Record-property-modified):

    /**
    * This object contains a key and value storing the original values of all modified
    * fields or is null if no fields have been modified.
    * @property modified
    * @type {Object}
    */
    modified : null,

    So it is a (small) part of reducing per-record overhead is all.

  6. Ted Bundee 06/19/2014, 9:24 pm Reply

    Gotta get off extjs 600ms for 1000 rows is terrible (even on a pentium 3 with ie7):/ and 13 seconds to add 200 rows is just plain unacceptable. Yes buffered rendering helps but its really a feature that would not even be needed if the framework was designed properly.

  7. mats 06/21/2014, 9:05 am Reply

    “600ms for 1000 rows is terrible.”

    No it’s not, and please don’t troll our comments.

  8. Ted Bundee 06/25/2014, 7:40 pm Reply

    Sorry that you don’t feel that way.. Welcome to the 21st century?

  9. Mats 06/25/2014, 7:44 pm Reply

    Welcome to the real world, if you could share some constructive criticism – we might take you more seriously. Until then, Adios!

  10. Bill Seddon 07/13/2014, 6:03 pm Reply

    There’s a breaking change in Ext.data.AbstractStore

    http://docs.sencha.com/extjs/5.0.0/apidocs/#!/api/Ext.data.AbstractStore

    In 4.0 the getGroups() function returns an array of groups. In ExtJS 5 the same function returns an instance of Ext.util.GroupCollection.

    You can see this change in the 5.0 documentation for the function. The documentation has been updated to reflect the new result of the function but the example in the function’s documentation still shows an array being returned.

    The same documentation claims the new result class “is a private utility class for internal use by the framework. Don’t rely on its existence.” Not very reassuring

    For those of us with the misfortune of having to support groups in applications that may be run on ExtJS 4 and ExtJS 5 the change can be accommodated by reducing the new result to an array:

    var groups = mystore.getGroups();
    if (!Ext.isArray(groups))
    groups = groups.getRange();

    However, in ExtJS 4 the elements of the array were decorated with Ext.data.NodeInterface so the elements had a ‘children’ property. Now each element is a collection so it’s necessary to call getRange() to access the group elements.

    It’s not clear what advantage the new reliance on a private utility class bring but since its here, its necessary to deal with it.

  11. Mats 07/13/2014, 9:57 pm Reply

    Bill, good catch. You should bring this up with Sencha in their forums. This should be clearly mentioned in the upgrade guide as a breaking change.

  12. tony 08/29/2014, 3:33 am Reply

    Ext JS 5.0.1.1255 improve grid performance significantly.

    In your case for rendering 1000 records,
    Ext JS 4.2 takes about 1000ms
    Ext JS 5.0.0.736 take about 800ms
    Ext JS 5.0.1.1255 takes about 300ms

    • tony 08/29/2014, 6:26 am Reply

      I need to correct my reply.
      Ext JS 5.0.1.1255 use buffered rendering by default.
      ExtJS 5.0 without buffered rendering improves performance slightly.

  13. Mats 08/29/2014, 7:24 am Reply

    Tony, thanks for the update. We’ll be doing an updated blog post later to look at the 5.0.1 performance later. You’re right that buffering is enabled by default, so it needs to be disabled for the benchmarks to be accurate.

Leave a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>