Despite Sprocket or similar tools I decided to go for the plain old ANT approach. Why? It was the most practical tool, you have full control of what you are doing and the other tools did not quite what I wanted.

One part of this ant solution was to configure production setting in several source files. I rediscovered just how powerful and really simple this great tool is. Once you get used to is configure,combine,pack and deploy your php/js/html/css is a piece of cake:

Here some excerpts
In order to have just one source file I defined some custom preprocessor variables in my various files:

//@@prod@@ $config['base_dir']="";
/*@@dev@@*/ $config['base_dir']="Foo/";

<!--@@js-dev-start@@ -->
<script type="text/javascript" src="assets/js/jquery.plugin1.js"></script>
<script type='text/javascript' src='assets/js/jquery.plugin2.js'></script>
<script type="text/javascript" src="assets/js/jquery.plugin3.js"></script>
<script type="text/javascript" src="assets/js/jquery.plugin4.js"></script>
<script type="text/javascript" src="assets/js/jquery.plugin5.js"></script>
<!-- @@js-dev-end@@ -->
<!-- @@js-prod-start@@ <script type="text/javascript" src="assets/js/jsbuild.js"></script> @@js-prod-end@@ -->

then in ant this looks as follows:

<echo message="Configuring PHP config for production" />
  <replaceregexp byline="true" flags="m">
            <regexp pattern="^.*@@dev@@.*$"/>
            <substitution expression=""/>
            <fileset dir="${build.dir}" >
                <include name="php/config/*.php"/>
            </fileset>
        </replaceregexp> 
        <replaceregexp byline="true" flags="m">
            <regexp pattern="^.*@@prod@@(.*)$"/>
            <substitution expression="\1"/>
            <fileset dir="${build.dir}" >
                <include name="php/config/*.php"/>
            </fileset>
        </replaceregexp>

And for the javascript in my php – view files

<echo message="Configuring referenced Javascript for production" />
<replaceregexp flags="sg">
            <regexp pattern="@@js-dev-start@@[^\@]*@@js-dev-end@@"/>
            <substitution expression=""/>
            <fileset dir="${build.dir}/php/view" >
                <include name="**/*.php"/>
            </fileset>
        </replaceregexp>
        <replaceregexp byline="true"  flags="m">
            <regexp pattern="^.*@@js-prod-start@@(.*)@@js-prod-end@@.*$"/>
            <substitution expression="\1"/>
            <fileset dir="${build.dir}/php/view" >
                <include name="**/*.php"/>
            </fileset>
        </replaceregexp>

Applying the concat task for js and css concatenation and apply java to invoke the yuicompressor and you’re done.

Following situation:
- Much Inline Javascript
- Many JS and CSS files referenced
- No Frontend Deployment/Build Process in place
- Some Javascript values are set at page generation time by Server Side code
- Webserver is not configured yet correctly for setting expires & compression headers

Problems with this:
- Maintainability and separation of concerns is an issue with lots of inline JS
- Long Pageload because of many HTTP request
- Webserver takes big hit for all the static content loading
- Network is being stressed as well
- Javascript Logic is unobfuscated/not minimised and visible to the world

Tasks:

• Externalize JS
• Modularisation of JS Dependency Loading vs. all in one
• Configuration of HTTP headers in Webserver
• Identify Scripts / static content for CDN
• Seamless Deployment/Build process from comfortable JS dev to the production code

The “challenge” was to externalise the inline Javascript.

For modularisation there are several tools to handle the dependency combination of Javascript files. Depending on the amount of Javascript and the usage metrics you can as well just pack all in one. Of course there are many other methods for combination and modularisation and you can as well just run your own method. So this is bascially just a matter of choosing the right tool / method and not that difficult. For compressing / minimisation the YUI compressor seems like state of the art.

Configuration of the correct headers is also just a – well – configuration task of setting meanigful caching control and expires headers and deflate compression for Apache2, so that the documents get compressed over the network. As for deploment and build process sprockets, ant or others are a valiable solution.

What I would like to share here is the solution for externalize Javascript that was initialised by server side code.

The basic idea builds upon this post by dustin diaz. So I am not gonna repeat his content instead if you are not familiar with private, public and privileged Objects in Javascript you might read his post first. As a starting point when combining multiple inline Javascript files we have to take care about namespaces.

//just namespacing
 
function registerNS(ns)
{
 var nsParts = ns.split(".");
 var root = window;
 
 for(var i=0; i

Ok so far so good, now we need to have a way initialise those external Javascript files with dynamic server-side variables:

//initialise a namespaced object
 
var MY = function() {
	var private_var;
	function private_method() {
		// do stuff here
	}
	return {
                init : function(var1) {
                    private_var=var1;
                },
		method_1 : function() {
			alert("method 1");
		},
		method_2 : function() {
			alert(private_var);
		}
	};
}();
 
MY.init("hey you!");
MY.method_1();
MY.method_2();

That worked out as well. But there’s a but. Our javascript will be referenced externally and along with the YUI Performance rules the script include tags will be at the bottom of the page. The initialisation code on the other hand is at the top of every page fragment/widget and might be executed at rendering time. To prevent timing problems the initialisation code therfore needs to configure an object that is already live:

//global js config obj
var runcfg = new Array();
 
//within html
var a = runcfg["details"] = new Array();
a["url"]="http://uebersoftware.com";
 
//external js
var MY = function() {
	var private_var;
        var myconfig = runcfg["details"];
	function private_method() {
		// do stuff here
	}
	return {
                init : function(var1) {
                    private_var=var1;
                },
		method_1 : function() {
			alert(myconfig ["url"] );
		}
	};
}();
 
// usage
MY.method_1();

This method allows us easy externalized the Javascript without much refactoring. The script code is namespaced and is still dynamically configurable.

Javascript one of the most popular language for web programming. Although it has been around for decades, – coming from Netscape 1995 – it was not until the advent of the Ajax and Web 2.0 when JavaScript came to the spotlight and brought more professional programming attention.

The OpenSource movement of JavaScript frameworks started in 2005 with prototype and script.aculo.us. Since then programming appealing JavaScript based Websites has become so much easier. Nowadays its litteraly possible to mash-up widgets with little to no JavaScript knowledge and set up a stunning page. I would however still recommend for someone not knowing JavaScript first to get the basics and maybe have some JS Reference & DOM Reference handy.

Looking at the core functionality of todays frameworks what do we have?

• DOM Traversal with CSS selectors to locate elements
• DOM Modification: Create/remove/modify elements
• Short syntax for adding/removing Events
• Short syntax for Ajax Request
• Animations (hide/show/toggle) & Transition
• User Interface Widgets (Drag & drop, Tree, Grid, Datepicker, Model Dialog, Menu / Toolbar, Slider, Tabbed Pane)
• Wide Browser Support

On the net you will find a mirrad of comparisons of popular frameworks. The most popular OpenSource and free JS Frameworks available today are:

* Prototype (&Scriptaculous for UI)
* Dojo
* jQuery
* YUI
* Mootools

I would say that all of those have their advantages and drawbacks and there’s not really an obvious winner. It really depends on what you use it for. Some helpful links that helped me choosing are:

Wikipedia – to get a feeling on the features
unbiased functional comparison
Stackoverflow comparing JQuery Dojo and more
Performance comparison

Choosing a framework, as mentioned, depends a bit on how you want to use JavaScript:

Plug-and-Play:

• Drop in a “calendar widget” or “tabbed navigation”
• Little, to no, JavaScript experience required.
• Just customize some options and go.
• No flexibility.

=> Widgets

Some Assembly Required

• Write common utilities
• Click a link, load a page via Ajax
• Build a dynamic menu
• Creating interactive forms
• Use pre-made code to distance yourself from browser bugs.
• Flexible, until you hit a browser bug.

=> Libraries

Down-and-Dirty

• Write all JavaScript code from scratch
• Deal, directly, with browser bugs
• Quirksmode is your lifeline
• Excessively flexible, to the point of hinderance.

=> Raw Java Script

Of course you can also mix different approaches, as you can also mix Frameworks but of course in terms of maintainability and productivity it would better if you don’t have to.

For my personal use case I had the following requirements:

1. Easy to learn with minimal intuitive syntax
2. Lightweight solution
3. Availability of some widgets: Datepicker, Grid, maybe more
4. Appealing Web 2.0 effects
5. Production quality

Right now I have choosen jQuery (incl. jQuery UI) and see how far I get with it. It was to me the most appealing in terms of the above criterias. I am not sure if I need a sophisticated data table, if so I might have another look at YUI data table which seems to me one of the best widgets for this (compare to e.g. this jQuery plugin).

For development i guess its essential to still have a good Javascript support in your IDE and a JavaScript debugger – I use Firebug and Netbeans for this. If you are into Eclipse I strongly suggest to take a look at Aptana, their IDE is really great for JavaScript and PHP, but unfortunately not optimal for Facebook development.

As a last hint: consider using Google Ajax Libs for speed up JS loading on your clients. However do not use it in local development. It just does not work reliable (loads too late etc.)