@ChrisGwynne: As Louis said, 1.2 is very optimised for that. We have raised the YSlow rating from 60 (D) in 1.1 to 91 (A) in 1.2.
We still have a few things to fix before it is released, but it shouldn't be too long now, and of course you can always grab the latest version from our SVN repository if you are feeling adventurous :)

Yes, but it's still better to have it all concatenated and minified as a single, or fewer files and THEN compressed and cached :D

Given that 1.2's getting minify I wouldn't be surprised to see it ported to V2 as well.

Well you can argue the toss on anything being better/worse than anything else because not all situations are the same. Sometimes inline JS and CSS is the best thing to do from the point of view of speed - just look at some of Google's code. However, as a general catch-all improvement 1 single JS and 1 single CSS file is better than 5+ of each! Concurrent downloads be damned.

As a relatively simple improvement to the "1 big file" solution, perhaps we could have

$Footer->AddScript('javascript.js');

in addition to the

$Head->AddScript('javascript.js');

we already have. That way, scripts that can be deferred until the content has loaded could be specified to go in the footer. Then we'd have 2 big JS files, one set in the head and one set in the footer. Thoughts?

@Dinoboff I just meant if you are combining tiny js files into larger js files then you could keep parallel downloading, by sticking them at the bottom of the body the page can be loaded at the same time.

@[-Stash-] (I hope the nickname highlighting works on *that*)

I agree about the footer bit. And I suppose scripts could also specify jQuery.ready for on-DOM load, although Google's idea of having JS that loads to write in further JS might be worth a look. The idea of turning JS from something dumbly loaded via HTML into something smartly loaded by JS as a platform itself might be worth considering. I love all the new MVC frameworks for JavaScript, or something I just discovered the other day-- CoffeeScript. I don't see why we can't treat JS more like PHP and optimize its hooks/execution the same way we do in Garden for PHP.

For Vanilla 2, the equivalent of Head::AddScript and Foot::AddScript would be too low level. Controllers and plugins should not have to guess how the scripts and style-sheets they require should be loaded.

Applications and plugins should instead list the ressources they can serve. A resource should have a name, a default location, a list of dependency (some other js or css script) and some flags (like "can be packed", "can be minified", "can be loaded asynchronously", "is a library", etc...)

Then the controllers should list the ressources a page needs and let Vanilla or a plugin add the scripts and stylesheets. Vanilla should have a naive implementation, adding all ressources inside the Head elements in the correct order. Plugins could implement different way to optimize loading so that admin can test and pick the best solutions for their forum (a forum that get most of its traffic from google will have different needs than a private forum).

When trying to optimize css and js file load you need some information about the files: can a script be packed (eg: Scriptaculous cannot), has it been tested minified, in which order should the files be loaded, etc...

It is better for the developers who will use these libraries if the providers of the library define all metadata; it's also "DRYer".

In Vanilla 1.2, to add jQuery and your plugin (and allow them to be packed), you will have to remember the recommended order of loading for jQuery and its plugins:

$Head->AddScript('js/jquery.js', '~', 190);
$Head->AddScript('extensions/MyExtension/functions.js', '~', 350);

If you are using MooTools, you have to guess since the framework or the plugins Vanilla 1.2 includes don't use MooTools.

I would have like better:

$Context->RegisterScript('extension/Myextension/function.js', ['js/jquery.js']);
$Page->Require(''extension/Myextension/function.js'')

About js and themes, there are patterns that allow default settings to be customised:

(function($){


	$.askConfirmation = {
		selector: definition('askConfirmation.selector', 'form.important'),
		prompt: definition('askConfirmation.prompt', 'Are you sure?'),

		init: function() {
			var self = $.askConfirmation,
				e = $.Event("askConfirmationInitStarting");

			$(window).trigger(e);
			if ( e.isDefaultPrevented() ) {
				return;
			}

			$(self.selector).submit(self.onSubmit);
		},

		onSubmit: function() {
			return confirm($.askConfirmation.prompt);
		}
	};

	$().ready($.askConfirmation.init);

})(jQuery.noConflict());

To overwrite the selector, the theme can add the following script at the end of the head element:

jQuery(window).bind('askConfirmationInitStarting', function() {
	jQuery.askConfirmation.selector = 'form.very.import';
});

Or If I understand what Garden's "definition()" can be used for, it can just add an entry for the "askConfirmation.selector" definition.

As a plugin developer I would be happy to provide meta data in the plugin if it meant less people had problems using the it (read: there were less support questions!).

Never say die!