It is with pleasure that we announce today the general availability of Ext JS 4.1. This release represents a significant step forward for the performance of Ext JS 4, including several new features and numerous other improvements. With the three betas and the three RCs, we’re also extremely thankful to the community members who have helped us with bug reports, forum posts, emails, tweets, and field testing on production applications to make this a huge step forward for Ext JS!
Performance
This release focused primarily on improving performance of the rendering and layout processes. On our test applications and community contributed tests, we’re seeing anywhere from a 30% to a 100% improvement in end-to-end display time. The new bulk rendering mechanism allows us to render the right markup initially and avoid expensive manipulations of the resulting DOM elements. The new layout engine is designed to minimize the number of costly browser reflows required to layout components and containers.
While many other, smaller, optimizations made it into this release as well, the focus of the release was on layout and DOM performance optimizations. We’ll continue working on further performance improvements in subsequent releases, and we’re always open to your input in the forums to see what areas you think need our attention next.
Grid
The return of native scrolling for grids has been covered previously so I won’t go into that further. The many improvements to infinite/buffered scrolling will be great news for applications with large data sets. For grids that use the “locking” feature, many other features now work properly on the locked and unlocked sides of the grid.
Layouts
Most of the work on layouts has been to make them faster by avoiding browser reflows. In the process, however, most layouts benefited from the refactor in other ways. Most notably, the “border” layout’s new features have been covered previously. In addition, the width shrink-wrapping that used to be handled by specialized components (e.g., tooltip or menu) is now properly handled by the core layouts. Not only did this change make those use-cases much more efficient (by avoiding repeated layouts), but now this functionality is more generally available in your applications.
Core
There have also been significant improvements in XTemplates and overrides. Much of this has been covered before; however, Ext.override has also gained a new bit of useful functionality: it can now override instance methods (e.g., on a singleton), allowing the overridden methods to be called using the standard callParent method.
Another handy addition to event listeners is that the use of method names (rather than function references) is now supported. For example:
listeners: { click: 'onClick', change: 'onChange', scope: someObject }
In previous versions, the above would have looked like this (which is, of course, still valid):
listeners: { click: someObject.onClick, change: someObject.onChange, scope: someObject }
The use of method names gives better diagnostic messages in development mode for missing methods.
Tooling
We’re also excited to release alongside Ext JS 4.1 the new release of the SDK Tools, Beta 3. The new version of the SDK Tools is required to generate images for custom themes using Ext JS 4.1. This same version of the SDK Tools is also compatible with the latest release of Sencha Touch 2.
Included in the example folder of the Ext JS 4.1 download is a web page-based tool called the Page Analyzer. This has been covered as well, but its use is highly recommended to get the best performance out of Ext JS 4.1. It is also invaluable for diagnosing layout problems.
Docs and Guides
Of course, the documentation center has been updated to use Ext JS 4.1! In addition, there is new content important for moving to the new release. There is a new Optimization Guide based on the related blog post and webinar. Reference it for the latest advice on tuning your applications for best performance. There is also an Upgrade Guide covering the API changes that will likely impact your move to Ext JS 4.1.
Conclusion
Ext JS 4.1 brings significant improvement to your applications, and we are investing heavily in exceeding our customer’s usability and performance expectations.
We want to take this moment to reiterate our commitment to our customers on various versions of Ext JS. We blogged about extending support of Ext JS 3 for 12 months beyond the next major release after Ext JS 4, and support subscribers will continue to receive patch updates for Ext JS 3.4.x, including support for IE 10.
We are very excited about Ext JS 4.1 and are looking forward to your feedback. Go to the forum and let us and the rest of the community know about your experience with Ext JS 4.1!
This is excellent. Definitely a long time coming. Congratulations you guys. Thank you very much for the hard work!!!
Excellent Don, I look forward to upgrading.
Good news! Can we have a comparison of speed between 4.1 and 3.4 for Internet Explorer? Is it now faster, or still slower?
Good work!
Congratulations guys, can’t wait to get using 4.1 at work now!
YES!! Also, today is not the 23rd
And how much did the API and CSS patterns change *again* between 4.0.7 and 4.1? Have you documented the differences?
great news… will be looking forward to continue with migration to 4.1.
When do you expect Sencha Architect to support 4.1 projects (instead of 4.0.x) ?
I was looking forward to see this release since I’ve seen it at SenchaCon 2011.
I want to know a question though : what about the Neptune theme, is it finished ? Is it working in all browser ?
Why is it so slow in Kitchen Sink demo? It’s like a turn-based strategy game.
What happened to the grids scrolling? Very slowly in Firefox :-(
Great news :-)
“#Sylvain Filteau ….. what about the Neptune theme, is it finished ?….. ”
+ 1 good question…. so, the Neptune theme its done ??!! will be done someday… ??!!
Best,
Thank you! You are awesome! So many read and watch about it, can’t wait to try. This is will be the very long night :)
Neptune is still in “preview” status and is WebKit only at the moment. We opted to not remove it from the distribution because, even in its limited form, some in the community have found it sufficient for their purposes (possibly with some modifications of their own).
The proper link to the Upgrade Guide is:
http://docs.sencha.com/ext-js/4-1/#!/guide/upgrade_41
We should get the link at the top corrected soon – apologies.
For neptune theme the following folder is missing:
/extjs-4.1.0/resources/themes/images/neptune/tab-bar
@Ulrik: we are definitely going to move to 4.1 in the upcoming 2.1 release. We don’t have a timeframe yet for it, we will release it when it’s ready.
Many many thanks to Sencha team. It is a brilliant job. Now we need a modeling & code generation tool with Sencha Architect. So that we can scaffold easily and save more development time.
Awesome!
Don, Nige and team – great work. This was always about doing it right, rather than doing it fast, which accords with our own philosophy. Now we can be confident in looking to move our production solution from 3.x to 4.1 with all the many benefits that this will give us. Look forward to celebrating this and much else in London next week!
Excellent guys, thanks.
Hoping the SDK works, been a looooong time coming ;)
A repeatedly stated major goal has been performance…and the target is to be faster than 3.4. Sencha, surely you must be measuring your progress against this goal so please tell us the results. Your lack of response (this was the very first comment to this blog) makes it difficult to not be concerned. Thanks.
None of the examples in the documentation for 4.1 is working. Also there is no switch from 4.0 to 4.1 via the “version selector” …
Finally, Well done guys!
Yeah, most of the samples don’t work whether I’m using a webkit browser or not. IE 8 is totally broke. Running some of our production code against 4.1 GA in IE 8 shows that instances where a class extends a window and puts components directly in that window fails to layout (whereas it had prior). However, placing a panel in a window then placing the components in that panel does work for the default layout. This is minor compared to the examples fail, however. I think we’ll put this cheese on the shelf and let it grow some mold first.
Here’s a toast to EXTJS 4.1.1 GA.
We are looking into why the examples are not running properly in the Documentation Center. They run properly from the direct link:
https://www.sencha.com/products/extjs/examples/
If you are having other problems, the forum is the ideal place to discuss them.
https://www.sencha.com/forum/forumdisplay.php?79-Ext-JS-Community-Forums-4.x
Congrats guys, thanks for all the great work, and for the SDK tools update. Looking forward to playing with 4.1.
Whoohoo!!! Congratulations to the team for all their hard work in bringing 4.1 to GA!
@Doug Bieber: This release seems a bit “rushed”. The issues in sum make it look kinda unfinished … I’ll wait for 4.1.1!
http://docs.sencha.com/ext-js/4-1/#/guide/upgrade_41 is broken. What’s the correct upgrade URL?
@Don Griffin Thanks for the direct link. That does seem to work fine. Even with IE 8!
@DougBieber, perhaps the direct link to the examples works because it appears to be using ExtJS v3, not v4.
https://www.sencha.com/products/extjs/examples/
look at source:
view-source:https://www.sencha.com/products/extjs/examples/
contains:
[removed][removed]
look at this source: http://ajax.googleapis.com/ajax/libs/ext-core/3/ext-core.js:
/*
* Ext Core Library 3.0
* http://extjs.com/
* Copyright(c) 2006-2009, Ext JS, LLC.
*
* MIT Licensed – http://extjs.com/license/mit.txt
*/
window.undefined=window.undefined;Ext={version:”3.1.0″};
Let’s try this again…what was [removed] from my previous post was:
[removed][removed]
Last try…[removed] points to
ajax/libs/ext-core/3/ext-core.js
@Richard Walker
The page in the link does use Ext JS 3 Core, but the examples are all Ext JS 4.1. The first grid example links you off to:
http://dev.sencha.com/deploy/ext-4.1.0-gpl/examples/grid/array-grid.html
I believe the examples in the docs app are also fixed now… just tested it myself.
When will it be possible to use ExtJS 4.1 in Architect?
It is a very good article, recommend everybody to read it.
@Rafael Franco : Yeah I need to know what’s their difference.
Thanks guys!
What are the plans for Ext 4.2? Hopefully Ext 4.2 effort will again concentrate mostly on incremental performance and architecture improvements as opposed to adding new features.
@Les,
Plans are not firm yet, but yes, performance is right at the top. Now that 4.1.0 is released, we are looking again at what will have the biggest performance impact with much fewer constraints than we had deep in the 4.1.0 timeline.
I’m looking forward to testing this over the weekend! The previous releases before rc2 completely broke my app written in 4.0.7. I’m curious to see how well it holds up.
Congratulations guys!
What a shocking release. An app that works without fault in 4.0.7 doesn’t even show up properly in 4.1. We just got Sencha’d … again!
I still didn’t saw a comparison for speed between 4.1 and 3.4 for Internet Explorer 6,7,8 which is what our clients use mostly in the financial business.
Can somebody that upgraded to 4.1 give me some benchmarks?
@Ryan
The work my company did in 4.0 has worked fine so far, with no change in 4.1.
That is as of now 57 js files extending Ext JS components as a base with our more complex needs built in.
23 common components built on top of the 57 components.
And over 500 screens using the common and architecture components we made in 4.0.
It is hard to create a way to make every scenario work in which javascript has a million and more ways of doing things.
@Ron – thanks, that is awesome to hear! you just made my day :)
@Ryan – I hope the upgrade guide is of some help in tracking down the issues you are experiencing. As you know, all it takes is one JS error somewhere in the initialization/loading process to make the page stop in its tracks… if you have some specifics, let’s discuss in the forum.
Extjs 4.1 is not for the faint of heart. I’ve been working with ExtJS since version 2 and have written several thousand lines code for it. But a final release may not be mentioned. Sorry.
I hope you quickly come to a STABLE RELEASE and not a FINAL RELEASE.
@Ron: It is the responsibility of the API developer to maintain backward compatibility as much as possible.
@Don: It’s not a Javascript error, as no error is returned. It’s most likely the changes to the layout rendering that is causing significant abnormalities (in multiple applications going from 4.0 -> 4.1).
@Ryan
You may already be on this, but in case it helps others… the first two places to start: 1) the “development” build (ext-all-dev.js) to see if it generates any helpful messages; 2) the new page analyzer. If either of those turn up clues, please provide what details you can on the forum.
I updated the ‘themes’ performance test used several months ago to compare v4 performance to v3. On IE8 there is no improvement vs 4.1 pr1, however, on Chrome 4.1.0 is almost 20% slower than 4.1 pr1.
So 4.1.0 is 56% slower than 3.4.0 on Chrome and 83% slower than 3.4.0 on IE8.
details here:
https://www.sencha.com/forum/showthread.php?131618-4.x-Serious-performance-issues-under-IE-8&p=791429#post791429
Hey @Richard Walker, thank you very much for those results, that was exactly what I was looking for. Now indeed it’s very hard to convince the shareholders to invest in Ext 4.1 when the performance is so weak, regardless of the architecture.
Being ExtJS a framework used mostly for enterprise applications where most clients still use IE6 / IE 7 it’s a shame to keep with a old framework just for the sake of performance, but that’s what most people is looking for anyway.
I’ve been working with EXT JS 4.07 for about 6 months to 1 year now. I’m using a drag n’ drop grid with button and pagination toolbars, customizeable columns, etc… When I upgraded from 4.07 to Beta 2 I saw massive performance improvements in my prototype that uses local/fake data. (i.e. dragging 100 rows over from the left grid to the right grid took 10-14 seconds in 4.07 and 1-2 seconds in 4.1 Beta 2) Today I tried switching out the main library file (ext-all.js) to quickly run a test and see how things held up in 4.1 GA. I was surprised to notice that the same test now took 5-7 seconds to complete with noticeable delay. Not sure if there are other pieces that I need to migrate over… but I’m a bit concerned with the initial performance observations. Have things changed thtat drastically between 4.1 Beta 2 and 4.1 Commercial? Maybe I need to recode the grid/column definitions and local data array, but I’m not holding out much hope that this is the cause of the problem.
@Ryan in my case it was 100% backward compatibility I just dropped 4.1 in with my existing 4.0.7 code with nothing breaking.
And we made our 4.0.7 components coming from 3.1.1 in which we already had a MVC architecture built. So from my point of view it is 100% backward compatible and hence the reason I said what I did before. You can’t make a solution for every single possibility out there in JavaScript.
More structured languages like C and Java maintain rules to govern backward compat a lot better then what you can do in JavaScript a prototype language.
Really it boils down to how well the programmer making the end code understands JavaScript or if they are just copying and pasting with a bit of glue to make something work that they don’t understand.
Most programmers will take the easy way out in today’s world without fully understanding the JavaScript language then complain when it doesn’t work out of the box and they cant understand how to fix it.
@Jason,
There have been a lot of changes since 4.1 Beta 2. :)
One possibility for really “fast” results in early 4.1 releases was a layout failure – once the layout failed, the engine stopped working on the layout. Which made it appear quite fast as you might imagine. Not certain of course.
Your best bet is to see if there are extra layouts running using the page analyzer. It is really easy to make that happen if you manipulate several components at a time.
Again, details are best discussed in the forum.
@Ron: You might be having luck with 4.1 but that doesn’t mean others are or will? Not really sure I follow your thoughts off-topic as to how a dev “understands” Javascript, that’s not really the point here.
@Ryan My thoughts go with how many dev’s take the lazy way out and are fast to point fingers at others without taking a good look at their own code. And my thoughts are going out to everyone that doesn’t search on the forums and/or read the source files and then demands someone to fix it for them when its usually they did something wrong for it not to work correctly. Saying everyone got Sencha’d again is a disrespect to these guys and gals who are doing a lot of hours trying to get this framework out. When in the end its probably something you have misconfigured. Your comment hit a nerve with me in from personal past events.
Now if your getting just a blank screen and using the Loader you need to make sure that is configured correctly I was getting the blank screen with no errors back in 4.0.7. I had the Loader misconfigured so not everything was being loaded correctly. I would check with that first.
@Ron I fully understand the effort from the devs in trying to fix it, but saying from the beginning (almost 1 year ago) that ExtJS 4 would have a better performance than 3.4 only to be 50% slower than 3.4 doesn’t add up to the credibility.
ExtJS 3.4 by itself doesn’t have exactly outstanding performance, specially with Trees and Grids, so I wouldn’t take the step into moving to 4.1 even if the architecture is better to have a even worse experience for our clients.
When I post the question in the forums and even the general wording is that it’s hard to convince the stakeholders that they need ExtJS 4.1 means something is very wrong:
https://www.sencha.com/forum/showthread.php?182093-Migrating-from-ExtJS-3-to-4-how-to-convince
Don’t take me wrong, I love ExtJS, it’s just a pity that this version seems so unpolished.
Rafael,
Ext is far from perfect, but show me another JavaScript library that is as polished and complete as Ext JS 4.1… there’s NONE.
I think you just like to complain (:
@Les, definitely, I didn’t said I was going to quit using ExtJS (Has been more than 3 years now), simply I will stick with using 3.4 even for newer projects.
@Rafael I understand that but I haven’t seen one speed report do a direct comparison of 4.x to 3.4 cause you can’t basically cause 4.x has a lot more components then 3.4 to give greater flexibility. On the screens we are testing right now coming from our 3.1.1 architecture library to 4.1, we are seeing faster results. But coming from our architecture library in 3.4 to 4.1 its about even. And we have added a lot more functionality and a more mature mvc then ext js 4.1 has out of the box.
Also in my company 4.0 was a hard sell that my company didn’t take we waited for 4.1 and just upgraded our 3.1.1 library to 3.4 in the mean time. And don’t take me wrong either I’m one of the biggest clowns my company has but Ryan’s comment hit a nerve with things that I’ve had to tell other developers here in my own company and on forums.
@Ron I have posted a direct comparison of v3.4.0 to v4.1.0 here:
https://www.sencha.com/forum/showthread.php?131618-4.x-Serious-performance-issues-under-IE-8/page13
It states:
Ok, I removed the few additional elements created in the v4 themes example so that the rendered components are the same as the v3 themes example. Here are the results:
Chrome: 4.1.0 is 28% slower than v3.4.0
IE8: 4.1.0 is 48% slower than v3.4.0
@Richard Are the tpl’s the exact same so the elements count is the same across the board of each component? Just saying. =)
Hello, I am brand new to Sencha and am trying it out for the first time.
Unfortunately the tutorials do not seem to work.
I am looking at the following guide:
/extjs-4.1.0/docs/index.html#!/guide/application_architecture
And as soon as you add in the Controllers to the app.js file it stops working with:
Uncaught TypeError: Object Ext.container.Viewport has no method ‘push’: Application.js:160
If you forget about this and try and add the userList view instead, you get:
Uncaught TypeError: Cannot call method ‘substring’ of undefined: ext-debug.js:4483
There is also no explanation about the naming conventions (such as userList vs user.List and what on earth “widget.” is)
Has anyone run through these introduction chapter recently? Is it just me or does this need a whole lot more explanation to get new users to understand the basics?
Kind Regard,
Dave.
@Ron and anyone else who is unconvinced of the performance problems in v4.1.0, please ask Sencha (I’ve asked repeatedly) to publish *their* direct performance testing of these versions. Sencha has told us many times that the goal is to make v4 at least as fast as v3. If they aren’t even testing this, then these promises are questionable at best. If they are testing it, where are the results?
The code used for my themes test has just been posted here:
https://www.sencha.com/forum/showthread.php?131618-4.x-Serious-performance-issues-under-IE-8&p=792669#post792669
Richard,
You will not see 4.1 performance numbers (comparing 4.1 to 3.4) because 4.1 is still slower, so these numbers would look bad.
BUT, this doesn’t mean that Sencha is not working on performance. Ext 4.1 is visibly faster when compared 4.0.7. I still would call release 4.1 a success because (a) it improved performance and (b) a megaton of bugs was fixed.
My guess is that it might take another point release (perhaps two more point releases) to match Ext 3.4’s performance numbers.
What are the limitations of ARIA in Sencha 4.1?
@David Asbury: There is an error in the code snippet under “Creating the application in app.js”: ‘requires’ should be an array, not a string. Line #2 should read “requires: [‘Ext.container.Viewport’],”.
There are some other omissions in the code snippets but it’s easy to fill in the blanks:
– Under “Creating a Model and a Store”: The 3rd code snippet doesn’t make it clear that the store has to be removed.
– Under “Creating a Model and a Store”: The 5th code snippet doesn’t make it clear that the second part should go into app/store/Users.js (not in app/controller/Users.js like the first part).
– Under “Saving data with the Model”: The 1st code snippet doesn’t make it clear what the resulting file should be (the ‘stores’ and ‘models’ config declarations are missing, and other things as well).
– Under “Saving to the server”: data/updateUsers.json must exist otherwise the POST results in a 404.
To answer your questions…
– The alias ‘widget.userlist’ defines a custom type of user-interface component (a “widget”). It allows the application to refer elsewhere to this custom type in an “xtype: ‘userlist'” declaration.
– The ‘user.List’ declaration specifies that a view is described in the file at /view/user/List.js
As a summary, here is what happens at startup:
1) index.html loads app.js
2) app.js declares a controller of type ‘Users’ inside an application folder called ‘app’.
3) The code for the controller at app/controller/Users.js is loaded.
4) The controller declares 2 views: ‘user.List’ and ‘user.Edit’. The periods ‘.’ are replaced with slashes ‘/’ to build the relative paths.
5) The code for the views at app/view/user/List.js and app/view/user/Edit.js is loaded.
6) The view in List.js makes itself known under the alias ‘widget.userlist’.
7) The controller init() function is called.
8) The application launch() function is called.
9) The launch() function declares an item of type ‘userlist’ as a child of the Viewport.
10) Thanks to step #6, the framework knows that an item of type ‘userlist’ is a widget whose code is in List.js
11) The widget is created and attached to the Viewport.
We hope these explanations will help you to better understand the value and the power offered by the Ext-JS MVC Application Architecture. If you have any other question, please don’t hesitate to ask or lookup for responses in the forum at https://www.sencha.com/forum/index.php
Thank you for reporting these errors. The guide will be updated soon.
Congratulations on performance improvements.
However there is a newly created issue I think, The dynamic callParent().
In every method, it’s a really good idea to help ExtJS users call the superclass one, easier and shortly.
But it can loose the performance and get longer and harder to deal call stacks.
According to my experiments in similar situations I believe that the previous way of referencing parent methods in earlier versions(3.x and before) was more effective in gaining lightness because of straight calls without any delegators.
So callParent() is just a good tool to use with beginners.
It’ll be a good idea to use the old way in your own codes (ExtJS team generated Components) which will be result in a higher performance.
@Pierre Saslawsky
Thank you so much for your answer Pierre!
I now have got the sample app running correctly, and thanks to your explanation have a better grasp on the naming conventions and how this maps to the source files.
I would strongly recommend you add something like your post to the getting started docs as I felt that there is a knowledge gap there about why things are called what they are, and the basic structure of what is happening. Also someone should so what it looks like you just did and review the code snippets to make sure they work!
Thanks again :-)
I am evaluating Sencha for use in our company and getting the same errors as David Asbury. The fix suggested by Pierre for the first error (using array instead of string) works to solve it. But the second error, when adding the userList view, still remains. I have tried several other similar suggestions from the Sencha forums but they do not fix this bug. I am working under Mac OSX but don’t see how that could be problem.
@radman: Both errors were solved by the fix I suggested so maybe you are seeing something else and we would need more information to understand it. However the official company blog is not the best place to solve technical issues. Could you please post a description of the problem on the ExtJS Bugs Community Forum at < https://www.sencha.com/forum/forumdisplay.php?80-Ext-Bugs>? Please join a step-by-step descrition to reproduce the problem and the exact error messages that are reported in the console. Thanks!
Sorry for posting in wrong place — will rempost in bug forum with more info shortly.
I’m new – 2 weeks, and like others am having a lot of problems getting started.
1. Can you please fix the “View” links bottom right on the Ext 4.1 download page so we know if there has been any fixes or patches? Because the examples, videos, and guides are mostly broken. Also for Architect 2.0.
2. Can you please put together a video or example of a complete working application in Architect 2.0 AND Ext 4.1 – w/ login/menu/mysql tables – joined tables … in 2 panels with relationships.
3. Every single sample application / tutorial that Sencha has uses data either embedded in the application itself or uses .json files … how is this going to work in the real world? It doesn’t. Nobody builds web applications like this.
4. Is there a versioning system for the documentation so we can find out when the links are fixed?
5. I’ve completely given up on Architect, and am just about to give up on Ext-JS. I have literally resorted to begging for examples from forum users and copy/pasting code to try to build my tiny application. (And even then my Request for sample apps post was moved to the Q&A forum).
@Les – Smart Client from Isomorphic is by far more polished and complete. The data sources tool (amazing), the console, the admin control tools, and the visual developer are light years ahead. But it’s expensive, no community to speak of, and support is almost non-existent. The forums are dead. Their server side implementation is genius – complete with Ajax/application installation and multi-developer support.
We decided to go with Ext JS due to the community / forums / activity. But after 2 weeks, it’s obvious almost every post was originated in 2009 and most people are using Ext 3.3. That’s understandable, but where is the Sencha support/tutorials for 4.x? It’s nearly impossible to get started with 4.1.
Hi. I would like to simply find out about the following matters:
1. Does ExtDesigner work with Ext4.1?
2. Does Sencha Architect 2 work with Ext 4.1?
Thank you in advance…
Your fan forever :)
@Ghostly:
The documentation contains 25 guides (http://docs.sencha.com/ext-js/4-1/#!/guide), 25 videos (http://docs.sencha.com/ext-js/4-1/#!/video) and close to 150 sample applications covering almost every aspect of the framework (http://docs.sencha.com/ext-js/4-1/#!/example). The source code for these applications can be found in the ‘examples’ folder of the SDK. Running each application and looking into its source code is an excellent way to get started with Ext JS 4.1.
@Michael:
Indeed the documentation contained some errors and omissions that will be fixed soon. However the full and functional source code for the MVC application can be found in the Ext JS 4 SDK download, inside the examples/app/simple folder.
Hi Guys – Its exciting to hear the new release. But its also scaring for people like us who already uses Ext JS, the reason is everytime, there is something changing in the way we use Ext JS.
It would be nice if we could mention what might change in the next version so that we can be cautious in using some of the API (something like ‘deprecated’ feature in Java). Also it would be great if it could be backward compatible without using a compatibility layer (excluding the deprecated feature). I am sure this would be a concern from most of the developers.
I agree that an official 4.1 vs 3.4 comparison is something i am looking for. I assume that many of us use ExtJS in a corporate envrionment where we render sortable lists, trees and data entry forms. A simple side-by-side comparison of a sortable grid with 100 rows and 20 columns (10 visible, 10 hidden by default) over a server side store and sorting of 10,000 rows would be great (e.g. to emulate showing a report of all clients, their revenue and metdata like address, country, etc). Side-by-side measured for initial load time and sort time in every major release of every browser supported on Windows and Mac OS X. Special focus on IE7 and IE8 on Windows XP on a bit older business class notebook (let’s sell Dell Latitude D820).
Plus an online demo that we can show around. Give us something we (and our managers/stakeholders/clients) can see, experience and relate to. Even better would be a more complete business app including trees, edit forms, charting, etc. Show us a large, business typical app in 3.4 and 4.1 (both being feature and design wise identical) and on top one version with more and 4.x exclusive features. Show us how 4.1 allows you to buld a better app for users (not a clear MVC and plugin model for devs). That would help me sell this internally – and it would help you make business.
This is a GUI development framework. You can’t build an application with Ext JS 4.1 or Architect 2.0. It’s impossible. You need an actual web application framework behind this – like Symphony, YTII, Joomla/Fabrikar, Ruby, cakePHP, codeignighter …
http://www.phpframeworks.com/php-frameworks/index.php?id=19
I’ve spent a solid month evaluating this product, I’m 100% confident in my evaluation.
None of the guides/tutorials/examples actually work – you can’t add a record because there is no database. Because there is no application – it’s hocus pocus time.
MVC is stupid – It’s actually SMVCPA – Store, Model, View, Controller, Proxy, Application – the Application part is what’s missing in Ext JS 4.1. The rest can be coded in 1 script. Don’t waste your time creating 5 directories for every application that doesn’t work. Ridiculous comes to mind.
@Michael
You nailed it. I have three clients who would love to see that. It would have saved me a month of work.
The real genius in your post however is that having this business application for each version would allow us to quickly see what had to be changed in order for the app. to run on a new version of Ext JS. A simple diff could quickly get to the nitty gritty.
I would really love to see this, so would my clients.
@ghostly: There are plenty of examples, documentation and tutorials online under the documentation line on the home page. Instead of complaining….RTFM!!!! It’s really not that difficult. Sencha has by far the most extensive documentation for any framework out there and is a great diversified library for creating GUIs for most any situation.
No one is going to write your app for you!! If you still don’t get it, then take a training course provided by Sencha.
Also, don’t tell people not to use MVC when you know nothing about it. Apparently you don’t appreciate clean, separated code. Why don’t you actually try looking at some of the examples and examine the code behind them before you start ranting childishly.
@Tad
Most of them don’t work in Ext JS 4.1 or Architect 2.0. All of them are very simple – zero necessity for MVC.
I was paid to evaluate Ext JS. Two weeks into the process 4.1 released. This accounts for the majority of issues. Links weren’t updated, code wasn’t updated, serious issues with Chrome 17 & 18.
That being said, I have over 50 Ext JS examples / sites / test applications on my local web server. My evaluation is 32 pages long. I was the number one poster on the forums for 2 weeks running. I have 32 years experience in application development. Twenty years in web development. I’m extremely thorough.
I assure you, I’ve tested every single tutorial, sample application, concept application, and example – including the video tutorials. I’ve read every single page of the documentation for Architect 2.0 and Ext JS 4.1.
The third largest issue I ran into, after 4.1 bugs and simplistic examples, was simply that there is no SVN access for non-subscribers – the INT record ID bug killed many of my examples, Chrome 17 & 18 bugs killed many – these things had been fixed, but there was no news of it on the forums. There were no errors.
I stepped into this evaluation at the wrong time, admittedly. But, by far, the largest complaint that I have is that there are no examples of a working business application to be found – anywhere. It’s all snippets. There are no examples of how these snippets come together.
Over half of the new stuff is specific to Sencha Touch – fourth largest issue.
I’m classifying this whole experience as bad timing. Ext JS is obviously a great product – teething pains with 4.1. It happens to the best of us.
My clients and I are simply going to take a break from Ext JS and see how things pan out at a later date.
Firstly I would like to say that I am doing a prototype of an application screen for my application suite. It ROCKS. I am doing things with such ease and such speed hat I simply cannot believe it.
A lot of people are looking for a complete application example, but I tend to disagree with that! If Sencha had to do that, then all of us would be complaining that it is not the correct architecture etc etc..! Each to its own, and all I can say a lot of experimentation, a lot of forum reading, a lot of contribution will take you a long way!
I am developing versin 2 of my application and I am already doing things that took me 1 month in virtually 1 week! And this is due to the fact that I have to experiment etc..!
I must also say that I work by myself and as such I don’t know how it would influence a development team colaboration, but it will all depend to YOUR application architecture.
Those who are taking a break will be missing out on a lot..!
Take care guys and thank you for the amazing work done in this framework…
@Ghostly: Well put. I definitely agree it would be nice to have more of a business application example or something that’s more application based rather than just snippet components. As for SVN access, I just don’t get why you can’t pay for a license. It’s not that much money and you’d have access to both SVN and premium support / forums. If you’ve been using Ext JS for quite some time (I’m talking 2.x era) than you’d definitely see the significant advancements since then. Things have come a long way and I’m sure some of these things will be resolved in the future. Take the infinite grid for example, how long have people been asking for that? Yeah it took a while, but I’m grateful it’s there now and done the right way.
I disagree on the zero necessity for MVC. For me at least, I can reuse any of these classes I’ve added in multiple applications. I support multiple sites at my work that do have overlapping views, stores, etc.. With that being said, I find it very useful to be able to just require the class I want to use and then just use an xtype config (i.e if a view) to inject it into my application. It has saved me a great deal of time and effort and if I need to make a global change to a class like using a different url for a store I only have to make it in one place.
@Ghostly: Forgot to mention, while the release notes for this version seem to have a broken link on Sencha’s site, they are in fact in your download copy that you can view:
Congratulations, this version is very good, you have done a great job in design and implementation (not to mention bug fixing).
@tad
Let’s focus on the imperatives. We need a business class example.
Let’s just focus on that…. and nothing else.
We are in agreement, your first sentence and my prognosis…. so let’s just focus on 1 thing.
I don’t have anything, do you?
@Ghostly: I don’t think it’s imperative that we have one. It would be nice, yes. But it’s definitely not a show stopper. Every use case will be different so a business example won’t suit everyone’s needs which is probably why they haven’t created one as of now. I do find the App Architecture Tutorials have been really useful for something like this.
Excellent, Good work
I’ve download it by giving my email address and work fine.
Thank
I like the way most of the work on layouts has been to make them faster by avoiding browser reflows.
Congrats Sencha Dev on the release. I’m sure there has been a lot of hard work put into this. With regards to the elephant in the room, performance. Isn’t it about time 4.x was dropped and instead start fresh on 5.x? I love EXTJS but here’s the issue, performance is absolutely fundamentally key. The product is almost pointless without the promised performance. Look at it like this, how many cars do you think Ferrari would sell if they put a 2.0L diesel engine in there sports models!
In the absence of 5.x (assuming it gets the go ahead and it out performs 3.x) can Sencha please put some devs back on 3.x & 2.x and give the community what they need. A high performance production ready framework.
Regards
MrSparks
MrSparks just hit a home run. Features mean *nothing* when the performance precludes usage. 4.x performance has been acknowledged as inadequate repeatedly, and a resolution promised. Please put this issue at the top of the list and get it done. In the meantime, please do as promised and now fix the open issues with v3.4. Thanks.
Good that you shared such an information i am glad that i visited this blog, Your solution is perfect and solved the firefox problem.
Excellent! Thank you.
I love EXT. It rocks.
Trying to upgrade from 4.0.5 to 4.1 on our enterprise web application. But right off the bat I’ve noticed that there is a race condition with the Ext.Loader singleton class. (for-loop at line: 5784 of ext-all-debug.js)
This results in the loader making duplicate requests and then the Loader.numPendingFiles being a negative number and therefore the controllers in the applications controller array are not being initialized, halting the execution of the launch method in the application.
Setting Ext.Loader.syncModeEnabled = true; is a band aide for now. But there is obviously something fishy going on here. I’ve noticed there are many changes in the Loader and EventManager classes, so its hard to narrow down the issue.
Any ideas?
There is an issue with circular “requires” statements that the Loader previously handled more graciously but now results in the behavior you are describing. I would look for loops in your requires statements – beyond that, I would discuss this in the forums.
@tad
think it is actually imperative.
It is definitely a show stopper.
If this web application framework can’t actually produce a web application – that’s a show stopper.
The tutorials are lame / old and don’t even match the API documentation. Nor do they even work.
That’s called a “Show Stopper” by all definitions of the phrase.
@tad
Furthermore, if a business class example won’t suit everyone’s needs, they how can this possibly be more than entertaining? We’re all in business here. For those just screwing around, they don’t pay $800 license fees.
This is a business class application – so where are the working business class examples?
Sencha Touch – mobile web applications. Period.
That’s it. There is nothing more to be seen here. It’s just a javascript front end for mobile applications.
Witness the app. gallery – it’s 100% mobile sencha touch applications.
When I use 4.0.7 version, there is loading mask show when I load the data store. But when I use 4.1 version, there is no loading mask. How to show the loading mask when data store is loaded?