Today we’re excited to release a preview of the performance improvements coming in Ext JS 4.1. We’ve been working hard over the last several months to dramatically improve load time, render and layout performance across the entire framework. For the last several months we’ve been benchmarking and performance tuning with our own examples as well as a number of your apps across a range of browsers, and we’ve made some significant improvements.
Today we’d like to open the current build up to everyone so you can see the speed increase in your own apps. We’d like you to test this release out with your own apps, but want to be very upfront about the nature of this build. This is a **pre-beta performance preview** and has known issues with some components. We don’t recommend using this in production but we would love to hear its impact on loading, rendering and layout performance in your apps.
Table of Contents
What Makes a Web App Fast
When we look at what takes up time in a web application, we find it falls into three main categories:
- Initialization: setting up all the class definitions and preparing for launch
- Rendering: creating the HTML markup for all of your components, putting it in the DOM
- Layout: reading CSS information, sizing and positioning all of the components on the page
Measuring the relative impacts of these three areas is important in understanding what to optimize. We’re going to use the SDK’s Theme Viewer example to demonstrate hard data for this post, but the same general outcome follows all of the examples we have been testing.
The Themes Viewer is pretty heavy–it contains over 300 Components, all rendered to the screen on startup. It’s more complex than most startup screens, even in the biggest apps, so we think it’s a good guide to what happens in highly complex UIs.
All of the numbers presented here are measured on Internet Explorer 8 running on commodity, consumer grade hardware. (We test across a range of browsers and examples but this is a representative example). When we run the benchmarks with this setup on the themes viewer, we find that the page takes 4.5 seconds to finish loading. Obviously, we want to make it faster than that and we set ourselves the ambitious goal of halving the load time.
How We Made It Faster
Obviously, layout is enormously expensive when dealing with screens filled with this many components, but rendering and initialization could be improved too. We tackled each in turn, yielding substantial improvements:
Layouts
Layouts were by far the biggest component of application time in 4.0. Layouts have to do a lot–figuring out the sizes and positions of every Component on the page, allowing for margins, padding and borders specified in CSS, then writing all of those values into the DOM. But by altering the order of operations, we’ve been able to substantially improve performance.
Browsers are optimized to do DOM reads and writes in chunks–so interspersing lots of reads and writes can lead to diminished performance through reflows, repaints and cache invalidations. In 4.0 this was well optimized at the individual Component level but was not well optimized when lots of Components were laid out together.
With 4.1 we have developed a system that batches DOM reads and writes into a small number of read/write cycles, which vastly reduces the number of reflows and repaints the browser has to perform. We’ll be following up with a lot more detail on what’s changed with the layout engine in another blog post.
Bulk Rendering
Moving beyond layouts, we next addressed rendering. Rendering 300 Components in one go is quite demanding of the browser, but just like with layouts we were able to batch together the DOM writes required to render everything to the page. Whereas before each Component was rendered separately, in 4.1 the entire Component tree from the Viewport down is rendered in a single write.
This approach yields another big reduction in startup time. Compared with 1100ms in 4.0, 4.1 renders all 300 of the theme viewer Components in **350ms**–that’s a about 1ms per Component, and a 3x speedup over 4.0.7.
Initialization
Finally, we next addressed the lower levels of the framework and optimized a number of functions from the class system through to utilities like MixedCollection. The cumulative effect of these improvements took us from 730ms in 4.0.7 to **300ms** in 4.1–again more than a 2x speed-up.
Results
All of this adds up. While Ext JS 4.0.7 took 4.5 seconds to render this large screen full of Components, the Ext JS 4.1 developer preview does it in just 2.2 seconds. This is a 2x speed improvement on this complex example running on IE8.
The themes example isn’t the only one that got faster, we’re seeing significant performance improvements across all of our examples and in all browsers. We’ve been benchmarking every single example in the SDK, and when we add together the total load times for each we find significant speed improvements once more:
These numbers are preliminary, so you should expect them to fluctuate as we lock down and head towards final release. However, our own testing combined with real world verification from a group of advance testers tells us a that we’re achieving substantial performance gains.
Neptune Preview
While the focus of this release was performance, it’s not the only thing that made it in. At last year’s SenchaCon we demonstrated an exciting new concept theme called Neptune. While it was only a screenshot on a slide, it caused quite a stir and has been one of the most requested features ever since.
Since we first gave a glimpse into Neptune we’ve been iterating like crazy on it. We’ve tested it with the various ways you can put Components together, making sure the colors, margins and borders all look great from netbooks to projector screens. We’re not quite done yet but today we’re excited to be able to release it along with Ext JS 4.1 Developer Preview.
In this preview release we’re targeting modern browsers only–Chrome, Safari and Firefox all look great so for everyone who develops using those browsers (almost everyone we’ve asked falls into this group) you’ll be able to develop using Neptune from day one. As we finalize Neptune based on your feedback we’ll roll out support to older browsers, all the way back to IE6.
Warning–Preview Code
While we’re very happy with the performance improvements we’ve obtained with 4.1, we’d like to be up front about what this release is. We wanted to get 4.1 into your hands so that you can verify the performance improvements in your app and test out the new theme. At the moment we expect that your app will experience visual glitches, odd behavior and even hard JS errors. We strongly recommend against attempting to use this build in production–we’re looking for feedback on performance and Neptune only with this release.
We are expecting some applications to need changes to migrate to 4.1 using this preview–especially if you have written custom layouts and components. This is because we altered some of the low-level architecture of the layout engine, which can have some impact on some more advanced usage of the framework. We will work with you to resolve these issues, and have created a dedicated forum to collect any migration problems you encounter so that we can improve that experience as we approach 4.1 beta.
We hope you like what you see above and that you’ll give Ext JS 4.1 Performance Preview a spin with your own apps. We can’t wait to hear what you think of it and look forward to your responses in the comments!
What's your reaction?
0
0
Awesome! Thanks for sharing. Personally I like what I see so far of Neptune.
One quick question, will neptune.js be needed in future releases or is this a interim solution to get the theme to work?
Oh yeah! Neptune theme looks awesome.
@NGrover not sure on exactly when we’ll be able to pull back neptune.js – it’s just a few overrides to make the theme render nicely everywhere, will look at it more closely on the SenchaCon madness is over :)
Wow, Neptune is a bigger departure from the previous theme that I expected. It is more minimalistic, more stream-lined. No doubt it will apply to a larger range of platforms than the old theme.
I’m already messing around with this ;)
I ran into this at the top of the neptune css:
“Pictos Font
…
This font is NOT free. It is illegal to use this font without paying for a license.
”
Interim thing?
Will the calendar make it back into 4.1 ? Last blog post say you would try to :D
@Christian yes that is our intention
@NGrover will quadruple check with legal but I believe you are already automatically licensed through us
well done guys! great progress!
That’s not how I remember Neptune… Not looking forward to it anymore :(
That screenshot reminds me of high school web design classes. Maybe the minimalistic approach will grow on me, and the lightness does make me think of intranet web applications more than anything but we’ll see. What happened to shading :(?
Just a heads up: In chrome the calendar picker is missing the arrows for next/prev month.
Wow! Neptune! I’m downloading it straight away. Btw. I have a feeling that the end of the sentence in the last paragraph of “Layouts” section is missing.
Btw2. could you deploy examples somewhere & docs somewhere?
I test my app in 4.1, found that it’s faster than 4.0, but still much more slower than 3.3! really???
I’m going to try this preview right now. I need more performance with the gridpanel, I don’t understand why it is so slow when I use it as a simple table (I just want the user to be able to click on one row, and that’s all basically). Maybe would be nice to get a real ListView again?
Is there anyway we can see some benchmarking numbers of various widgets/application types rendered in ExtJS 3.x vs 4.x? I believe one of the promises of ExtJS 4 was a performance improvement over 3. An answer to this question would be extremely helpful for us to make the decision to move from 3.x to 4.x.
Okay, I tried it, and it’s actually MUCH faster. I don’t need my “ListView” anymore, this is now blazing fast. I also tried the Neptune Theme, it’s quite interesting. Two big issues with it I found for now: the same “blue” is used everywhere, making it difficult to see a few components (especially within the tabpanel). In addition, my menu, which contain icons for each item, doesn’t render properly. But in overall, this preview is super promising. Thanks a lot!
What happened to bootstrap.js? I don’t see it. Also, when I try to run my app I get:
Ext.Loader is not enabled, so dependencies cannot be resolved dynamically. Missing required class: Ext.grid.Scroller
[Break On This Error] var Ext=Ext||{};(function(){var g=this…b.getEditor().setField(a.field,a)}});
ext-all.js (line 15)
Ext.Loader is not enabled, so dependencies cannot be resolved dynamically. Missing required class: Sch.panel.SchedulerGrid
[Break On This Error] var Ext=Ext||{};(function(){var g=this…b.getEditor().setField(a.field,a)}});
ext-all.js (line 15)
Ext.Loader is not enabled, so dependencies cannot be resolved dynamically. Missing required class: Sch.model.Resource
[Break On This Error] var Ext=Ext||{};(function(){var g=this…b.getEditor().setField(a.field,a)}});
Congrats & thanks for the developer preview of 4.1 .. Downloading and testing my app…
The graphics design getting simpler and simpler, good old ExtJS3 theme was the best.
FWIW, I think the new, minimal theme kicks ass! No more than necessary, and enough to show the user the app state. The designers and SASS people did a great job from where I stand.
Thanks for release. But my app is completly unusable. Components size and position are broken, tree with column actions are not well rendered. Toolbar button position are not good. I can only access to the first screen of my app. I tested on Explorer it freeze the browser. I hope the 4.1 beta will work better (and soon) with my app. Currently it works “fine” with 4.0.7 on chrome & firefox only.
@Paipai if you read carefully the post you will see that it said that for the moment any version of IE is not supported in Ext 4.1. Of course, when is finally released it will be supported.
Thanks to the development team for all your efforts.
the same behavior as Paipai in my app (completly unusable), what should I do to migrate from 4.0.7 to 4.1,
thanks in advance. thanks so much
It’s the browser that is causing performance problems.
“[…] IE6, IE7, and IE8 performance on Ext JS 4.0.7 vs 4.1.0 […]”
How bench have been done if IE is not supported ?
Hello Ed,
In the “Layouts” section above: “The results are dramatic–from over 20 reflows in 4.0” – to what ? It looks like you forgot to end this sentence.
BR
Yaron Yogev
I’m having a problem with understanding the approach toward extjs4 themeing.
Neptune has completely new sass files.
I created sass files with variables that customize the now old “ext4” theme to my needs.
These overrides don’t seem to work with neptune.
How is this going to work in the future? A new extjs version will mean new sass files? if new components and changes are made in new versions will there be backward competability with sass variables and mixins? when working with the themes can i play around with the actual sass files or will this be a problem with new versions?
Will be very glad to hear comments….
Thanks for releasing a preview Ed, I look forward to finding the time to try it!
@Yaron thanks, fixed the paragraph. We’ll make another post dedicated to just layout and render changes to dive into a lot more detail
Other than the issues noted in the forum post, this release can be tested in IE. Neptune is not going to work in IE yet.
examplesportal can not work under ext-4.1-pr1. IE a lot of problems.
@SenchaDev
Love the new Chart Export to image (PNG) option in 4.1! Very nice indeed :)
So – it looks promising! The most important thing here should not be the theme, but the speed and reliability of what has been delivered through the versionn 4. Very exciting times!
I have been following the forums, we have been promised weeks, since something like July! What are the timelines for an actual production release? What are going to be the major requirements to change our aps to incorporate the new release? Can we develop the way we have been developing? I am currently using ExtDesigner, Export and develop logic from there on.
Hope the news are great for the actual release!
P.S. There are major problems with things like the portal! …
Thanks for the preview, but for now my app (running great on 4.07) is totally unworkable with this 4.1 preview, the only error I get on firefox is “comp.container is undefined”.
Hope the final 4.1 will be 100% backward compatible.
Wasn’t Neptune a navy theme as showed at Sencha Con last year?
Finally, a modern theme! I can’t wait to see the final version… It might only be UI, but I can tell this will be a turning point in the ExtJS history … ;)
Unfortunately, the docs at http://dev.sencha.com/deploy/ext-4.1-pr1/docs/#!/ still feels pretty slow when browsing with IE 8…
Anyway, keep up the good work!
I really like the Sencha Touch theme, but the Neptune theme doesn’t look all that great to me. It would have been great in 2002.
@ Loiane, Yeah the Neptune theme seems to be totally different to one shown at last years SenchaCon. Very odd. Anyway, I’m not a fan of the current Neptune theme, its far too simple and obviously targeting mobile UI’s, not desktop apps.
That being said, i’m happy with the classic blue theme. My app looks great styled under that :)
@scarsick the docs app flies with 4.1 – the tab switching night and day compared with 4.0. We haven’t deployed 4.1 to our live docs yet because, like I said about, this release shouldn’t be put anywhere near production yet :)
@MrSparks + @Loiane yes Neptune has definitely evolved significantly. It’s not the only theme we’ll be making though and is definitely still in beta
It looks amazing.
I’m looking forward for 4.1 release.
I tried to run the kitchen sunk and it worked well in chrome, but in firefox it does not render the icons.
I’m using ubuntu 11.10 and Firefox 7.0.1
Hope this help.
Great work..
I had such these programs to improve Ext’s performance. Thank God that you’re doing them yourselves.
For example I changed getBody() to get a named flyweight instance instead and now you did better.
I have some new ideas too.
For example when you use a viewport, your document isn’t scrollable anymore. So we do not need to do “fly(document).getScroll();” and add any number to our X or Y of an element in getXY() in Element.static-more.js file.
And one more question the builder tool isn’t avalable anymore within the package?
Thanks in advance Ed..
Excuse me
I wanted to say that I made the 4.0.2a release RTL and add two calendars to the date field too.
My sencha user is maysam_tayyeb
Thanks Ed..
______________
S.M Tayyeb
ExtJS Developer
Love the modern theme. Neptune was a bit outdated to say the least.
I can see that the tree view now supports tripeRows, which is cool. Will the treeStore in the final version support filtering ?
Are you guys going to fix all the masking issues in IE that have been in since 4.0.
Grid masks for example on auto sized grids will mask from the left corner of the grid to the right bottom of the screen.
@ValterBorges have you tried 4.0.7?
@EmCy not sure about 4.1, maybe 4.2. Scope creep is a terrible thing :)
@Maysam the builder is a separate download called SDK Tools, available from the Ext JS download page
Thanks Ed..
You know,
I’ve been RTLing ExtJS since 2.2.1,
I mean the builder that builds the Ext library with sdk.jsb3 ready to use, like 4.0.7 release. There always were folders named build and jsbuilder within their packages that containing some files such as .bat and .js and some other extensions in which I used them in order to build customized RTLed source(The core and the components).
I’ve RTLed the Ext library and changed the cordinates of the page to RightTop instead of LeftTop.
So please tell me do you have any plan to add them again or not.
Regards
______________
S.M Tayyeb
ExtJS Developer
Ed..
Excuse me if I bothered you..
In fact, I want to share my experiences about RTLing the Ext Lib especially in 4.1 with your team in order to speed up releasing 4.2 with RTL support.
Regards
______________
S.M Tayyeb
ExtJS Developer
I’d be interested to see the performance differences between 3.1 and 4.1 as we are still yet to upgrade and I would be interested in whether similar or better performance improvements would be seen as I’m unsure of the impact 4.0 had vs 3.x?
@James Crow –
I’ve asked this question several times already on the blogs and have gotten no response. Its frustrating since this is going to be the main impact on the decision of whether we move from 3.x to 4.x. I’m guessing the answer is not good since no one is willing to answer it.
Sencha – what are the performance expectations for 3.x vs. 4.1?
@James/Benjamin – we don’t know exactly how fast 4.1 is going to be, but if you pointed a gun at our heads, we would say it’s likely to still be slower than 3.x. If IE performance is all you care about, and you don’t care about the new features in 4.x and you have to make a decision *today* to go with 4.1 vs. stay on 3.x, then we’d probably tell you to stay on 3.x. This might still turn out to be the incorrect recommendation, but if you want our best recommendation for *today* – October 31st 2011 – there it is.
Addendum: That said, we’re not finished with our performance optimization work in 4.1. We’ll be continuing to improve performance in 4.2 and beyond if necessary until we get performance in the 4.x line that’s faster than the 3.x.
ExtJS 4.1 developer preview seems to be much faster, when compared to 4.0.
But, for infinite grid scrolling example, scrolling up or down the grid causes big white block to appear and data filled in later. Any ideas what seems to be the problem?
I was having trouble getting a buffered grid to load with different params in 4.0.2a and on the forums heard “Wait ’till 4.1 – lots of significant changes happened with grids in 4.1.” Wondered if it is possible to refresh a grid’s buffered store with new load params {} in 4.1.
Thx in advance for any news.
When will see the beta release? the promised date has passed again.. and the pr-release is not the promised~~
Wohooo… Thats just what I need right now! Thanks Sencha!
@Michael Mullany
Thanks for the reply – I understand that there are still many unknowns. For us – having that information as opposed to just guessing is a big help.
>>> we don’t know exactly how fast 4.1 is going to be…
or as Ronald Rumsfeld would say…
“There are known knowns; there are things we know we know.
We also know there are known unknowns; that is to say we know there are some things we do not know.
But there are also unknown unknowns – the ones we don’t know we don’t know.”
:)
Kuddos for the great performance improvements in 4.1 for IE7 and 8. Our tests confirm improvement.
When do you expect that we can use EXT4.1 in our products? (a more stable version than the Preview)
2 weeks from now? 1 month? 2 months?
We have just completed a major upgrade from 3.3 to 4.1 and of course we are seeing performance problems with IE, this is fine, to be expected and we know they’ll be resolved. However, we can’t release this to our customers until performance problems are rectified. 2 quick questions that will really really help us out:
1) We are still using the compatibility pack. Will doing a “complete” upgrade without the compat pack show us gains in performance? If so, do you have an idea as to what the performance gains would be?
2) In order to schedule with our customers, support, build-team and developers, do you have an approximate time frame when 4.1 will be released? Even if it’s +/- 3 weeks, that is a big help. Will it be in the next 2 months? Further out than that?
We love the new 4.x architecture, we are using it to take advantage of the great charting abilities you have implemented. The architecture and new features are a dream. The inheritance model, the mixins, the class structure with statics, singletons, it’s just an amazing boon to our architecture and allows us to be much more OOP, more organized and develop not only more clearly but faster! We can’t wait to set aside some time to go 4.x completely and use “required” to make the dependency chain clean and clear. Thanks for such a well thought-out piece of software, you guys are true visionaries.
Sorry, the first line should read:
We have just completed a major upgrade from 3.3 to 4.0 <=== We have not tried the 4.1 developer preview yet.
Hi Ed,
Yes, We have been using 4.0.5, 4.0.6 had too many problems for us, 4.0.7 is running just as well as 4.0.5 and has not introduced any new issues for us. However the IE speed and IE masking is still an issue since 4.0
Just upgraded one of my slow pages to ExtJS 4.1 PR and it is running a lot quicker now, thanks!
In order to plan most of us need to know when 4.1 is going to be released. 4.0 is not usable because of the performance problems. This is not breaking news, nor is it a criticism. We all know this is a trying release to get out, and we all know the pressure is on, we can relate to that. You guys are doing a tremendous job!
A lot of us worked very hard upgrading from 3.0 to 4.0 and now can’t move forward with it. It’s probably a management decision not to post a 4.1 release date–we all have to deal with management decisions–but not posting an estimated date I believe could ultimately hurt your relationship with your customers. Offering some more transparency would go a long way to helping us cope. The vast majority of us are reasonable and can take bad news (and dish it out to our bosses when we fall behind).
Please? Even if it’s just an estimate plus or minus a few weeks. It helps.
+1
@Ira Klotzko – I totally agree!
We too, got sort of trapped…
@Thomas, Yup! It was a real bear getting (I’m sure for Sencha as well) to move on up to 4.0. I’m sure they feel bad, heck, I feel bad for them. It sucks to be in this, let’s call it an, “Opportunity to Learn”.
In the meantime I’m rekindling my romance with 3.x as this delay can not stop forward progress of features for our clients!
I don’t even know what to say, this made things so much eiaser!
just tried the 4.1 developer preview and my app has become completely useless !! cant even begin to describe the mess !!!
@astrocybernaute
Your are not alone in this case ! and I don’t understand how bench have been done with this release.
I hope the next one will be more 4.0.x compliant.
“…astrocybernaute wrote:
just tried the 4.1 developer preview and my app has become completely
useless !! cant even begin to describe the mess !!!
…”
we are running out of time for our app lunch date!! one month !
this get me so scared :s
i really really hope the next release will be out very very soon
We’re also waiting the next 4.1 release. Hope that this new one will be really functional and efficient !
We have the same concerns and need to make some hard decisions over the next 1-2 weeks. Can you please provide an update on the status of 4.1? We are very concerned in what are seeing and the complete lack of communication on this matter is very frustrating.
Hello Sencha Team,
Can you please provide 4 us an update on the status of 4.1?
Thank u!!!!
hmm… maybe they’re waiting to deliver it just before X-mas?
;-)
Further 4.1 Updates have been and will continue to be provided weekly in this forum thread:
https://www.sencha.com/forum/showthread.php?154116-Ext-JS-4.1-Updates
I’m going to close this blog post for further comments so there’s a single place to go for further news.
I’m going to try this preview right now. I need more performance with the gridpanel, I don’t understand why it is so slow when I use it as a simple table (I just want the user to be able to click on one row, and that’s all basically). Maybe would be nice to get a real ListView again?
Okay, I tried it, and it’s actually MUCH faster. I don’t need my “ListView” anymore, this is now blazing fast. I also tried the Neptune Theme, it’s quite interesting. Two big issues with it I found for now: the same “blue” is used everywhere, making it difficult to see a few components (especially within the tabpanel). In addition, my menu, which contain icons for each item, doesn’t render properly. But in overall, this preview is super promising. Thanks a lot!