As developers, we want three things from our JavaScript: For it to be easy to write, safe for other developers to edit, and fast for the browser to download and use. We like to call this the iron triangle of JavaScript development.
It’s actually difficult to achieve all three points of this triangle, because they often conflict with each other. Recently, though, tools have come about in JavaScript development that allow us to have our lunch and eat it too.
Trust me, it’s technical, but it will all make sense soon.
We want our code to be easy for the browser to download and use.
Our endgame is typically to have only one script file so it can be downloaded with fewer calls to the server. And we want that file to be compressed so it downloads as quickly as possible. But this sort of JavaScript is simply impossible to digest. In fact, it’s impossible to read. Think about all the issues it would cause for another developer, who isn’t familiar with the code, to understand its intent and make meaningful edits.
So, how do we write code that’s easy for both developers to work with, and for the browser to use?
We do have a way to achieve the goal of simple code that’s fast for the browser. First, we write code that’s meaningful, and that we can understand. Then, we run that code through a compiler, which breaks it down into the absolutely smallest form it can be. So, something like “passenger” might become just “a.” This may not seem like a big deal, but applying changes like that hundreds and thousands of times over the course of a large project offers massive benefits. It compacts our meaningful code so that the browser can very quickly download and use it.
It’s a lot like lunch.
Of course, another issue we run into in development is that when we want to give our client a better value, we use third-party scripts. In fact, one of the problems with JavaScript is that it’s a bit too easy to use the global scope. Not to get too technical, but it’s sort of like, by default, JavaScript stores all of it’s information in the same place. Just like how at work all of my co-workers store their lunches in the same refrigerator, which can sometimes lead to problems.
Sometimes JavaScript that one developer writes will store a piece of information (i.e., “lunch”) on the top shelf of the refrigerator. Then, a piece of JavaScript that another developer writes decides it wants to use the same exact spot, so it swaps out the contents of the top shelf of the refrigerator with its own “lunch.” But when the first piece of JavaScript goes back to the top shelf of the refrigerator, it won’t find its “lunch” and thus will begin to behave unpredictably. (This is understandable as I, too, begin to behave unpredictably when someone steals my lunch from the company refrigerator.)
Lunch requires a fork, but Javascript has a few other handy tools.
This is where tools like require.js and Almond come in handy. They make it really easy for us to break up the code into smaller, independent chunks that have their own refrigerator, so they can’t steal each others’ lunches. Using these tools allows us to put a “wrapper” (a sandwich bag, if you will) around our code so that it can talk back and forth with others’ code when it needs to, but it’s protected from being moved around or otherwise messed with.
So it is possible to meet all three points of the iron triangle if you use the right tools. Using a compiler, we can create easy-to-read code, and thanks to tools like require.js and Almond, our code is safe for other developers to edit and use. And we can even use third-party scripts to save time and money. Ultimately, all of these tools help the browser to speedily chomp through the code and serve up the page.
Still not making sense? Let's get lunch and chat about it.