Chapter 7. JavaScript and Danger-Driven Development

"In JavaScript, there is a beautiful, elegant, highly expressive language that is buried under a steaming pile of good intentions and blunders."                                                       –  Douglas Crockford, JavaScript: The Good Parts

This quotation expresses essentially what optimizing JavaScript code is all about.

Often fascinated by the latest shiny feature or by the need to deliberately or pretentiously display his own abilities, the developer's mind sometimes slips into a mysterious state of awaken sleep by which he is overcome by the need to show off overly complex code or by the desire to use the most recent features even though he knows, deep down, that this means that he will have to sacrifice long-term stability and the efficiency of his computer program. This way of building applications is what we might call "Danger-Driven Development". JavaScript has many very bad parts but has enough good parts to outweigh the bad...

The global object and local variables

JavaScript’s global object is the container of all global variables. Any top-level variable of any compilation unit will be stored in the global object. The global object is one of the worst parts of JavaScript when it is not used correctly, as it can easily become bloated with unneeded variables and can be unknowingly abused by developers when JavaScript default behavior is heavily relied upon. Here are two examples of such misuse:

• When running a simple code such as total = add(3, 4);, you are, in fact, creating a property named total in the global object. This is not a good thing for performance as you might keep a lot of variables on the heap while most of them are only required at a certain moment of an application's execution.
• When neglecting to use the new keyword in order to create an object, JavaScript will execute an ordinary function call and will bind the this variable to the global object. This is a very bad thing, not only for security reasons...

Avoiding bad idioms and keeping an eye on the very bad parts

As with most C-based programming languages, it is best to avoid certain bad idioms that often cause code inefficiency and bugs.

Bad idioms

Here are a few bad idioms that should be identified as problematic:

• Declaring a variable at first use is a bad idea in JavaScript due to the fact that the developer will most likely give the variable global scope in order to access it later. It is better to organize the code from the start of the project and use intuitive and meaningful namespaces in order to organize the use of variables throughout the application.
• Using structures in a way that is not explicit or that was not originally intended should be avoided in all cases. For example, letting a switch statement fall through or assigning a value to a variable within the condition of a conditional statement are very bad idioms and should never be used.
• Relying on automatic semicolon insertion is a bad idea and can lead to code misinterpretation...

Using the DOM efficiently

Document Object Model (DOM) manipulations remain amongst the costliest operations to do in JavaScript. Indeed, repaints or reflows should be kept to a bare minimum in order to avoid performance issues in general.

This being said though, there are other pitfalls that must be avoided in order to maintain the speed of a script when DOM operations are required and lead to repaints or reflows. These pitfalls concern how to modify the document tree, how to update an invisible element, how to make style changes, how to search for nodes, how to manage references from one document to another and what to do when inspecting a large number of nodes.

Modifying the document tree

It is important to know that making modifications while traversing the tree is very expensive. It is best to create a temporary collection to work on rather than modifying the tree directly while looping over all of its nodes.

Indeed, the best approach is to use a non-displayed DOM tree fragment, to make...

Structuring and loading a JavaScript application

When thinking of how to structure and load a JavaScript application, it is important to remember certain important principles.

Minimizing costly operations

The costliest operations to do in JavaScript are:

• Requesting a resource through network I/O
• Display repainting, also known as redrawing, of the web page due to dynamic content changes such as making an element visible
• Reflowing, which can be caused by a window resize
• A DOM manipulation or dynamic change to the page’s styling

Obviously, the bottom line is that all these operations should be kept to a bare minimum in order to preserve good performance in general. When working on a script that is executing too slowly, these are the most important elements to look for with Google Chrome's Timeline tool, which can be accessed through Chrome’s Developer tools, as mentioned in Chapter 1, Faster Web – Getting Started, of this book.

Cleaning up, minifying, and compressing resources

Of course, excluding unused...

Summary

In this chapter, we have covered a few of JavaScript’s best and worst parts, especially the pitfalls that can cause issues performance-wise. We have seen how coding safe, reliable and highly-efficient JavaScript code might not be as exciting as using the latest shiny feature or as tempting as lazy coding, but will certainly help any JavaScript application be a part of the Faster Web.

In the next chapter, we will see how JavaScript is increasingly becoming a functional language and how this programming paradigm will be a vector for performance in the near future. We will take a quick look at upcoming language features that will help improve the performance of JavaScript applications.