Archives For General

In JavaScript, the term ‘Variable object’ is a general or abstract term used to refer to the object that holds the properties that describe the environment and scope of the currently executing context. Simply put, it’s the object that holds variables declared against the executing context (i.e., variables declared with the var keyword). Note that it’s just an ABSTRACT concept. Hence, what the Variable object actually is at a given point of execution is dependent on the scope of the currently executing context. When in the global scope (i.e., outside of any functions), the GLOBAL object becomes the variable object. Why? Because it’s the object that holds the properties that describe the environment and scope of the global executing context. In the browser, because the global or outermost executing environment is the browser WINDOW, it is the window object that ends up being used as the Variable object, due to it being the object that describes the global executing environment. This is why variables declared with the var keyword outside of functions end up on the window object (i.e., foo="foo" ends up being accessible as

Now when in the function local scope (i.e., when inside of a function), an object called an ‘Activation’ object becomes the variable object. Why? Because it is the object that holds the properties that describe the environment and scope of the currently executing function. It is on this object that function arguments for example, are held. As an aside, by definition, to ACTIVATE something is to cause that thing to act or FUNCTION. As such, when you hear the term ‘Activation object’, think ‘FUNCTION’ object, or better yet, the root object that is LOCAL to a function (i.e., the FUNCTION LOCAL OBJECT).

With regards to the relationship between the Variable, Global and Activation object, think in terms of abstract inheritance (i.e., inheriting from an abstract type), where the Variable object is the ABSTRACT type, and the Global and Activation objects are CONCRETE instances of that abstract type.


Depicts the abstract relationship between the variable object and the global and activation object.


In this way, the Global and Activation objects can be said to be TYPES of Variable objects. By itself the term ‘variable object’ is just a general term used to describe any object that is used to store the variables that are declared with the var keyword within a given execution context. It’s similar to how the abstract term ‘HUMAN’ is used to generally describe a MAN or a WOMAN.

This is just a simple recipe for associating a local git repository with a remote GitHub repository, for those times when creating the GitHub repository first and then checking it out is not an option. I’m currently using version of git. Continue Reading…

It used to be that my natural inclination would be to wire my view templates in a manner that made assumptions about the users’ intentions and expectations, based on my understanding of the requirements. This could be seen not only in the way that I named the properties and methods that would be exposed by the controller / view model, but in the way that the view interacted with these properties and methods. Take the following AngularJS view template code as an example:

Continue Reading…

As an accompaniment to my blog post entitled ‘Lazy Loading In AngularJS’, I provided a link to a sample app that was intended to provide a very basic example of how to lazy load artefacts using RequireJS. This sample app, however, was not initially setup with unit testing in mind. This was because my aim was merely to give a very simple and easy to follow example of lazy loading and nothing more. My thinking was that the more I added to the project, the more complicated it would become for others to follow. As others have been trying to integrate the concepts found in the sample app, however, some have found that they are not able to test artefacts that are to be lazy loaded. As a result, I have now refactored the app slightly so that these artefacts can now also be easily tested. If you have not yet read the blog post in question, I would recommend that you first do so in order to gain the proper context before reading any further.

Continue Reading…

Being able to lazy load artefacts such as controllers and directives in AngularJS is great because in addition to saving on bandwidth costs, it results in the initial load time of your AngularJS app being much shorter. This is because only the assets that are needed to render the particular route in question, are delivered to the browser, and nothing more. If too many files are being lazy loaded at a time, however, the time between the initial load of your app and when the app is actually ready to present its first route, may significantly increase. The same applies for the time it takes to change routes. This can happen when the browser has reached its ‘maximum concurrent connections’ limit and as a result, has to wait for the first set of concurrent downloads to complete before starting another set of downloads. One way to mitigate this issue is to present some sort of ‘loading’ message to the user while the lazy assets are being loaded. At times, however, the message may not be enough to maintain the perception of the app being performant. At this point, the only thing that can then be done is to combine the lazy assets into fewer files that can be delivered much faster to the browser.

This is where RequireJS comes in. RequireJS is a JavaScript file and module loader that also comes with an optimisation tool that can be used to combine module definitions into ‘optimised bundles’ for fast delivery to the browser. When partnered with Grunt (a JavaScript task runner), it can be easily used as part of your build step to package multiple lazy AngularJS artefacts into fewer files. Using the lazy loading strategy found in my previous article entitled ‘Lazy Loading In AngularJS‘, I have created a runnable sample project that demonstrates grunt being used with RequireJS to combine lazy dependencies into optimised bundles. The sample project can be found at: Note, however, that this sample project is not meant to be of production quality so please only consider it for educational purposes.

When building large sites or apps with many routes/views in AngularJS, it would be good to not have to load all artefacts such as controllers, directives etc., on the first load. Ideally, on first load, only the artefacts that are needed for the route in question, will be loaded. This may be either in one download or multiple depending on the app, however, it will only be what is needed to render the particular route. Then as the user navigates the app by changing the route, other artefacts that have not already been loaded, will then be loaded as and when there are needed. Not only should this potential speed up the initial page load, but it should also result in bandwidth not being wasted. With this post, my aim is to show how the lazy loading of artefacts such as controllers and directives can be achieved with AngularJS.

Continue Reading…