9 Jan 2012 12:55 AM #1
4.1 Beta Performances
4.1 Beta Performances
Did you tried the 4.1 b ? how is it for you ?
I work 3 days to fix many problems to update my app in 4.1 beta (there still a lot of bugs, but I can use it). Now it does'nt work anymore with 4.0.7 but the result is slower (I don't run benchs, just using the app). It seems slower in all browsers.
How is it for those who test ?
Thanks for responses.
9 Jan 2012 7:09 AM #2
I can't get my two existing apps to load with 4.1 B1 with the existing bugs. Started sandboxing with a new app and got as far as I could reporting what I could along the way, but the bugs finally pushed me back down to 4.0.7.
But, I have high hopes for 4.1 B2.
9 Jan 2012 1:59 PM #3
What kind of bugs are you having? I have migrated our large app to 4.1. Been through a lot, feel free to post and we can figure it out.
9 Jan 2012 2:34 PM #4
Thx for any help you can offer.
A couple of bugs I reported on the bugs page already. One was when adding CSS dynamically (which my login window does, sadly) and having that in play breaks the login which has some persisting effects all by itself.
But, if I take that out, the forms are all empty. A height/width is there where the form fields and fieldcontainers once were, but they don't appear to be rendered.
And anywhere where there was a form field that is rendering its width is like 30-100 px where in 4.0.7 they were the width of the owning container (under anchor 100% layout setup).
9 Jan 2012 2:53 PM #5
In the second app I keep getting errors of 'el is null'. Seems to be when the viewport is instantiated and it's adding each component.
el.addCls.apply(el, arguments) * line 63823 in the Ext-all-dev-w-comments file
The cls being added each time is: x-docked.
9 Jan 2012 5:20 PM #6
I uploaded 4.1.b1 to my server and tested my app... It seemed to break everything. I didn't want to waste much time troubleshooting it... especially since it's a beta. Under the beta, my "simple" login form failed to render and my application failed to startup completely.
I designed the GUI in Designer (XDS) and wrote the business logic when I was satisfied with the layouts. This is a CMS/blog manager that I have been developing since the ExtJS 3.1 days.
At this point, I'll wait for the general/stable release of 4.1 before uploading ExtJS to my server.Perfection as a goal is a nice idea that can point one in a specific direction. However, since "perfection" is an ever changing (evolving?) and moving target, one must admit that perfection can never be obtained...
When in doubt, check the d4mn source code!
And here are my terms...
- I don't care if you use my source code. (Known as "Code.")
- I don't care if I get any monetary compensation.
- I do care to receive credit for Code provided. So, please keep my name in the comments for Code provided.
- Code is provided without warranty "AS-IS" and I claim absolutely no warranty nor liability to the quality, security, and run-ability on any platform.
- By using Code, you accept all risk inherit with Code regardless if Code has known and yet to be discovered bugs.
- You are welcome to change and improve the Code to best meet your needs.
- I don't care if you use the Code in a commercial or open-source project.
- You are not required to contact me prior to using the Code.
10 Jan 2012 7:56 AM #7
There does not seem to be any though toward backwards compatability. We had the same issue with even the most simple login screen not working. It will take us at least a week to get things working so/so. Some of this is to be expected given the amount of customizations that were required to the base ExtJs code while some of it is just plain poor development practices by Sencha.
That being said, it takes 1980ms (on a slow browser/hardware platform) to make the viewport visible under 4.0.7 and about 800ms under 4.1 b1. Given that out slowest platform is 6x slower than this that platform will go from 12 seconds to 5 seconds. Still not good but better. 2.1 was significantly faster but we were not attempting a pure JS solution for that.
10 Jan 2012 11:36 AM #8
- Join Date
- Nov 2008
- San Diego, Peoples' Republic of California
- Vote Rating
We have a shipping product that's been continuously developed for the past 3 years, first using ExtJS 2, then ported to ExtJS 3. When 4 came out, I looked at the issues to port to it, and we decided against it, and it didn't take much time/thought. The performance was not part of the consideration.
However, the existing ExtJS 3.x extensions we made and leeched from the forums were; porting those would add a significant amount of effort, cost, and time to the porting task. The number of overrides we made to get everything to work to our quirky standards would all need to be understood and ported.
I admit I haven't spent much time stepping through the ExtJS 4 code, or even really writing much for it.
I wanted to show what SilkJS could do, so I did an ExtJS 3 and ExtJS 4 demo and put it on github. The ExtJS 3 demo was a brief and smooth effort. The ExtJS 4 demo took a bit longer because I had to refer to the API and examples to get things even working. That's not a big deal, but my experience while running the code in my browser was almost painful. It crawled. It even made my browser appear to lock up for seconds at a time, or just run slowly (Google Developer Tools, too).
This is just a bit of constructive customer experience I'm relating above.
I do not mean to be critical of the 4.x effort in the least. They have some brilliant new ideas and ways to do things that prohibited legacy support (backwards compatibility). They felt starting fresh with an almost entirely new code base was the best strategy; I wish Microsoft would have figured out to do this with Windows many versions ago .
I'm willing to suffer with the performance problems over the long haul. I mean, Sencha is using their own toolkit to do their client work so they must realize they have work to do to get it right. They're a bunch of really smart guys, and it's just a matter of time, IMO.
My big concern is that 3.x isn't going to get the attention it ultimately needs. 3.4.0 came out a long time ago, and I don't see much discussion of updates, fixes, and so on. Yet I have this legacy application that depends on 3.x, and I'm sure there are many others out there in the same boat.
You see, my Google Chrome magically updates itself. One day it's version 11.x, the next it's 12.x. One of these version changes, some browser detection and specialized code in 3.4.0 isn't going to work right with the new Chrome (or Firefox or IE or whatever), and I'll be flooded with customer complaints that their software stopped working (magically). I don't really care if they add new features to it, but it does need to be maintained. IMO.
10 Jan 2012 2:34 PM #9
Completely agree with the concerns about 3.4.x support as stated by mschwartz. I can't use 4.x in it's current state as performance is unacceptable. If Sencha fails to provide the necessary, timely support to 3.4.x they will effectively orphan a sizeable portion of their paying customer base. Very much hoping this does not happen...
11 Jan 2012 12:37 AM #10
Given that we're just talking about bugfixes on 3.4.0, couldn't this just be a community effort? I don't see the need for Sencha to officially support that version if we're just talking about an override here or there. We could just have a thread listing a set of overrides that fixes all the known bugs with 3.4.0.
I've posted my overrides recently:
On the other hand, this is where it really shows that ExtJS isn't a true open source product (developed by the community for the community). It would be a much more stable product if people could freely submit patches (overrides) and get them checked in to the core. Sencha could set up a CLA that anyone can sign to submit patches with appropriate copyright transfer.