JavaScript (JS) is a nearly ubiquitous programming language on the web. A vast majority of websites still actively employ JavaScript, and as a result of this universality, all web browsers now include native JS engines in order to facilitate the simple, smooth browsing of sites online. JS fluency is one of the most widely accepted signs of web developer competency, since so many web development positions will involve working with JS on a regular basis. There are a few interesting roadblocks that may be encountered, though, even by experienced programmers when working with JavaScript.
A particular issue, known as the “Pyramid of Doom,” can be heavily detrimental to the function of your web business, and can negatively impact client experience and profitability. The good news, however, is that the Pyramid of Doom can be avoided by implementing a style of programming known as “promises,” potentially saving your company thousands by circumventing a very common JS issue.
This article will explain how the JavaScript Pyramid of Doom functions, how to avoid it, and explore some of the history of the terms.
What is the Pyramid of Doom?
A Pyramid of Doom can occur when a program contains code that makes too many assumptions about classes, other programs, or data it is attempting to call upon. Generally associated with nested indentation in JS, a Pyramid of Doom is characterized by a single value somewhere within a “pyramid” of indented code returning null and breaking the entire program. Locating the value that is causing the Pyramid is time consuming and sometimes nearly impossible, meaning that in the occurrence of a Pyramid, a great amount of money can be spent in labor alone trying to fix the problem, not to mention the potential cost of affected services being down.
JS is particularly susceptible to Pyramids of Doom because of the way it handles callbacks (code that is passed along to another piece of code to be used.) Additionally, JS does not contain the “syntactic sugar” that was later developed to avoid Pyramids of Doom and other similar problems (more on syntactic sugar below.) The ubiquity of JavaScript means that any aspiring web developer is likely to encounter, and possibly even create, a Pyramid of Doom at some point during their career.
How Can a Pyramid of Doom Be Avoided?
The commonality of the Pyramid of Doom problem has led to a number of solutions arising to address, solve, or outright avoid the Pyramid of Doom. One of the tactics that has eliminated Pyramids of Doom in many languages that were developed after JS was developed is “syntactic sugar.” Syntactic sugar actually refers to the general “sweetening” of languages for human use by including convenient syntax shortcuts. The programming language Perl, for example, incorporates a form of syntactic sugar in the form of the “unless” statement. Unless statements do not exist in all other languages and this can help clean up and simplify code for later parsing by other coders or users, as well as allowing for sidestepping certain types of the Pyramid of Doom.
Syntactic sugar is not the be-all-end-all of the Pyramid of Doom problem or other programming oversights. In certain contexts, syntactic sugar has even been criticized for adding unnecessary layers to programming that actually doesn’t simplify the process at all. Sugar that doesn’t successfully sweeten the programming experience is often jokingly referred to as syntactic saccharin.
Some languages have also incorporated the flip-side of the syntactic sugar solutions, known as “syntactic salt.” Syntactic salt is defined as features of a language or compiler that impede the creation of bad code, typically designed to target extremely common issues.
On a more foundational level, the development of the concept of “futures” and/or “promises” served as a more reliable way of preventing a Pyramid of Doom. Promises are objects in object-oriented programming that act as a placeholder for potentially void values. Inclusion of promises often solves Pyramid of Doom issues by providing a proxy value in the case that JavaScript code attempts to call a value that is non-existent or yet to be determined.
Who Developed Promises/Futures?
Future/promise constructs have been around for quite some time, though the term was originally coined by Barbara Liskov and Liuba Shrira in 1988. The constructs were originally developed to combat latency issues, but did not reach peak popularity with the programming community at large until 2000. In 2000, many users began to see the value in using promises/futures for web development to help streamline and improve website functionality. Since 2000, many languages have implemented promise/future constructs.
Want to know more? We can help you at www.nixa.ca! We are a company of professional web developers who can help you learn new techniques, master old ones, and avoid the most dangerous missteps in web development. Contact us today!