Matt Snider JavaScript Resource

Wow, it’s May already. I’m really busy with my full-time work at Mint and my consulting, but will find the time to post some articles. I have been working on an article to compare different features from the different Frameworks, but while experimenting with JavaScript profilers and run-time analyzers, I have not found one that I like. If you have any ideas, please comment. For now, here is a simple article on how to architect your JavaScript.

Every Unobtrusive JavaScript driven Web Application should have 3 and a half tiers:

• 1. Framework tier
• 2. Toolkit/Utility tier
• 3. Business logic tier
• 3.5 Server-client variables

Framework tier
This tier will contain the objects, functions, and resources that will be used throughout your website. I suggest packaging everything into 1 file so that your client’s browser only needs to download and cache a single file (it is more efficient to download 1 large file, than several smaller files, unless the client has enabled special browser settings). At the bare minimum a framework tier should have your Dom and Event manipulation code. I also like to add String, Object, and Array manipulators and my AJAX system. Every page of your site using JavaScript should reference your Framework tier and it is safe to use these functions in your Toolkit and Business tiers.

I use one library.js file as my Framework tier; here is an where I take several files that make up my Framework and combine them into a library.js:

cat core.js dom.js form.js string.js array.js event.js > library.js

Toolkit tier
This tier contains JavaScript tools that you only use sometimes throughout your Web Application, such as Autocomplete or Animation. These files should be included as needed throughout your site. If you find yourself using these tools on every page, then go ahead and include it in your Framework file, as it will improve site performance. Also, you may find that certain tools, like a Dialog and Animation utility are always used together; you may improve performance by combining them into one file. Generally speaking, I recommend building a utility for any code that may be used on more than 2 pages. Some utilities examples:

Autcompleter, CustomCheckbox, Dialog, Logger, Math, Slider, Tooltip, etc

Business tier
This tier will contain all page specific code. I recommend you name the file directly after your view. So, if your page is called ‘login.html’, then your JavaScript business file should be entitled ‘login.js’ (any page specific stylesheet should be named ‘login.css’ as well). These pages should be included last and can reference any Objects or Functions from the Framework and Toolkit tiers. All your events should be attached to the DOM here and I often cache frequently used DOM Elements. It is good practice to put all your Business logic inside a namespace Object, such as ‘Login’ so as to not override any variables defined in the other Tiers. For example:

var Login = function() {
var dom = {collection of dom references};
Event.addListener(dom.someElement, someEvent, someFunction);
...
}

In-page tier
This tier should actually go before the Business tier, so that the Business tier can reference Objects passes from the server. You do not need this tier if you do not use any server-side scripting language. Whenever, your server-side scripting language generates the variables, such as JSON Objects, create a script tag just prior to the Business tier reference and set any variables that you need. For examples, suppose on the login page you want to retrieve a username and a JSON object representing the user’s messages in a PHP environment:

<script type='text/javascript'>
var username = "<?= $user->getUsername() ?&gt";
var messages = <?= $user->getMessages()->toJSON() ?>
</script>
<script type='text/javascript' src='login.js'></script>

Now the username and messages variables can be referenced by the Business logic code inside ‘login.js’.