View Poll Results: Do you think the ExtJS developers would benefit from a 'require' functionality?

Voters
60. You may not vote on this poll
  • Yes, it would be great!

    52 86.67%
  • Maybe, I am not convinced...

    7 11.67%
  • No, not interested

    1 1.67%
  1. #1
    Sencha User
    Join Date
    Aug 2009
    Posts
    480
    Vote Rating
    1
    plalx has a spectacular aura about plalx has a spectacular aura about

      0  

    Thumbs up ExtJS Dependencies (Performance Optimizations)

    ExtJS Dependencies (Performance Optimizations)


    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)
    Code:
     
     
    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

  2. #2
    Sencha User Mjollnir26's Avatar
    Join Date
    Oct 2008
    Location
    Germany
    Posts
    152
    Vote Rating
    0
    Mjollnir26 is on a distinguished road

      0  

    Default


    FWIW there is a lib providing similar functionality over at

    http://requirejs.org/

    Anybody here tried both of them?

  3. #3
    Ext JS Premium Member
    Join Date
    Feb 2009
    Posts
    57
    Vote Rating
    0
    papandreou is on a distinguished road

      0  

    Default


    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

  4. #4
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    555
    Vote Rating
    27
    joeri has a spectacular aura about joeri has a spectacular aura about joeri has a spectacular aura about

      0  

    Default


    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.

  5. #5
    Sencha User
    Join Date
    Aug 2009
    Posts
    480
    Vote Rating
    1
    plalx has a spectacular aura about plalx has a spectacular aura about

      0  

    Default


    @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!

  6. #6
    Ext JS Premium Member
    Join Date
    Aug 2007
    Location
    Antwerp, Belgium
    Posts
    555
    Vote Rating
    27
    joeri has a spectacular aura about joeri has a spectacular aura about joeri has a spectacular aura about

      0  

    Default


    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.

  7. #7
    Ext JS Premium Member
    Join Date
    Feb 2009
    Posts
    57
    Vote Rating
    0
    papandreou is on a distinguished road

      0  

    Default


    @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.

  8. #8
    Sencha - Community Support Team mschwartz's Avatar
    Join Date
    Nov 2008
    Location
    San Diego, Peoples' Republic of California
    Posts
    2,053
    Vote Rating
    17
    mschwartz will become famous soon enough mschwartz will become famous soon enough

      0  

    Default


    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?

  9. #9
    Ext JS Premium Member
    Join Date
    Feb 2009
    Posts
    57
    Vote Rating
    0
    papandreou is on a distinguished road

      0  

    Default


    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
    Last edited by papandreou; 27 Oct 2010 at 7:37 AM. Reason: typo

  10. #10
    Sencha User
    Join Date
    Aug 2009
    Posts
    480
    Vote Rating
    1
    plalx has a spectacular aura about plalx has a spectacular aura about

      0  

    Default


    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?

Similar Threads

  1. ExtJS Grid: Poor performance with latest ExtJS version
    By developer0xff in forum Ext 3.x: Help & Discussion
    Replies: 2
    Last Post: 10 Dec 2010, 11:37 AM
  2. ExtJS Performance
    By extshrek in forum Ext 3.x: Help & Discussion
    Replies: 5
    Last Post: 17 Feb 2010, 7:36 AM
  3. Extjs performance
    By lassaad in forum Ext 2.x: Help & Discussion
    Replies: 1
    Last Post: 15 Oct 2009, 10:13 AM
  4. performance for using Extjs
    By susanxu in forum Community Discussion
    Replies: 5
    Last Post: 30 Jun 2008, 7:54 AM
  5. performance for using Extjs
    By susanxu in forum Ext 2.x: Help & Discussion
    Replies: 2
    Last Post: 27 Jun 2008, 9:02 AM

Thread Participants: 10

Tags for this Thread