For my new company, I had the following design goals for my heavy use of JavaScript (JS):
Since I'm using Cambridge Templates with JEXL to process things first, the ${tool.jsbuilder(...)} section runs some Java code which does a lot of the magic during the rendering portion of the page. The first argument is a boolean to indicate whether or not I'm logged in. 'me' is an object in the context and if it is null I'm not logged in. The rest of the arguments are String[]. The method signature looks like this:
Enjoy.
![]()
![]()
- I'm using CoffeeScript (CS), so I need to have my IDE automatically compile CS to JS when I save. That way the whole Change file, Save, Reload the browser process works cleanly.
- Be able to split the files up depending on which page is loaded so that only the JS which is needed for the page is sent to the client.
- Be able to differentiate JS files to be loaded between different states such as logged in, logged out and both. That way, once someone is already logged in, the JS which controls the login and forgot password dialog does not get served again. The flip side is that JS for logged in pages is not served up to anonymous users.
- In development mode, have everything un-minimized, but in production mode, automatically minimize everything.
- Run all of the JS through the Closure compiler regardless of dev/prod so that I know that things that work in dev also work in prod.
- Limit the number of
<script>tags to the bare minimum. Ideally, 2-3 for .js files served from my site and not directly off of a CDN. Fewer loads means less network traffic. - Be able to transparently support new code / application versions so that when I upgrade the application, the browsers dump their cached copies of my files.
- No dependencies on external xml, json, property or other configuration file formats to implement the goals above. Everything should be configured by someone editing the html templates.
Let's start off by talking about one of the tools I'm using. LabJS enables me to load JS only when I need it. As part of the 'master' template which contains the skin for all pages, at the very bottom before the
</body> element I have something that looks like this:<script src="/js/LAB.min.js"></script>
<script>
var country = "${country}";
var fbAppId = "${fb.APP_ID}";
var js = '${tool.jsbuilder(
me != null,
'json2:both',
'handlebars.1.0.0.beta.master:both',
'bootstrap-twipsy:both',
'bootstrap-popover:both',
'gen/global/page:both',
'gen/global/common:both',
'gen/global/search:both',
'gen/modal/loginDialog:out', // ! logged in
'gen/global/loggedInMenu:in', // logged in
'gen/global/master:both'
)}';
var lab = $LAB
.script("//ajax.googleapis.com/ajax/libs/jquery/1.7/jquery.min.js")
.wait()
.script("//ajax.googleapis.com/ajax/libs/jqueryui/1.8.16/jquery-ui.js")
.script("//connect.facebook.net/en_US/all.js")
.script("//apis.google.com/js/plusone.js")
.script("//platform.twitter.com/widgets.js")
.wait()
.script(js)
;
// Variable "pagecode" should be a function that takes a LAB and does any page-specific loading
if (typeof pagecode === 'function')
pagecode(lab);
</script>
Since I'm using Cambridge Templates with JEXL to process things first, the ${tool.jsbuilder(...)} section runs some Java code which does a lot of the magic during the rendering portion of the page. The first argument is a boolean to indicate whether or not I'm logged in. 'me' is an object in the context and if it is null I'm not logged in. The rest of the arguments are String[]. The method signature looks like this:
public String jsbuilder(boolean loggedIn, String[] files);
What happens in that method is that it will parse the array of Strings, and based on a setting of 'in' for logged in, 'out' for logged out, or 'both' for either logged in or out, it will compare that to the loggedIn boolean and either load the appropriate JS file or not. The files are then loaded into memory, in order, and sent through the Closure compiler to minify the code.
The output from Closure is then cached in a global HashMap which is never cleared out. (Note: for languages that don't really persist memory between requests, like PHP, you can store this data in something like memcached).
The key of the Map is generated from a md5 hash of the list of filenames combined together + application version. The hash looks something like this:
In dev mode, the Map isn't used at all. The code is generated for each request, which ensures that my changes get immediately reflected in the browser. In production, the Map is first checked for the key and if it exists, the key is immediately returned from the
The key of the Map is generated from a md5 hash of the list of filenames combined together + application version. The hash looks something like this:
be712950814b2ccc6b92ff5c3. This hash is the String that is returned from the jsbuilder method. By using the names + application version, that ensures a new hash will be generated each time the application is upgraded.In dev mode, the Map isn't used at all. The code is generated for each request, which ensures that my changes get immediately reflected in the browser. In production, the Map is first checked for the key and if it exists, the key is immediately returned from the
jsbuilder method.
The final rendered page looks something like this to the web browser:
var js = '/js2/be712950814b2ccc6b92ff5c3.js';
When the LabJS code executes in the browser and loads my script with the line
.script(js), there is a Servlet listening for requests to /js2/*.js and it looks up the key from the url in the Map and returns the appropriate JS data. This servlet can also set the correct browser cache headers depending on dev or prod.
As you can see, 10+ separate files have been combined and minified into a single file which makes the requests more efficient. All without configuration files or a crazy syntax that only a backend developer can understand.
If I wanted to split the JS files into more loads so that the browser can take advantage of concurrent loading, I could do that as well by just creating more calls to
If I wanted to split the JS files into more loads so that the browser can take advantage of concurrent loading, I could do that as well by just creating more calls to
jsbuilder. That is effectively what is happening in the pagecode section near the end of the </script> element above. The body template which is loaded into the master template by Cambridge, optionally has a JS function defined called pagecode. When it executes, it calls lab.script() again with similar output from the jsbuilder tool. This allows me to split up my code so that there is global code as well as page specific code.Enjoy.
