View Full Version : Is there an equivalent to dojo.load for ExtJS?

9 Nov 2010, 11:54 AM
Hi everyone, our current flavor at where I am now is Dojo, and it's wonderful that we can load classes and files that only need to be used using dojo.load, however I would like to use ExtJS on some projects for its GUI features but my concern is having to load the whole library or manually calling individual Javascript files from the library. Does anyone know or is there a method similar?


10 Nov 2010, 3:20 AM
From what I remember of my Dojo days, you still had to load dojo.js, dijit-all.js and any individual dojox scripts you might need (if not using their CDN). The 'dojo.require("dijit.Dialog")' statement in the load event where just instructions to Dojo to scan the content and instantiate any widgets defined via the HTML attributes. So, in short, I don't believe it was actually dynamically loading only the widgets/modules used.

For what it's worth, I converted a sizable web app from Dojo to Ext and noticed a markedly faster load time after doing so.


10 Nov 2010, 3:53 AM
1. Ext has an Ext.Loader class to load javascript dynamically.
2. Ext does not have a module system, so it doesn't know which files it needs based on the classes used.
3. If you want to reduce loading time by not loading ext-all, I recommend building a distribution yourself (using JSBuilder2 with a modified ext.jsb2) instead of trying to load files dynamically. The result is usually much faster.

10 Nov 2010, 5:37 AM
I think that they are working on something regarding this but I don't know what it is yet... I guess we will have more details after the conference. I have proposed something (http://www.sencha.com/forum/showthread.php?113604-ExtJS-Dependencies-(Performance-Optimizations)) similar to what they use for the Google Closure Library, but I did not get any official response on that either.

11 Nov 2010, 9:49 PM
Hi, @screamy yeah I was meaning dojo.require. We are using the Google API so I am familiar with their method of loading parts.

I am starting to see ExtJs works well with namespaces for organization so I am really debating between Dojo and ExtJS for an upcoming project.

@Condor I will look into JSBuilder.

11 Nov 2010, 10:49 PM
I have never had an issue with ext-all.js

Our app is a single page from which you never navigate away.

Application Components are Ajax-loaded as JSON and inserted into Containers.

So the entire static javascript for the app (minified and gzipped) is loaded only once, at application startup. And even then it is cached, and so most often, the server will send back a 304 Not Modified response.

12 Nov 2010, 5:25 AM
@Darren, once I moved away from Dojo to Ext, I never looked back. Hands down, Ext is the most cohesive, object-oriented javascript Framework I've ever laid hands on. Plus, the API docs are sublime, especially when compared to Dojo's.

12 Nov 2010, 7:29 AM
@Animal, I made an App with ExtJS like that but I was looking for a more proper approach. I guess I could do it that way again.

@Screamy, yes DOJO's API is a little sketchy. I am still debating hard. I also have another developer who may need to work on this so I am hoping if it would be easy for him to transition.

12 Nov 2010, 11:12 AM
The cool thing about Ext is that you can use as little or as much as you like. I started out by face-lifting existing HTML and sprinkling in Ext widgets as needed. After doing that for a while, I slowly began to realized that I needed to 'drink the koolaid' and write a full-on, 100% Ext application to appreciate its full power.

The hardest part of moving to Ext is letting go of hand coding HTML/CSS page layout, but once you do, you'll wonder how you ever got by without Ext.

Even if you decide to stick with Dojo for now, keep playing with Ext and I guarantee that you'll eventually make the switch for good.

Either way, happy coding!

P.S. Here's a great book for covering the basics (and a bit more): http://www.packtpub.com/learning-ext-js/book

12 Nov 2010, 12:02 PM
My opinion is that while we know we are using an HTML DOM, actual textual HTML with "<" characters and tag names is not useful any more.

The DOM is what matters, and a body of objects managing that DOM reacting to events, animating it etc.

But how that whole UI is described is best encapsulated with the descriptive and declarative power of JSON.

Send one UI description to the client. Not a textual HTML "picture" of an application, and a parallel set of event handlers.