ExtJS Dependencies (Performance Optimizations)

[plalx]

After digging into Google Closure Library, I discovered many great features that ExtJS developers would benefit.
One of them being the goog.require functionality together with their Dependency Calculation Script that would boost performances ExtJS applications as well as simplifying the task of maintaining dependencies between JS classes.

Basically, goog.require allows you to specify scripts that needs to get loaded before your code can run.
This removes the overhead of adding a new script tag manually everytime you create a new class.
It also ensures that you won't forget to add this dependency script, as well as removing unused scripts.

E.g. (I wrote the example as if the functionality was supported by ExtJS)

 
 
Ext.ns('myns.widgets');
 
//This line will automatically add a script tag loading the JS file defining the Ext.Toolbar class.
Ext.require('Ext.Toolbar');
 
myns.widgets.SuperToolBar = Ext.extend(Ext.Toolbar, {...});

While including each JS files seperately is what we want when developing and testing, it's not really an efficient solution for a production environment since a round trip to the server will be needed for each dynamically added <script> tags (as we already know). This is where a dependency calculation script would becomes useful. It would browse all files looking for Ext.require statements and automatically generate a single JS file containing all required scripts. We could then compress this file, making sure that all Ext.require calls get removed as well, and we would be ready to roll... No more js2b files to manually maintained or manually added script tags...

I think Sencha team should really think about implementing such a functionality and standardize it's use making the whole community benefit from this!

more info -> http://www.sencha.com/forum/showthre...S-dependencies

[Mjollnir26]

FWIW there is a lib providing similar functionality over at

http://requirejs.org/

Anybody here tried both of them?

[papandreou]

For our own code we're using a homegrown dependency system that also reads ext.jsb2 in order to provide an abstraction on top of it. It sort of works, but it would be much, much nicer if Ext's internal dependencies were made explicit so that you would only get the parts you actually need. Right now we have to go through the Ext files manually and exclude those we don't need in our build for a specific project. It's cumbersome, error-prone and has to be redone for every major Ext release -- and, again, for every Ext-based project.

I'm aware that switching to proper dependency management would require a lot of work on the Ext developers' part as there are a lot of mixin constructs and private classes that aren't easily translated to a dependency tree. For instance: Ext.grid.GridView.SplitDragZone is a private class declared at the bottom of src/widgets/grid/GridView.js. It causes a JavaScript error if the drag and drop package isn't included, even if you don't use the d'n'd facilities of the grid.

Best regards,
Papandreou

[joeri]

Using a custom built dependency loader for scripts and stylesheets here also. Not using a dependency loader if you're building suite-style web apps is simply not scalable.

I don't know if it makes much sense to split ext-all up into packages. If it is split up, it would probably be best to do it very granularly: "core", "gridandtree", "extras", where the scope of what's in "core" is roughly similar to what's in Sencha Touch. This way Ext can grow in the "extras" package without it affecting performance of loading the core library.

[plalx]

@joeri I think the goal would be to push the granularity as far as the class level, allowing fine-grained dependency management. The only piece of logic that would have to be loaded first would be the 'require' functionality logic as well as native class (Function, Array, Object ...) augmentation code. It it is sure that it would probably have a little performance drawback when testing, but performances would be way better in production once the code is all compressed, since the size of the library would be reduced to what you need only!

[joeri]

Ah, I get the difference. You're talking about server-side precompressing the library to only those requirements absolutely necessary for the application. I'm talking about client-side loading of code on-demand.

[papandreou]

@scarsick +1
Yeah, at the very least it has to be class-level, and perhaps even more fine-grained than that. It should be possible to choose whether to include(/require/depend on) rarely used mixins for specific classes.

To elaborate on my above example, column resizing and reordering in Ext.grid.GridPanel would be a good candidate to move into a mixin because it adds so much extra weight to projects that don't otherwise need drag and drop. The enhancement itself would then require the core drag and drop features it needs.

[mschwartz]

For ExtJS 1.0 there was a WWW page on the site that let you build your own ExtJS with just the bits and dependencies you desired. That's not been on the site in ages though.

There are huge performance penalties in the form of extraneous requests for .js and css (yes, Ext component have CSS dependencies, too!) files. If some bootstrap loader were the only thing loaded into the page before onReady() and then all the various required components automatically loaded on demand, there might be several hundred requests to the server before the application is even ready to do anything.

Perhaps you want something on the server side that can build an ext-custom.js (and ext-custom-debug.js) based upon your needed components and their dependencies. This would work quite well for a single page application, but if you're loading a slightly different ext-custom.js on several pages in your application, the user experience is lesser because you're fetching a lot of the dependencies over and over when the user hits another page. I mean, why fetch Ext.Element.js multiple times?

[papandreou]

Yeah, we're talking about several concepts here:

1) Explicit dependencies between Ext classes (ext.jsb2 just doesn't cut it)

... As well as the features you can build as soon as such a hierarchy exists:

2) Lazy loading of dependencies
3) Pre-bundling (or even on-demand bundling) of JavaScript and CSS at the server

[plalx]

In response to @aconran "We're working on a bunch of stuff in this regard right now. More details to follow " in this thread.

When do you expect details to be available?