Creating globals is considered a bad practice in general and is specifically problematic in a team development environment. Globals create a number of nontrivial maintenance issues for code going forward. The more globals, the greater the possibility that errors will be introduced due to the increasing likelihood of a few common problems.

The potential for naming collisions increases as the number of global variables and functions increase in a script, as do the chances that you’ll use an already declared variable accidentally. The easiest code to maintain is code in which all of its variables are defined locally.

The global environment is where native JavaScript objects are defined, and by adding your own names into that scope, you run the risk of picking a name that might be provided natively by the browser later on.

In JavaScript development, a very useful method for finding out the details about a JavaScript item (variable, object, property, etc) you have, is the console.log() method. This allows you to place things in the console rather than somewhere on your page (like using an alert() method).

JavaScript normally runs code sequentially, which means in the order that the browser reads it from your file, but we can write JavaScript code that will run only when something happens in the browser. That’s because browsers can trigger events, when things happen to elements on your page.

When the page loads in a browser, when the user moves the mouse over a link, when a video has finished loading, or when a form is submitted are events. So if you want to take care of a task when something happens you have to capture that event, and that’s done through a process called event registration.

This means telling the browser that you want to do something when an event takes place, and there’s several ways of doing that. Some are more compatible with older browsers than others.

The first (but legacy) way of doing this is by using tag attributes, and this works pretty simply.

When you talk about code working differently in different browsers (modern browsers), you are generally referring to the rendering engine. That’s why you have very few differences in support between Chrome and Safari; they are both built on the same open source rendering engine, Webkit.

Some rendering engines are faster than others, but this also extends to the JavaScript engine in each browser. Just as some rendering engines are better than others, the same can be said about JavaScript engines that are built into the browser. The speeds of these JavaScript engines vary greatly, and this is generally why JavaScript is so slow to execute when compared to other technologies, like CSS.

You can use null to explicitly indicate that an object property does not contain a value. Typically, if a property is set up to contain a value, but the value is not available for some reason, the value null should be used to indicate that the reference property has an empty value.

1

2

3

// the property foo is waiting for a value, so we set its initial value to null

varmyObjectObject={foo:null};

console.log(myObjectObject.foo);//logs 'null'

For a variable that has a value of null, the typeof operator returns ‘object’. If you need to verify a null value, the ideal solution would be to see if the value you are after is equal to null. Below, we use the === operator to specifically verify that we are dealing with a null value.

JavaScript

1

2

3

varmyObject=null;

console.log(typeofmyObject);// logs 'object', not exactly helpful

console.log(myObject===null);// logs true, only for a real null value

When verifying a null value, always use === because == does not distinguish between null and undefined.