Agile JavaScript !

What makes JavaScript Agile ?

JavaScript is Agile when it deploys to your visitors using optimized techniques.

What makes JavaScript deployment optimized ?

When browsers are able to download your JavaScript content in parallel rather than serially.

Typical Browser Behaviors for JavaScript and CSS

Typically browsers will download each JavaScript and CSS file and then stop while each individual file is being downloaded.  This can take a lot of time especially when there are a large number of files or when each file is rather large.

Once you are able to optimize the delivery of your JavaScript and CSS you will notice a significant decrease in load times for your web pages.

Web pages that required 15 seconds before being optimized can load in half that time or less.  Lower the time required to load your web pages and you increase the enjoyment of your content, it’s just that simple.

Consider this following waterfall chart.

Notice line 2, this file loaded using the typical browser behavior which is to download the JavaScript while doing nothing else at the same time.

Now notice lines 4, 5 and 6 – here we can clearly see 2 CSS files and 1 JavScript file being loaded in parallel with the larger CSS being loaded while a smaller CSS file and a fairly large JavaScript file were loaded using the same amount of time as the larger CSS file. This is not the typical behavior for your typical browser.

How was this web page optimized ?

Very simply the dynamic.js file was loaded first because it contains some useful code that allows CSS and JavaScript files to be loaded in parallel.

CSS files are loaded the same as image files through the use of dynamic.js; using this model CSS files are simply loaded in parallel without any consideration as to what may be dependent upon whether or not they are loaded and this technique works very well.

JavaScript files are also loaded in parallel but in such a manner so as to allow this type of content to have dependencies with other JavaScript files.  A callback method is used to allow the next set of actions to be issued as soon as the JavaScript file has been loaded.  This allows jQuery to be loaded in parallel with CSS and other JavaScript files such that as soon as all the required JavaScript files have been loaded jQuery can be used with complete confidence that jQuery is ready and able to be used.

Some JavaScript programmers might want to use an interval that waits for jQuery to be loaded and ready but doing so is wasteful and not even required.  The cleaner approach is to use a callback method because doing so is less error prone and will always produce a cleaner crisper performance.

Consider the following Waterfall Chart

As before, line 2 is the only JavaScript that loads using the default browser behavior and nothing else was being done while this file was loaded.

This time lines 4, 5, 6 and 7 were all loaded in parallel during the time line 6 was being loaded.  Lines 4 and 5 are both CSS files and were loaded during the same 134 ms time-frame.  Line 6 is a rather large JavaScript file that contains jQuery.  Line 7 is swfObject.js which is used to load and embed SWF files.  As you can see, swfObject and jQuery were both loaded at the same time while both CSS files were being loaded.

What changed from the first waterfall to the second ?

The first waterfall was produced by causing jQuery to load before swfObject but only after swfObject had been loaded.

The second waterfall decoupled jQuery and swfObject by causing swfObject to begin loading before jQuery was requested with no dependency between jQuery and swfObject.  The callback for swfObject causes the SWF to be loaded and embedded while jQuery is being loaded.

The second scenario is a better experience than the first although the results are pretty subtle.

Enhanced SWF Loading

Along the way swfObject.js was also loaded in parallel and a SWF file was embedded after all the required JavaScript files were loaded by the browser.  The SWF was compiled using Flex Builder 4 using RSL’s for the Flex Framework and this produces a nicely optimized SWF that performs very well.  It should be noted the SWF is being loaded in a secure manner that hides the details of the actual SWF from view.  Try as you might you may not be able to determine the source of the SWF and therefore you may not be able to grab the actual SWF and this makes the use of the actual SWF more secure than might be otherwise.  The SWF you can see at which is a 3D rotating globe is not the SWF that will appear if your browser’s cache.  The SWF that appears in the browser’s cache is just a wrapper that knows how to load the actual SWF.  The fact that we expose the URL for the actual SWF in the source for this web page is something that could have just as easily been obscured using encryption for situations where the identity of the actual SWF might need to be hidden from view.

Additionally you may notice the right-click menu has been replaced by the SWF using a bit of JavaScript code.  The default menu is not all that pleasing anyway so why not replace it ?!?

Why do any of this optimization stuff ?

The reason one performs optimization is to make the user experience better than might otherwise be possible.

Sure, it is easier to allow the browser to do its thing because eventually the web page will be rendered and the user will be able to see what has appeared in the browser, no worries here.

For me, having spent about an hour just about 16 months ago to work-out what it takes to get my CSS and JavaScript optimized after having spent about 10 minutes with some Google information one Saturday morning… well not I don’t have to be concerned about whether my CSS and JavaScript files are handled in any other manner other than to use the code you can find in the dynamic.js script file.

For others, they might need to build some more elaborate methods for getting their CSS and JavaScript files into a single file for each where they end-up with a single CSS file and a single JavaScript file but their technique, as slick as it seems, means the CSS and JavaScript will still load using the typical browser behavior which admittedly will load a single CSS and single JavaScript file at the same time – my method means I have more control over when my files are loaded and I can use lazy-loading techniques to load my files after document ready if required to do so.

If you can use iFrames…

Some people don’t like iFrames because they have been deemed as being “evil” by those who just don’t spend enough time working with them.

You could just as easily load your JavaScripts using individual iFrames, one for each JavaScript file and then allow the iFrames to push the code they loaded into the parent DOM which results in loading your scripts faster because they can all be loaded in parallel.

The iFrame technique is a longer way to go to get the same thing accomplished versus the dynamic.js method outlined in this article but whatever it takes to get the work done works for me so long as I get to use the techniques I enjoy using.

Images can all be lazy-loaded too

The nice thing about loading image assets is that they can all be loaded in a lazy manner which means loading them only when they are needed or after document is ready, if the goal is to get your SWF content loaded faster than might otherwise be possible.

Optimized web pages are just more Agile

Why stop at using the Agile method to get your code developed ?  Why not make your web pages more Agile by allowing the browser to work for you rather than against you.

Maybe someday someone will produce a browser that can optimize how content is loaded but for now this is something a human being must do if it is to happen at-all.

When does the use of MVC become Counter-Productive ?

Q:  When does the use of MVC become counter-productive ?

A: When your programmers are coding MVC for the sake of MVC.

Now don’t get me wrong.  I think MVC is a good thing, when used in moderation – like everything else in life, a little goes a long way.

Consider Adobe Flex

Take a good hard look at the Adobe Flex Framework source code, this is Open Source and a good example of what MVC should be used to accomplish.

When you look at the Adobe Flex Framework source code you will see a bunch of objects but you will not see MVC the way most programmers want to code it.  What you will see is MVC built into every single Object Adobe produced for their Flex Framework.

Adobe did it right !

If you become skilled at writing code the way Adobe wrote the Flex Framework you will become very skilled at producing code very quickly with very little effort.

I personally feel the Adobe Flex Framework code is very readable even though there is no clean separation between MVC other than the fact that every Object has its own Model, View and Controller.

When MVC takes a left turn

The problem I have with MVC, from a purely professional viewpoint, comes from the way most skilled programmers want to do their MVC.

Take for instance a nice hierarchical nested data structure such as what one might want to build for a typical hierarchical menu that might appear on every web page as part of the navigation for a site.  This type of problem lends itself nicely to the Adobe Coding Model that allows objects to collaborate and cooperate with each other.  I have watched a rather skilled MVC programmer take this type of problem and build a large amount of code and only because his idea of MVC means he has to code a Controller that dispatches events along with a Model that handles the data model and a View that handles the visualization of the data as separate objects apart from each other.  Additionally he chose to handle the data model in what I felt was a convoluted manner.  His MVC code was massive and not all that easy to read and understand by anyone other than himself.

What if this same menu problem had been coded by the folks at Adobe ?   There would be 2 or 3 objects; the top level menu categories, the 2nd level menu items and possibly a menu fly-out object and no more.  No need to code some elaborate MVC nightmare that consists of literally tens of objects and no need to spend more than a few minutes looking over less code than would be required otherwise.

When is Less really More ?

Less code results in more productivity !

This is a simple fact most would-be skilled software engineers seems to fail to fully understand.

The more code one produces for any coding problem the longer one must spend looking at all that code and the less real work one is able to do with all that code.

OOP Beats MVC Every Day of the Week !

Object-Oriented Programming beats Model View Controller every single day of the week !

This too is a simple fact most would-be skilled programmers fails to understand.

OOP was tossed-out and replaced with MVC and this was unfortunate.

Adobe, thankfully, used OOP when they wrote the Flex Framework.  Not a lot of code, and only those objects that are required and no more; every object has a specific role to play and objects work together.

Your typical MVC programmer will require far more time to write an elaborate MVC program versus far less time for a typical OOP programmer to do the same work.

The computer does not care what the code looks like so why should we slavishly code MVC just so we can say we coded MVC ?

Show me a faster way to get products to market using MVC and I will code MVC with the best of them and quickly forget about OOP – for now I prefer getting my code out the door where it can do some good rather than not.

On the other hand, I too code MVC I simply prefer to code MVC within the body of each object rather than outside the scope of any single object.

OOP allows me to code MVC within each and every object with messages being passed between Objects as they communicate and collaborate with each other.  I get to write far less code and I get my projects done faster, in hours or days rather than weeks or months.

OOP allows me to zip through my projects nice and fast without having to slog through all that monolithic MVC stuff I have seen other programmers produce just for the sake of MVC.

If you could get more projects done using the same time a single project used to take then why not allow your programmers to produce less code while getting more projects done per unit of time.

Less time spent on a project means spending less money on each project.

Less money spent to get a project done means making more money from one’s efforts.

Less is really More  with OOP !

Vyper Logix Corp Enhances Data Center

Vyper Logix Corp adding more servers and more bandwidth.

Preparing to launch VyperDjango™ that provides FREE Django Web Hosting services. VyperDjango™ features a CMS (Content Management System) with super-fast performance.

Stay tuned for the launch date.

In the meantime you can read about VyperDjango™ at

Linked to LinkedIn

Visit me online at

%d bloggers like this: