deferred initialization

[MichaelOstrovsky]

stever: as you faced this problem , i wanna ask you ( other's are welcome to answer too ofcourse ):
let's say i'm VERY determined to have this functionality ( deferred script loading & deferred initialization ).. which is the best direction :
1. yours , shown on your post
2. wrapper
3. 'envelope' ( my latest proposal )
4. purchasing ultra-expensive account and pushing the developers to make it
5. giving up and not wasting my time on it

?

[stever]

smart serverside implementation can merge the required files into one, minify it and cache for further similar-requests.

Yes and no. Since we are talking about speed, I assume a couple of things. One is that the JS is coming from CDN (which is all static files). When you build from svn it creates other files (like a "grid" file that merges all the grid related files into one). So rather than file by file (class by class) dependency analysis, you can do dependency checking on a package level.

I don't like the system of having the client and server communicate which classes are already on the client, and it really does no good in caching them (from a cache utilization perspective).

You can still lazy load on show if you want, by having a container for it. Same way you would do it in the unpatched current version of ext.

by defining somewhere the relations

Ext provides that in SVN.

[stever]

stever: as you faced this problem , i wanna ask you ( other's are welcome to answer too ofcourse ):
let's say i'm VERY determined to have this functionality ( deferred script loading & deferred initialization ).. which is the best direction :
1. yours , shown on your post
2. wrapper
3. 'envelope' ( my latest proposal )
4. purchasing ultra-expensive account and pushing the developers to make it
5. giving up and not wasting my time on it

?

1 & 4.

On the dynamic loading of classes:

a) container knows that it must check and load if needed the classes. this is quick and dirty, has lots of issues, and is not automatic.
b) SamariJack has already done some stuff for loading classes on demand (a long time ago). That is partly why many of the ExtJS classes have changed to the 2 param Ext.extend from the 3 param version, which makes the interception of class creation a point at which a sync load could occur.
c) Alter the createComponent such that when an xtype is not registered, that it asks the server to download it, or calls a client side handler to do so (you might pre-register all the known xtypes and give a routine on how to load them.

The dynamic loading of classes is orthogonal to the deferred creation of them. However, they can be combined in some helpful ways. For example, when moving the items to deferredItems, we could iterate and see what xtypes there are that are not currently loaded, and start loading them since we know that they may be used in the very near future. I'm going to take a look at this approach.

[MichaelOstrovsky]

i just looking for a good way to not overload the browser. hundreds of big packages ( ext ones / application ones ) does that. if it was unnoticeable i wouldn't bother. but it take around 15 seconds to power up my current one ( not from browser cache ), with gzipping, on a relatively powerfull computer. the application slowness is really noticeable too.
Maybe i'm looking at the wrong direction for solutions

and stever- thanks very much for the support. i really appreciate that. +1

[stever]

i just looking for a good way to not overload the browser. hundreds of big packages ( ext ones / application ones ) does that.

Hundreds? the Ext breakdown is into 10 files, I think.

if it was unnoticeable i wouldn't bother. but it take around 15 seconds to power up my current one ( not from browser cache ), with gzipping, on a relatively powerfull computer.

What takes 15 seconds, exactly? Can you post a Speed Tracer profile so we can see what it is you are talking about?

[MichaelOstrovsky]

"Hundreds? the Ext breakdown is into 10 files, I think." => I meant components.. many of which are not required by the app most of the times. probably i over-counted it..

speed & load tests:
130 js files, 620kb of downloaded data ( 1.5 mb saved using compression ).
50 mb ram in use ( before any actions and activex loaded ) - deferredrender used.
time to download and initialize the scripts: 8 sec. ( from server on local network. from website it takes much more, especially for low-connections and weak computers ).

total initialization time ( with loading initial data , css, and all ) is around 13 sec.

I have extensive nesting ( tabs , accordions, border-layouts which are rarely expanded, toolbars, card-layouts etc. and many of the components require specific big extensions which are not used by any other ( gmaps in only one tab, charts only in another etc ). its going to be a big backend management system.

and the big problem is- it's going to ( fortunately ) be extensively used by telco's which are sitting on thin-clients ( weak,small computers ) and restricted to ie6

[stever]

130 js files, 620kb of downloaded data ( 1.5 mb saved using compression ).

You download 130 js files to the client?

time to download and initialize the scripts: 8 sec. ( from server on local network. from website it takes much more, especially for low-connections and weak computers ).

I can load ext-all.js from a server far far away in much less time. Sooo.... how long to load? How long to parse? How long to init the lib? How long to init your scripts?

total initialization time ( with loading initial data , css, and all ) is around 13 sec.

I mentioned showing a Speed Tracer profile for a reason. This "summary" is meaningless for helping you. I have no idea if loading is taking a long time or rendering. Maybe it is a layout issue. Or painting. Or...

I have extensive nesting ( tabs , accordions, border-layouts which are rarely expanded, toolbars, card-layouts etc. and many of the components require specific big extensions which are not used by any other ( gmaps in only one tab, charts only in another etc ). its going to be a big backend management system.

With lots of hidden stuff, my deferred creation patch would help a lot. For me: 20s to <1s.

and the big problem is- it's going to ( fortunately ) be extensively used by telco's which are sitting on thin-clients ( weak,small computers ) and restricted to ie6

Can't help with the IE6 part, but at least IE6 has a fast currentStyle rather than the more accurate getComputedStyle of other browsers (including IE9).

[alien3d]

"Hundreds? the Ext breakdown is into 10 files, I think." => I meant components.. many of which are not required by the app most of the times. probably i over-counted it..

speed & load tests:
130 js files, 620kb of downloaded data ( 1.5 mb saved using compression ).
50 mb ram in use ( before any actions and activex loaded ) - deferredrender used.
time to download and initialize the scripts: 8 sec. ( from server on local network. from website it takes much more, especially for low-connections and weak computers ).

total initialization time ( with loading initial data , css, and all ) is around 13 sec.

I have extensive nesting ( tabs , accordions, border-layouts which are rarely expanded, toolbars, card-layouts etc. and many of the components require specific big extensions which are not used by any other ( gmaps in only one tab, charts only in another etc ). its going to be a big backend management system.

and the big problem is- it's going to ( fortunately ) be extensively used by telco's which are sitting on thin-clients ( weak,small computers ) and restricted to ie6

adobe air + extjs ? Loading in local should be faster.Or ask client to remote desktop server to access your application online.server should have latest ie.

[MichaelOstrovsky]

Thanks guys. so, bofore jumping on anything, i'll need to analyze exactly the bottlenecks. ( loading/initializing/rendering/layouts etc ), and then fix them one-by-one.

let's return to the subject of the thread - deferred loading and initialization. i'll try to make some re-usable solution, based an all the info i have now ( thanks to you all ).

the solution will consist of two parts:

1. dynamic script loading mechanism based on xtype-relations and server-side concatenation, minifying , obfuscation ( & scrambling ) and caching . the cached scripts will be ready-to-use without passing through php ( file with cached script links will be provided to the app , just like the direct api . it will be independent of the deferred initialization, and may be used as-is.

2. reusable deferred-initialization utility , which will use (optionally) the dynamic-script-loading . it will fit common component which hide functionality : card-layout ( with all it's overrides like tab panel etc ), accordion-layout, border-layout ( w. collapsed regions ), etc.

[MichaelOstrovsky]

found good base for the first one : http://requirejs.org/