JavaScript best practices

Use === comparison

The == comparison operator always converts (to matching types) before comparison.

The === operator forces comparison of values and type.

Avoid use of eval() function

The eval() function is used to run text as code. In almost all cases, it should not be necessary to use it. Because it allows arbitrary code to be run, it also represents a security problem.

Optimize loops

Loops can become slow if not done right.

One of the most common mistake is to read the length attribute of an array at every iteration. This means that every time the loop runs, JavaScript needs to read the length of the array. You can avoid that by storing the length value in a different variable.

And an even shorter way of achieving this is to create a second variable in the pre-loop statement.

Another thing to ensure is that you keep computation-heavy code outside loops. This includes regular expressions and — more importantly — DOM manipulation. You can create the DOM nodes in the loop but avoid inserting them into the document. 

Avoid use of alert function

The use of alerts functions is discouraged in Production environments, as it could inadvertently expose sensitive data or program internals.

Avoid use of local storage on Client Scripts

HTML 5 allows developers to store megabytes of data on the client-side. This can be a security vulnerability as the data is not encrypted by default.

Avoid unrestricted targetOrigin on cross-domain messaging

HTML 5 allows for the exchange of messages between different Window objects. The window.postMessage() function can be used to achieve this, but using the wildcard * targetOrigin in this function can allow a malicious site to intercept messages being passed between your application Windows. Therefore, uses of the window.postMessage method such as window.postMessage("Message", *); should always be avoided.

See this reference for further details.

Avoid use of Function constructors

Function constructors are similar to the Eval function in that will transform any String into executable code. From this point of  view, they are a serious security vulnerability.

Additionally, each time the Function constructor is called on a string representing source code, the script engine must start the machinery that converts the source code to executable code. This is usually expensive for performance - easily a hundred times more expensive than a simple function call, for example.

Using the Function constructor  does not affect the code surrounding the use, but it can still be quite slow.

Avoid use of WebDB

The Web SQL Database (https://www.w3.org/TR/webdatabase/) was a failed attempt by the W3C to introduce a set of APIs to manipulate client-side databases using SQL. It is not implemented by all browsers, but any possible references to it should be avoided, as only a user name is required to access the data stored in these repositories.

Avoid use of debugging statements

Debugging statements, especially through the JavaScript debugging console, can expose program internals and data which should remain confidential. This may not be immediately obvious to a regular user, but anyone who is aware of the existence of a Javascript console can view the statements being logged. 

Avoid making connections on unsecure protocols

Any connection from JavaScript code through an unsecure protocol, such as http, or ftp should be avoided. System properties and user preferences which include these insecure protocols are also reported.