• Privacy Policy

    Privacy Policy:

    AliveX, Inc. ("AliveX") operates https://javascriptant.com and may operate other websites. It is AliveX's policy to respect your privacy regarding any information we may collect while operating our websites.

    Website Visitors

    Like most website operators, AliveX collects non-personally-identifying information of the sort that web browsers and servers typically make available, such as the browser type, language preference, referring site, and the date and time of each visitor request. AliveX's purpose in collecting non-personally identifying information is to better understand how AliveX's visitors use its website. From time to time, AliveX may release non-personally-identifying information in the aggregate, e.g., by publishing a report on trends in the usage of its website.

    AliveX also collects potentially personally-identifying information like Internet Protocol (IP) addresses for logged in users and for users leaving comments on https://javascriptant.com blogs/sites. AliveX only discloses logged in user and commenter IP addresses under the same circumstances that it uses and discloses personally-identifying information as described below, except that commenter IP addresses and email addresses are visible and disclosed to the administrators of the blog/site where the comment was left.

    Gathering of Personally-Identifying Information

    Certain visitors to AliveX's websites choose to interact with AliveX in ways that require AliveX to gather personally-identifying information. The amount and type of information that AliveX gathers depends on the nature of the interaction. For example, we ask visitors who sign up at https://javascriptant.com to provide a username and email address. Those who engage in transactions with AliveX are asked to provide additional information, including as necessary the personal and financial information required to process those transactions. In each case, AliveX collects such information only insofar as is necessary or appropriate to fulfill the purpose of the visitor's interaction with AliveX. AliveX does not disclose personally-identifying information other than as described below. And visitors can always refuse to supply personally-identifying information, with the caveat that it may prevent them from engaging in certain website-related activities.

    Aggregated Statistics

    AliveX may collect statistics about the behavior of visitors to its websites. AliveX may display this information publicly or provide it to others. However, AliveX does not disclose personally-identifying information other than as described below.

    Protection of Certain Personally-Identifying Information

    AliveX discloses potentially personally-identifying and personally-identifying information only to those of its employees, contractors and affiliated organizations that (i) need to know that information in order to process it on AliveX's behalf or to provide services available at AliveX's websites, and (ii) that have agreed not to disclose it to others. Some of those employees, contractors and affiliated organizations may be located outside of your home country; by using AliveX's websites, you consent to the transfer of such information to them. AliveX will not rent or sell potentially personally-identifying and personally-identifying information to anyone. Other than to its employees, contractors and affiliated organizations, as described above, AliveX discloses potentially personally-identifying and personally-identifying information only in response to a subpoena, court order or other governmental request, or when AliveX believes in good faith that disclosure is reasonably necessary to protect the property or rights of AliveX, third parties or the public at large. If you are a registered user of an AliveX website and have supplied your email address, AliveX may occasionally send you an email to tell you about new features, solicit your feedback, or just keep you up to date with what's going on with AliveX and our products. If you send us a request (for example via email or via one of our feedback mechanisms), we reserve the right to publish it in order to help us clarify or respond to your request or to help us support other users. AliveX takes all measures reasonably necessary to protect against the unauthorized access, use, alteration or destruction of potentially personally-identifying and personally-identifying information.


    A cookie is a string of information that a website stores on a visitor's computer, and that the visitor's browser provides to the website each time the visitor returns. AliveX uses cookies to help AliveX identify and track visitors, their usage of AliveX website, and their website access preferences. AliveX visitors who do not wish to have cookies placed on their computers should set their browsers to refuse cookies before using AliveX's websites, with the drawback that certain features of AliveX's websites may not function properly without the aid of cookies.

    Business Transfers

    If AliveX, or substantially all of its assets, were acquired, or in the unlikely event that AliveX goes out of business or enters bankruptcy, user information would be one of the assets that is transferred or acquired by a third party. You acknowledge that such transfers may occur, and that any acquirer of AliveX may continue to use your personal information as set forth in this policy.


    Ads appearing on any of our websites may be delivered to users by advertising partners, who may set cookies. These cookies allow the ad server to recognize your computer each time they send you an online advertisement to compile information about you or others who use your computer. This information allows ad networks to, among other things, deliver targeted advertisements that they believe will be of most interest to you. This Privacy Policy covers the use of cookies by AliveX and does not cover the use of cookies by any advertisers.

    Privacy Policy Changes

    Although most changes are likely to be minor, AliveX may change its Privacy Policy from time to time, and in AliveX's sole discretion. AliveX encourages visitors to frequently check this page for any changes to its Privacy Policy. If you have a https://javascriptant.com account, you might also receive an alert informing you of these changes. Your continued use of this site after any change in this Privacy Policy will constitute your acceptance of such change.

  • ,


    JavaScript Library Techniques, Tips and Tricks

    javascript logo

    You need only to look as far as your preferred JavaScript library to get an indication of how much JavaScript has evolved over the years. Most libraries implement some powerful features and the programming techniques that govern these libraries now closely resemble OO constructs found in server-side languages.

    As you mature in your JavaScript knowledge, you may find yourself not only wanting to use but also wanting to understand the core functionality inherent to each library. Deconstructing the source, you will discover common threads running through each line of code. If you can learn to imitate and manipulate these patterns to your benefit, then you will find that you have reached an important milestone.

    The following are a few tips and tricks that are gleaned from libraries in order to help you get started.

    Namespacing and anonymous, self-executing functions

    Namespacing in JavaScript is synonymous with namespaces, or packages, in server-side languages. Instead of mimicking the same behaviour by placing several JavaScript files in different folders, library designers will often sub-divide a single object into several smaller, meaningful objects. For instance, consider some of the namespaces in the Yahoo! YUI (called modules), such as Anim, Dom, and Element. Similar namespaces can be found in Prototype, such as Ajax, Event, and Enumerable.

    Although the technique for accessing methods and properties available in each library namespace can differ drastically, the concepts are similar. Most notably is the use of anonymous, self-invoking (or self-executing) functions. Take a look at the simplest example of namespacing below.

    var JSANT = {
    	ajax : {
    		// some code here...
    	events : {
    		// some code here...
    	dom : {
    		// some code here...

    This namespace is effortless to implement, is the easiest to understand, and does not use a self-executing function. It is often referred to as object literal notation, or a nested object literal. If you never roll out your own library to other developers, and have no need for private methods and properties, then this is probably the most straightforward approach. The next example is a little more complicated.

    var JSANT = function() {
    	var myPrivateProperty = null;
    	function myPrivateMethod() {
    		// some code here...
    	return {
    		ajax : {
    		events : {
    			// some code here...
    		dom : {
    			// some code here...
    }(); // the paranthesis will execute the function immediately	

    Instead of using an object literal for the global namespace, I am using a self-executing function, and then storing (or pointing to) this object with the variable named JSANT. This approach allows you the additional benefit of private methods and properties, which are only accessible from your public methods and properties. This is often referred to as the Modular Design Pattern.

    The pattern is possible due to the fact that a function that self-executes, only executes once. Whatever is returned that one time, is now stored as a part of the namespace through your global variable. If you have also tried to master closures, well, this is your chance to shine. When an inner function like JSANT.ajax.someMethod() accesses a variable within the outer JSANT function (like myPrivateProperty) after it executes, then you have a closure.

    The final and most complicated namespacing technique is the use of the dollar sign ($) as a substitute for your global namespace. The following code is derived from the jQuery JavaScript library, and it has several benefits. The first of which is the same as the second example — private methods and properties. The second benefit is the ability to use the dollar sign not only as a namespace but as a selector for selecting elements in the DOM. The final benefit is compatibility with other libraries that also use the dollar sign selector syntax.

    (function() {
    	window.JSANT = function( s ) {
    		if ( this instanceof JSANT ) {
    			return this.init( s );
    		} else {
    			return new JSANT( s );
    	if ( window.$ != "undefined" ) {
    		window.$ = window.JSANT;
    	JSANT.prototype = {
    		init : function( s ) {
    			// do something with your selector...

    If I were to walk through the previous code verbally, it would sound something like this:

    • Create a self-executing anonymous function that contains all of your code, and protects your library from conflicting with variables already defined in the document.
    • Create a variable called JSANT, point it to a function, and assign this to the window object.
    • Pass JSANT one parameter, which will end up being the syntax for your selector.
    • If an instance of the JSANT object already exists, then initialize it.
    • If an instance of the JSANT object does not exist, then create it recursively.
    • If the dollar selector is not being used by another library (making it undefined), assign it to the window object, and then point it to the JSANT object. The $ and JSANT can now be used interchangeably.
    • Define the prototype of JSANT, and all additional namespaces, methods and properties.

    As best as I understand it, and have read it explained elsewhere, JSANT must be declared with the prototype. This is because the instanceof follows the prototype chain to see if your object inherits from the prototype of the constructor function that is the class you are asking instanceof. If someone from the jQuery team would like to venture a better explanation in layman’s terms, it might be more helpful.

    Constructor type checking

    Many developers are plagued by the fact that although objects in JavaScript have types, checking for those types can be a difficult proposition. When I first discovered constructor type checking, it was certainly an aha! moment. The previously less acceptable method for checking an object’s type, was to use the typeof keyword. Unfortunately, for custom objects and Arrays, JavaScript always returns “object” as the type. Although accurate, it is certainly not specific enough. To get more exact type definitions, use instead of the name property on the constructor for an object.

    function getObjectType( obj ) {
    	return obj.constructor.name;
    window.onload = function() {
    	alert( getObjectType( "Hello World!" ) );
    	function Cat() {
    		// some code here...
    	alert( getObjectType( new Cat() ) );

    Variable arguments, function overloading, and the callback function

    Polymorphism in JavaScript is a difficult OO concept to emulate. Unlike Java, there really is no such thing as overloading a function. You cannot define multiple functions with the same name, pass them different numbers and types of arguments, and expect the JavaScript engine to find the correct function based upon those arguments. However, there is an alternative that comes close, and that is the use of variable arguments.

    A function can gain access to the arguments that were passed into it using the arguments keyword. You do not even need to define variable names to match up with the arguments, as in the first example below. However, arguments are not an array, so in order to treat it as such, you will need to call (or convert) it into a real Array object.

    function myFunction() {
    	var args = Array.prototype.slice.call( arguments );
    	for ( i = 0; i < args.length; i++ ) {
    		alert( args[ i ] );
    window.onload = function() {
    	myFunction( "Hello World!", "Howdy World!", "Hey World!" );

    If you are the only developer using the function and know this list of variable arguments will serve a single purpose, then you can reap the benefits. However, if you want to provide more flexibility, and roll the function out as a utility to other developers, then you will probably need to consider the second example.

    function myFunction( message, iteration ) {
    	if ( arguments.length == 2 ) {
    		for ( i = 0; i < iteration; i++ ) {
    			alert( message );
    	} else {
    		alert( message );
    window.onload = function() {
    	myFunction( "Hello World!", 3 );

    This approach might at first glance appear less flexible, but it allows you to treat your function as if it were being overloaded. Each conditional block can share local variables and perform a different task depending on the number of arguments. This also sets some expectations for other developers.

    The final example utilizes variable arguments to help process a set of key/value pairs in a hashmap and allows other developers the ability to specify an optional callback function. This is an extremely flexible, yet very defined feature that is present in several JavaScript libraries. Returning a callback function allows you to notify users after an action is complete, perform updates in the background, and it is generally a very useful tool.

    function myFunction( args, callback ) {
    	for ( arg in args ) {
    		if ( arg != "elId" ) {
    			document.getElementById( args.elId ).style[ arg ] = args[ arg ];
    	if ( arguments.length == 2 ) {
    		return new callback;
    window.onload = function() {
    	myFunction( { elId : "obj", position : "absolute", top : "5px", left : "125px" }, function() {
    		alert( "Hello World!" );


    The final technique that I will cover that is used in JavaScript libraries today is shorthand. One of the positive aspects of the language is that the syntax is flexible, which allows several developers to code to their comfort level in a single script. This flexibility can cause some confusion and verboseness if no conventions have been agreed upon, but it can also lead to the creative use of shorthand. The following are three academic examples that demonstrate some of this shorthand.

    /*      Conditional Shorthand:
    	If "a" is undefined, or is not equal to true,
    	then "a" is equal to "b".   */
            var a, b;
    	a = a || b;
    /*      Conditional Shorthand:
    	If some condition is equal to true,
    	then "a" is equal to "b", or else
    	"a" is equal to "c".     */
    	var a, b, c;
    	a = ( true ) ? b : c;
    /*      Assignment Operator Shorthand:
    	"d" is equal to "c", which is equal to "b",
    	which is equal to "a". Therefore, "d", "c",
    	and "b" are all equal to "a".    */
    	var a, b, c, d;
    	d = c = b = a;


    One topic that I did not cover in this tutorial is chainability — also known as object chaining, or DOM element chaining. This is a very powerful feature in many libraries that deserves special attention. Object chaining allows you to perform an action on an element in the DOM, return it as an object, and then perform another action on that object without having to specify the element again. You could call this a preview of things to come!


    Originally written by Brian Reindel
    and posted on 02/04/2008

  • ,


    Maintainable and Reusable JavaScript By Using Coding Conventions

    Javascript Wooden Logo

    It should be of no surprise that following conventions while programming can help foster maintainable and reusable code. This should be a simple concept to grasp since using agreed-upon rules up front for any form of communication will typically add clarity. Communication through programming is no different. So it makes sense that most programming languages use conventions to help clarify the meaning of the code. This is not only for your benefit, but also for the benefit of those who are going to be interpreting, reusing, and adding functionality to your Web site or Web application.

    In this article, we are going to look at some JavaScript coding conventions. Of course, this is not the be-all and end-all list of JavaScript coding conventions. In fact, the specifics of each convention should be a secondary concern in comparison to having a convention at all, and actually being able to follow it. With that said, below are the conventions I find to be an essential complement to writing JavaScript.

    Keep JavaScript External

    This convention is rather broad as it pertains to Unobtrusive JavaScript techniques. In general, the idea is that JavaScript should be written and maintained in an external file (yes, this includes events too), separate from the (x)HTML pages, by using the script element with the accompanying “src” attribute, which then links the JavaScript file to the page.

    CamelCase Naming

    Similar to built-in JavaScript methods (e.g. – getElementById), identifiers should start with a lower case letter, and the first letter of each subsequent new word should be uppercase. The one exception to this rule is when defining a class. When defining a class, the identifier should start with an uppercase letter, and the first letter of each subsequent new word should be uppercase. Additionally, when creating identifiers it is a good idea to think of classes as nouns (e.g. – Rectangle) and methods/functions as verbs (e.g. – getRectangleSize).

    /* - CamelCase */
    	var my_variable_named_x; //NO
    	var myvariablenamedx; //NO
    	var myVariableNamesx; //YES
    /* - An exception is that names start with a capital letter if it's a class (PascalCase) */
    	function rectangleClass(w, h){ //NO
    		this.width = w;
    		this.height = h;
    	function RectangleClass(w, h){ //YES
    		this.width = w;
    		this.height = h;

    Avoid Underscores

    Underscores should not be used in identifiers. However, private members of a class are often designated by starting the identifier with an underscore. Personally, I think this should be the only exception to the rule.

    Use Spaces

    I don’t think there is a hard and fast rule on this one. I have a personal preference, but instead of specifying how spaces should be used in each scenario, I suggest that space should be used after a comma or semicolon, and before and after the assignment (=) operator. Obviously, spaces must always be used with certain operators (e.g. – typeof, in, delete, void, new, instanceof). Remember that while JavaScript has some rules, it is considered a loosely typed language, and therefore, ignores tabs and white space. This is why it is possible to “minify” JavaScript code.

    /* - using spaces after a comma, semicolon, and before and after the assignment (=) operator.*/
    	var z=x; //NO
    	var z,x,c; //NO
            var z = x; //YES
            var z, x, c; //YES

    Use a Consistent Code Layout

    Code layout is generally a matter of preference. However, if you have no preference, then I recommend you try the following for consistency’s sake:

    /* - braces {} should be used on all statements, even with a 
    single statement conditional. Notice the appropirate use of the 
    semicolon for a single statement vs. a block statement.*/
    	if(condition)statement; //NO
    	if(condition){statement;} // YES
    /* - each statement of a block statement should be on its own
    line without the braces, and the contents of the statements 
    should be indented unless you are using a single statment. */
    	function functionName(parameters){//YES
    /* - do not omit semicolons, nor allow the automated 
    insertion of semicolons. The only time this should be allowed
    is when a single statement is used instead of a block
    statement */
    	var x = 1 //NO
    	var x = 1; //YES
    	if(condition){ //NO
    	if(condition){ //YES
    /* - these are single (line) statements */
    	var functionName = function(){statement} //NO
    	var functionName = function(){statement;}; // YES
    	function functionName(){statement} //NO
    	function functionName(){statement;} // YES
    	if(condition){statement} //NO
    	if(condition){statement;} //Yes

    Variables Should Use the “var” Keyword

    All variables should be defined using the var keyword, especially inside of functions. More than anything, this helps to keep your variables in local scope as an instance of the function that contains it.

    /* - variables should always be defined using var */
    	i, i13, $i13; //NO
    	var i, i13, $i13; //YES
    	var myFunction = function(){i;} //NO
    	var myFunction = function(){var i;} //YES

    Use Parentheses To Show Order

    Parentheses should be used to visually show the order in which operations are performed.

    /* - Parentheses should always be used to show order */
    	var myNumber = z+y*x; //No
    	var myNumber = a?b:c?d:e; //No
    	var myNumber = z+(y*x); //YES
    	var myNumber = a?b:(c?d:e); //YES

    Use Single Quotes For JavaScript

    Use single quotes for JavaScript strings, and double quotes for (x)HTML.

    /* - single quotes for JavaScript, and double for (x)html */
    	var i = "<a href="link" title="&quot;+i+&quot;">"+z+"</a>"; //NO
    	var i = '<a href="link" title="'+i+'">'+z+'</a>'; //YES

    Use Unique Scopes

    Programs should not be written so that variables are in the global scope of the document. Instead, variables that need to be accessed globally should be the key of a local method/property on an object literal, or a local method/property of a utility function.

    /* - private scope using a function */
    	var z = 0; //NO
    	function myFunction(){
    		var z = 0; //YES
    		function myNestedFunction(){
    			var z = 0; //YES
    /* - using an anonymous function to create a private scope */
    	var y = 0; //NO
    	(function() { 
        	var y = 0; //YES
    /* - using an anonymous function, called after an event to 
    create a private scope */
    	var w = 0; //NO
    		var init = function(){
    			var w = 0; //YES
    		window.onload = function(){init();}
    /* - unique scope using an object, also called
    a namespace */
    	var x = 0; //NO
    	var myObject1 = {x:0}; //YES
    	var myobject2 = {
    		x:0, //YES
    			x:0 //YES

    Use Literals

    Use literal expressions instead of the new operator.

    /* - use literal expressions */
    	var myNumber = new Number(432); //NO
    	var myString = new String("This is a string"); //NO
    	var myBoolean = new Boolean(true); //NO
    	var myFunction = new Function("", "return this.location"); //NO
    	var myRegExp = new RegExp("javascript"); //NO
    	var myArray = new Array(); //NO
    	myArray[0] = 1;
    	myArray[1] = 2;
    	myArray[2] = 3;
    	myArray[3] = 4;
    	myArray[4] = 5;
    	var myBodyObject = new Object(); //NO
    	myBodyObject.legs = 2;
    	myBodyObject.arms = 2;
    	myBodyObject.toes = 10;
    	myBodyObject.fingers = 10;
    	var myNumber = 432; //YES
    	var myString = "This is a string"; //YES
    	var myBoolean = true; //YES
    	var myFunction = function (){return this.location;} //YES
    	var myRegExp = /javascript/gi; //YES
    	var myArray = [1,2,3,4,5]; //YES
    	var myBodyObject = {legs:2, arms:2, toes:10, fingers:10}; //YES

    Use Comments

    Comments should be written either on the preceding line or to the right of the code in question. All of the previous code examples demonstrate this style of commenting.

    Optimize Your Code

    Minification and Obfuscation should be used where applicable.


    Originally Written by