I like Google Web Tookit API approach. It use Java language behind the scenes that piles ONLY JavaScript code WHOSE TARGET BROWSER NEEDS. It happens some developers would like to use that feature in pure JavaScript language.

Anwser: WHAT COULD WE SUGGEST in order to fullfill this requirement ?

I suggest to use JavaScript ments (as a flag) as a way some piler (like Yahoo JavaScript piler) analises our app JavaScript code and generates only a JavaScript Framework code needed.

Example: a hypothetical JavaScript framework (JQuery, Mootools, Prototype ect) code

// depends function say
funcion sayHello() {
    // some code   
}

function say() {
   // some code
}

// more and more no needed Javascript framework functions in our app

So when my app use a function sayHello, only that sayHello function and its dependencies would be filtered through JavaScript ments, nothing else. So, this way our application would be lighter, by using only JavaScript Framework code needed.

And you: what do you suggest ?

I like Google Web Tookit API approach. It use Java language behind the scenes that piles ONLY JavaScript code WHOSE TARGET BROWSER NEEDS. It happens some developers would like to use that feature in pure JavaScript language.

Anwser: WHAT COULD WE SUGGEST in order to fullfill this requirement ?

I suggest to use JavaScript ments (as a flag) as a way some piler (like Yahoo JavaScript piler) analises our app JavaScript code and generates only a JavaScript Framework code needed.

Example: a hypothetical JavaScript framework (JQuery, Mootools, Prototype ect) code

// depends function say
funcion sayHello() {
    // some code   
}

function say() {
   // some code
}

// more and more no needed Javascript framework functions in our app

So when my app use a function sayHello, only that sayHello function and its dependencies would be filtered through JavaScript ments, nothing else. So, this way our application would be lighter, by using only JavaScript Framework code needed.

And you: what do you suggest ?

• javascript
• performance

• 2 @Michael: I think it's quite readable. Not every users of SO is native English speaker (such as myself), but I can get the essence of what he's trying to say just fine :). – Jimmy Chandra Commented Jul 20, 2009 at 1:51
• 5 This post has been piled with only the necessary words. ;) On a more serious note, I get what the author is going for. But: piling Javascript files as-needed sounds like more trouble than it's worth, and it subverts browser caching. A simple modular approach seems sufficient to me. Hence this is a no-answer. – deceze ♦ Commented Jul 20, 2009 at 1:55
• 1 Premature optimization is the root of all evil. Considering Google and Yahoo will host the Javascript libraries for you, and users probably have those cached... is this really a problem that is worth spending your time on? – jrockway Commented Jul 20, 2009 at 2:15
• Hi jrockway, In my pany, a big health care pany, we use INTRANET IN SOME applications, so INTERNET is NOT always on. Consider it. – Arthur Ronald Commented Jul 20, 2009 at 2:22
• 1 Browsers don't always use the cache, even when they could. For example, if the user opens a new window (via the File menu, or with Ctrl-N) in IE 6 (and possibly later versions) it will always retrieve everything anew, pletely bypassing the cache. Developers shouldn't expect the browser cache to alleviate them of their responsibility to minimise the amount of data they send over the wire, for caches are unreliable at best. – NickFitz Commented Jul 20, 2009 at 2:39

6 Answers 6

If the JavaScript code of the framework is served as a cacheable file then the download cost of requesting the entire framework (e.g. jQuery.js) can be eliminated, but if you were generating the framework code on the fly (as you suggest above) then it's going to be harder to take advantage of caching.

On top of this the memory cost of defining the entire framework is probably unlikely to be problematic (assuming the framework is written sensibly).

So, pulling in the entire framework, as is the mon case, is simple, works well and doesn't require a particular server-side infrastructure (like GWT does).

There's one case where it would make sense to me--a jQuery for iPhone. It doesn't make any sense for all the non-Safari baggage in jQuery to be in there slowing things down.

For the typical desktop, though, if you get a JS library from the Google APIs, it's likely already cached and ready to go.

I would suggest learning to program in JavaScript and understanding the various peculiarities of the different DOM implementations, then writing just the code necessary for your application. If you really don't want to have to deal with re-creating all the event handling shenanigans and so on, then nick the relevant techniques from the libraries. You'll learn a lot more about what you're doing that way, as you'll need to actually understand how it all works to be able to integrate those techniques with your application.

Having worked professionally with JavaScript since 1996 I, like many, was initially tempted by the apparent ease of use offered by libraries; but if I see one more answer on here that says "use jQuery" (followed by some code that isn't even optimal in jQuery) when the correct answer is to use an existing and well-documented feature of JavaScript that works on every single implementation since Netscape Navigator 3, I'll scream ;-)

I don't think it would be worth it to add the plexity of selected inclusion. jQuery is 57k and loads very fast. Your energy is much better spent worrying about other things that might actually matter.

I'm currently doing something like this with my javascript code base, but only because I'm building a very large single-page ajax application. In ments at the top of the page I do java style import statements to include other javascript "classes"/objects. This is then used to create a single javascript file from the dozens of files in the application, pulling in only the code that is needed.

That said, it's not being done to reduce a small library like jquery into an even smaller library for just the things needed. When it es to that stuff, I think caching or a CDN should probably be good enough.

I don't know about other frameworks, but with Dojo Toolkit you can take advantage of caching better by using a public CDN copy of the source in your site, from AOL or Google.