h4. Update (12/23): Ext JS 4.1 Beta 1 is now available
The upcoming Ext JS 4.1 release prioritizes performance. We’ve been working hard to improve across the board, but we’ve focused on two major areas: rendering and layout. While this has taken up the majority of our time, there have been many other exciting developments to report. Among these are significant improvements to the JS Grid and border layout, as well as a preview of the new Neptune theme. Read on as to what Ext Js improves in the new beta version.
Learn the latest about Ext JS and HTML5/JavaScript for three intensive days with 60+ sessions, 3+ parties and more at SenchaCon 2013. Register today!
h3. Performance
The necessary precursor to improving performance is measuring it. To successfully and permanently increase performance, however, measurement has to become part of the regular build and test process. This was the first piece we put in place for Ext JS 4.1. Going beyond the use of profilers like dynaTrace, we created some simple measurement tools to use on a continuous basis. We use these tools to track key metrics on every build.
The performance metrics we track correspond to the page life cycle: Load, Initialize, Render and Layout.
h4. Load
An Ext JS application comes to life when its “onReady” function is called. Prior to that time, many things have to take place. When we say “page load”, we can mean many different things, but for the sake of simplicity, here we define page load as the time period that starts at the execution of the first line of “ext-all.js” and ends just before any onReady functions are called. This primarily includes time spent executing all of the Ext.define statements that populate the Ext namespace, and also the detection of when the page’s DOM is ready.
h4. Initialize
When the onReady functions are called, the application takes over. Applications perform whatever custom initialization they may need, but at some point they will create components and containers to display. In some applications, there will be literally hundreds of components created. Each of these components and containers has to be constructed, initialized and wired together.
In Ext JS 4, many more things are components compared with previous releases. Consider the header of a panel. The Header component is actually a container that contains a basic component for the title and (optionally) a set of Tool components: all managed by an hbox layout. This means you can add components to the panel’s header quite easily. It also means that there are more components and containers created in Ext JS 4 given the same panel configuration. Looking at the Themes example in Ext JS 3, there were 148 components in 50 containers. That same configuration in Ext JS 4 generates 271 components in 97 containers. This makes optimization of this area essential.
h4. Render
The next step is the conversion of these initialized components and containers into HTML. In previous versions of Ext JS, rendering was a mixture of calls to the createElement API and setting innerHTML. In Ext JS 4.0, each component’s primary element was created using createElement and its internal structure was produced using an XTemplate instance referred to as the “renderTpl”.
If a component happened to be a container such as a Panel, additional elements were created using createElement and the child components repeated the process as they rendered into the panel’s body element. At each step, special component methods were called and events were fired to allow derived classes and applications to extend this process.
In version Ext JS 4.1 we have optimized component rendering, so components are rendered in bulk. Instead of alternating calls to createElement and innerHTML, bulk rendering creates the entire component tree as HTML and then adds it to the DOM with a single write to innerHTML.
To support this change we added a new method to components called “beforeRender”. There has always been the “beforerender” event, but derived classes typically had to choose between overriding the “render” or “onRender” method if they needed to do any work just before their primary element was created. They could do what they needed and then call the base version of the method which would then create the element.
The general flow of rendering in 4.0 vs 4.1 is shown in Figure 1. In both cases, the process starts at a particular component and descends the component tree.
h4. Layout
Once the DOM has all the necessary elements, the final step is to determine the size and position of any elements that need special handling. Or in other words: the final step is to lay out the components. This process is the most complex and time consuming. It represented just over half the total time in loading the Themes example in 4.0.7. The challenge with layouts comes from how browsers handle requests for style information (such as margins, width and height), especially if these are being changed along the way.
The first rule of performance is that CSS calculations are expensive. Because of this, browsers cache these results. When JavaScript comes along and sets a width or height, however, the browser has to invalidate some or all of this cache. How much of the cache this affects is a function of what was changed and the cleverness of the browser’s CSS engine. The next request for style information will typically then trigger a “reflow” to refresh the cache. In general, one could say “write + read = reflow”. Given that reflows are expensive, an obvious way to increase performance is to reduce the number of reflows that occur during a layout.
In Ext JS 4.0, an hbox layout, for example, buffered all of its calculations and wrote those results only after it had read all that it needed from each component. If the hbox needed to know the size of a component, it had to measure the component’s element (read), but before it could do that, the layout of that component had to do its work first. In other words, the component’s layout performed some calculations (reads) and then stored the results to the DOM (writes). The hbox then measured the component’s element (read).
What started out as a sequence of reads followed by a sequence of writes often became a highly interleaved set of reads and writes, which, of course, resulted in a large number of reflows. To eliminate these reflows the child layouts needed a way – external to the DOM – to report their results to their owner.
Layouts in Ext JS 4.1 have been refactored to use a layout context object to share results while avoiding the write/read to the DOM (and its associated reflow). This change, while largely internal, breaks custom layouts. While we believe this is a fairly rare practice, it is something to be aware of when upgrading.
h4. From 4.0.7 to 4.1 PR1
All of these optimizations produced some very significant gains. One of the key examples used to benchmark the performance of Ext JS is the Themes example. The performance difference of 4.1 PR1 compared to 4.0.7 in this example is shown in Figure 2, as tested on IE8.
h4. Next Steps
While 4.1 is clearly a big improvement over 4.0, it is not yet as fast across the board as 3.4. This is not the last word on optimizing performance. In fact, we have many other performance optimizations planned for 4.x that just could not fit in this release. Our goal right now is to stabilize and ship a final release of Ext JS 4.1 as quickly as possible. We will then be hard at work to accelerate getting those additional gains delivered in subsequent releases.
h3. Other Goodies
As promised, this release is not purely about performance. We demonstrated the new Neptune theme at SenchaCon this year, and we are very pleased that a Neptune preview will be part of this release. Much to our delight, the Calendar example will be returning as well.
The list could go on with the many other improvements, but let’s dive in to some of the more exciting changes.
h4. Grid
By popular demand, we went back and investigated other solutions to the buffered scrolling and “infinite” scrolling mechanisms in Ext JS 4.0. We wanted to see if we could solve our technical problems without resorting to so-called “virtual scrolling”, and we are happy to report that, in fact, we can.
In 4.1, grids of (almost) every kind now use native scrolling. This vastly improves the user experience because things like acceleration, momentum and friction all work as well for grid as they do for any other scrolling content. Another welcome improvement is that this also means that scrolling is done by pixels and not whole rows. This is also true for “infinite” grids, even when the rows are variable height.
The only situation where virtual scrolling is still used is on the locked half of a locking grid. Since it has no scrollbar, native scrolling is not an option there.
Lastly, though not part of grid per se, metadata handling is now supported by Store.
h4. Border Layout
In the process of working on layouts, border layout in particular benefited from some internal restructuring. It has always been a very popular layout, but it has also suffered from some long-standing limitations:
* You could only have one region that is north, south, east or west. If you needed multiple south regions, you needed to use nested border layouts.
* You could not configure the layout such that an east or west region had priority over a north or south region. To achieve this, again, you needed to use nested border layouts.
* Components could not be added to the container after creation.
* Components could not be removed from the container after creation.
We are pleased to say that all of these limitations have been removed in Ext JS 4.1.
h4. XTemplate
Internally, Ext JS uses the XTemplate class for many things. It is a critically important part of the framework but was missing one important feature: it could not efficiently append to an array for a subsequent join operation. When we started work on bulk rendering, we decided that both DomHelper and XTemplate needed to collaborate on markup production by pushing their output onto a shared array.
We then discovered that the internals of XTemplate could not be surgically modified to support this, which allowed us to reconsider just how this piece needed to work. Some long-standing challenges and issues with XTemplate:
* It only supported the most basic control structures: “for” and “if”.
* The code generated from the template was somewhere between very hard and impossible to debug. As a result, errors in the template text were very difficult to track down.
* The template text was compiled at XTemplate construction time, which was undesirable because many XTemplate instances were never actually used.
* Executing the compiled code for a template was not as fast as it could be because it contained many internal function calls and string concatenations.
In 4.1, XTemplates are now compiled the first time they are used. This makes construction of an XTemplate nearly free. Further, the compiled code is now a single function that can be stepped into using the debugger, and it looks very much like the original template.
With this approach, many things became simple to support. Like “else” and “else if” statements and “switch” statements. Even literal code insertion (similar to JSP or ASP) was now a trivial extension.
var tpl = new Ext.XTemplate(
”,
‘Order {id} is ‘,
”,
‘large’,
”,
‘medium’,
”,
‘small’,
”,
‘{% continue; %}’,
”,
‘Items:’,
…
”);
The “<tpl for>” statement generates a proper “for” loop while the “<tpl if>”, “<tpl elseif>” and “<tpl else>” generate the obvious “if” and “else” blocks.
The new “{% x %}” syntax is used similar to “{[ x ]}”. The body of both of these is treated as arbitrary code. In the “{[ x ]}” expression, x is an expression that produces a value that is placed into the output. In the “{% x %}” case, “x” is simply inserted into the function. In this case, it will continue the for loop when reached.
h4. Overrides
In Ext JS, it has long been a common practice to share bug fixes and enhancements in the form of an “override”. In the past, these had to be manually managed as special entities. They operated on existing classes, whereas just about all other code in Ext JS 4.0 uses class names as strings. For example, to derive from Ext.panel.Panel:
Ext.define(‘My.app.Panel’, {
extend: ‘Ext.panel.Panel’,
method: function () {
this.callParent();
}
});
But to apply an override to the same Panel class (in Ext JS 4.0), the shape changes completely:
Ext.panel.Panel.override({
method: function () {
this.callOverridden(); // not possible before 4.x
}
});
And this code will fail if the Panel class is not loaded already. The inheritance use case would not fail, but would instead inform the loader/builder that Ext.panel.Panel was required.
Overrides are now first-class citizens. They can be named and loaded when needed. In fact, writing an override is just about identical to writing a derived class.
Ext.define(‘My.app.PanelPatch’, {
override: ‘Ext.panel.Panel’,
method: function () {
this.callParent();
}
});
Not only does this support the classic uses for override in a managed way, but overrides can actually become tools in your designs similar to a mixin. Where a mixin is always part of the class (like the base class), overrides can be bolted on later and only if desired or needed.
h3. Conclusion
We hope you get a chance to download and try out the new features and improvements as we approach the final release of Ext JS 4.1. We are looking forward to getting feedback from everyone on how this release has benefited you, and where we should look at further improvements.
Performance and native grid scrolling are two of the biggest parts of 4.1 I’m most looking forward to. The Themes Example Performance chart didn’t specify which browser was being used to achieve those results, nor how different browsers take on the same example. Is there any data on that, specifically for IE 8/9?
@Zach Gardner – According to the article the figure represents data from IE8.
I’m also excited for this, performance has been a major issue in 4.0.x releases. Hoping this update will resolve it.
The performance tests were made using IE8 running on a low-end laptop (Core i3 2.1 GHz, Windows 7 x64). We internally measure other browsers, and have discussed how to make more of that kind of data available. In relative terms, the improvements are pretty similar on other browsers though.
We’re still on ExtJS 3.1.1 and planning our next upgrade however I’m keen to understand if this 4.1 is now faster than 3.1.1? Understand from the above that it is not quite as fast as 3.4 yet but we’re not on that version yet. If this can be provided it would greatly help planning our upgrade. Thanks.
@James Crow,
The comparison is most likely very similar to 3.4, but we have not measured it specifically.
The override thing it’s really a must have.
Thanks
I am confused by the Neptune preview line. Will the new theme be in 4.1 or not?
These are very interesting improvements.
However I need to comment on your “low-end” platform.
Core i-3 might be low-end for the consumer market, but it’s mid-range in the enterprise market.
I would recommend you also test on a Centrino Core Duo + Vista which is still more likely to be encountered in enterprises.
Another thing I was anticipating a lot was support for RTL, and I thought it was going to be part of 4.1. Is it?
Thanks.
Do we have a definitive date for the 4.1 general availability release.
Is the latest version available for download or has nothing changed since original 4.1 preview release?
what is about right to left support?
Finally!! if-else support for the XTemplate, this is awesome guys, good job! looking forward for the final release :)
Great, elseif support!!!
How can an *improved* version of Ext 4.1 still be slower than Ext 3.4 ?
Great work guys! I’m can wait to test!
The biggest problem of ExtJS4 is it doesn’t really work on iOS (iPad)… so if you create a website using ExtJS 4 you need to recode it also using Sencha Touch, instead of having a functional (but not touch optimized) site on the iPad by using only ExtJS4. Coding a site two times is not funny, you can share some code between them but it a shame ExtJS4 doesn’t support iPad.
The new way to create patches is interesting, but I think it will be difficult to use in some cases.
Let’s say I wanted to patch the Ext.draw.Sprite class, and this class is required by the SVG and VML engines. How would I ensure that these engines require the patched Sprite class? Do I have to patch the engines, so they require the new patches?
I am now really concerned about your phrase on custom layouts that might break in 4.1. Please provide more detail! What do you mean by custom layouts and how can the new things affect it?
If I implement my custom layout logic in doComponentLayout() method where I manually arrange the elements, am I safe or no?
Also, what does that mean: ” metadata handling is now supported by Store.” ?
We’re still using ExtJS 3.4 with our application. Would the ‘Sandbox’ be updated to support ExtJS 4.1?
Don,
You mentioned in another post that “It is possible for a class to even “require” its own overrides”.
Can you explain in more detail how this could be useful?
I hope that you, or someone reading these posts, can help me out. I am looking for a component(s) that will allow visitor to our application to create and modify web-pages in a browser. Go Daddy and other hosting services allow their users to easily create and edit web-pages in a browser.
Thank you in advance,
Gus
Thanks for the update guys. Has createElement been completely removed from the framework in favour of innerHTML now? Fingers crossed the answer is YES :)
Yeah, a clarification of the override example would be great!
Does the override directive mean that the base class is overridden (Ext.panel.Panel) or do I need to change all controls to instead use “My.app.PanelPatch”?
I really hope that My.app.PanelPatch is only a “helper” class, otherwise the override method is pretty much unusable and Sencha has missed how most people (guessing from forums where tons of overrides are available, can’t be a surprise to Sencha).
The move from objects to strings for classes has really made development a pain-in-the-b**t as you find yourself constantly chasing typos and the useless errors don’t help isolate where the ficking error is…
@tangix,
The role of the override name (My.app.PanelPatch) is to enable the override to be used in a “requires” or “uses” statement. That way you can state dependencies on overrides and the loader will load them and the build tools will include them in builds only when needed.
Once an override is processed, it modifies (overrides) the target class named in the “override” property (Ext.panel.Panel). The application continues to use the same class (Ext.panel.Panel) but that class is now adjusted in someway.
There is no other use for the name of the override itself (My.app.PanelPatch), though there is an object generated in that namespace with that name, so the name must be truly unique.
Hopefully that clears things up. :)
Hi,
Will RTL be supported in 4.1?
Thanks.
SV
@Stefaan Vandenbussche,
Thanks for the feedback and specifics. This was the lowest end machine we could by new, but we are considering adding older machines. Good thing for eBay :)
@Don,
thanks – that makes perfect sense. Phew :-)
@Les,
The patches would be required at a higher-level, possibly at the app layer. This is not unlike overrides in the past. The overridden code can not reach out for overrides that it does not know about, so the app (html, jsp, asp) had to load the needed override files.
If your company has its own value-add layer of components that you use to build apps, sometimes an override could be required at that lower-level.
@Dmitry Pashkevich,
The inner workings of layouts had to change quite a lot for layouts to coordinate their activities outside the DOM. This mechanism is implemented in the Ext.layout.Context and Ext.layout.ContextItem classes. The Context class has a solid first draft of docs in the PR download.
The doComponentLayout method is not used in the same way as it was in 4.0 from the perspective of a component author overriding the method. Users can still call doComponentLayout to update the layout, but how that is accomplished internally is different in 4.1.
To layout a component in 4.0, we have the concept of a “component layout” (Ext.layout.component.Component). This object was used by doComponentLayout to perform the actual layout. Obviously, if you were implementing your own component in 4.0, you could skip this and just do the work in doComponentLayout.
In 4.1, the component layout object is required. The reason is that all of the active layout objects in a component tree are executed together and iteratively (please see the aforementioned docs) in a basic “solver” process. This includes component layouts and container layouts.
For more discussion on this, the forum would be a better place to sort through specifics.
@Les,
The usefulness of a class requiring overrides of itself would be for large classes. Internally Element comes to mind. We are considering using this technique to better break-up the class into cohesive units (like we do now manually at a file level).
@MrSparks,
We still have some few places that use createElement. And of course we still support DomHelper methods that wrap createElement for convenience. But I would say we have moved 95% of all our rendering into the core markup production phase (which then goes into innerHTML).
@ykey,
There is still some internal discussion on the status of Neptune in the 4.1 release, but it boils down to the effort required to support modern browsers vs IE. It is likely (though not yet decided) that “Neptune preview” will mean “only supported on modern browsers”.
Sorry, but RTL and ARIA were de-scoped from 4.1 to get the release out sooner.
@Daniel,
Yes, sandbox mode will be supported in 4.1
Where is the download for the 4.1 preview release? I can’t find it anywhere, so I guess it’s invite-only or something? Given that the article concluded with “We hope you get a chance to download and try out the new features and improvements…” I figured that we could download it already?
Sorry, my bad. The “Ext JS 4.1 Performance Preview” link has a download link. I clicked on the link below it thinking that the first one would just be an article about its performance. The second “update” link only links to 4.0.7, though.
@Marc,
Thanks for the info on the link. I’ll see what I can do about that.
The article with the download is https://www.sencha.com/blog/ext-js-4-1-developer-preview/
The download for 4.1 PR1 is https://cdn.sencha.com/ext-4.1-pr1.zip
@Dmitry Pashkevich,
Stores in v3 supported a “metachange” event which was lacking in 4.0.
See http://docs.sencha.com/ext-js/3-4/#!/api/Ext.data.Store-event-metachange
Just full of win. :D Thanks for the hard work guys!
@Don
Thanks for the clarification about the overrides config. I knew I was missing something!
Excited and anxious for a stable release :)
Any updates on nested stores and models? I’m currently working with trees and find it a PITA that my tree store model is applied to all nodes (which doesn’t fit many cases in reality)…Would love to see an improved model/store approach when those models are nested.
Keep the communication coming… thanks for putting metadata back in :-) this makes me very happy.
also noticed the article used camelCase for the events… I’m assuming this was an editor oversight? (I thought all events where lowercase)…
@ahmed “right to left”, it is support for languages that are written right to left, as english (and many other languages) is written left to right. They are aligned right amoungst other things. (a overly simplistic answer)
Can’t wait to use this baby…
These speed improvements are great! you really notice the difference in render times on IE at the moment. Looking forward to trying out the better grid scrolling too.
Any update on getting a proper Router & Controller actions? I’m using PathJS for this at the moment but would love to see a native implementation that allows action names such as ‘new’ and ‘delete’ or ‘destroy’. Currently naming controller functions like that conflicts with javascript keywords or Ext events.
@Don,
With regards to the remaining 5% that’s using create createElement. Can this be moved / do you plan to move this to innerHTML?
There’s a great blog detailing the performance penalty in createElement. Google “Benchmark – W3C DOM vs. innerHTML”.
@Thomas,
There is some investigation underway on nested stores and models, but that is not scheduled for 4.1. This is a common use case, so I hope we can make improvements there.
@Dawesi,
The camelCase is the beforeRender method (like afterRender). The event name is beforerender. Unless I am missing the name to which you are referring.
@MrSparks,
The remaining uses of createElement are “harder” to convert, so we haven’t pursued them. In some cases we now render them in the “detached body” (Ext.getDetachedBody). Then we move the elements to the body on first show. The drag proxy stuff is one example of this.
@Barry,
We have been looking at MFC improvements in Touch 2 and these would (eventually) be merged with Ext JS. Not sure when that will happen, but you could track the latest progress on MVC by watching Touch 2.
@MrSparks,
If you are referring to http://www.quirksmode.org/dom/innerhtml.html, that was a big supporting argument for pursuing this approach. :) Great article!
Native scrolling: Does this mean that current 4.0.7 bugs with broken scrollbars (i.e.after panel switching, hiding) are going to be fixed?
Multiple panels in a single (border layout) region:
1) how does collapse/expand work?
2) Can I have multiple panels expanded or collapsed in the same region ?
3) Can I configure if multiple or single panel can be expanded at the same time?
4) Will it support panel hiding? (because I want to use it with “sliding panel UI layout”, not yet natively implemented in Ext 4)
@Don,
That’s the article :) When 4.0 first dropped I did a little digging and found this article. I suspected that createElement might be the cause of the IE issues, however my limited JavaScript/programming knowledge meant I couldn’t prove it either way. Can Sencha seriously consider removing the remaining 5% createElement bottleneck moving forward, it would be very beneficial to the overall performance :)
@Don Griffin
quirksmode article is a bit outdated… createElement with document.createDocumentFragment works pretty well in my case, since appending to document fragment object does not cause page reflow. Did You Guys did some tests, please share if so?
is there a timeframe that we can be expecting this release. Im excited for the changes and cant wait to see how it helps my app out. I would like to have a timeframe because i have some bugs that i think this will fix and i can delay looking at those bugs if i can tell my PM when this release is coming
Great work guys! I can’t wait to test it, thanks.
@Don: any word on the 4.1 release? We are in the middle of a project go-live and the IE7/IE8 performance issue has become a MAJOR bottleneck. Is there a way we can get access to the beta release before Christmas?
Appreciate your help and inputs,
@krishnaM Suggest you look into Chrome Frame if you truly need performance on IE7-8
@Rich02818 IE7/8 performance is a concern of ours as well, and if we had the means to install Chrome tab on our clients computers, wouldn’t we just install Chrome?
@Rich02818: Unfortunately, in most corporate environments, asking customers to allow their users to download a plug-in or the Chrome Frame is not a realistic solution.
It is claimed that Chrome Frame can be installed without admin privileges. Given that we have no reason to expect acceptable performance of ExtJS 4.x in old IE versions, I consider it worth investigating….
http://www.webmonkey.com/2011/05/install-google-chrome-frame-without-admin-privileges/
@Rich02818, most corporate environments prevent downloads by users, they also may have strict internet usage policies. Typically violating these is gross misconduct.
I was really interested in the new “to png” feature of the charts – I’ve been trying to figure out how to do that for a while (particularly in VML).. However, looking the source it look like you’re just sending the rendered chart data over to some sencha server (http://svg.sencha.io)! This is completely unacceptable from a security point of view on my project and I’m sure others will be in the same boat. Why isn’t it mentioned in the docs that this is how it works?
PS: Why is http://www.sencha.com down so often!! Do the other servers covering http://svg.sencha.io have the same issue? If so that’s a pretty bad show too.
I am also very really concerned about your phrase on custom layouts that might break in 4.1.
You ‘believe this is a fairly rare practice’, but we are doing some custom layouts here !
Good Job for 4.1.0 Beta 1. Thank you again for publishing it before Christmas!
Ext.define(‘My.app.PanelPatch’, {
override: ‘Ext.panel.Panel’,
Breaks the loader if you have this class before loading Ext.panel.Panel.
Then Ext.create will throw [Ext.create] ‘Ext.panel.Panel’ is a singleton and cannot be instantiated
@Dennis I know it’s not specified but did you try to add a ‘requires’ property to your definition?
Ext.define(‘My.app.PanelPatch’, {
requires: ‘Ext.panel.Panel’,
override: ‘Ext.panel.Panel’
});
Little redundant, but it may work.
@Camden, that doesnt work. And even if it did, it would still have the problem of requiring me to load the panel up front, which I am not really interested in doing. I wanted to use this for loading localizations, and then just expect them to work whenever the appropiate class was actually loaded.
Why Extjs MVC app do not work with multiple applications ?
for example:
Ext.applicationBundle({
name: ‘Mainapp’,
bundles:[‘App1′,’App2’],
controllers:[‘Myappcontrol’]
})
Ext.create(‘Ext.app.Application’,{
name:’App1′,
controlles:[‘app1controller1′,’app1controller2’]
})
these is good!! because i develop my application by modules,
and modules can be developed like application.
For multiapplication, Check out https://github.com/mitchellsimoens/SubAppDemo
That is ok ! but does not use the Ext.Loader
I must write my application dependencies coupling the application to them.
I must list all dependencies. Would be better to be created dynamically like the application using the Ext.Loader. Js are deleted and are not persistent in my application.
It would be better if my application has an array of modules(the names of the modules).
A module would be a type of application with MVC architecture, some type of inheritance or something.
But does not use the Ext.Loader I must write my application dependencies coupling the application to them. I must list all dependencies. Would be better to be created dynamically like the application using the Ext.Loader. Js are deleted and are not persistent in my application.
It would be better if my application has an array of modules(the names of the modules).
A module would be a type of application with MVC architecture, some type of inheritance or something.