Archive
Care and feeding of large JavaScript projects
Tetsuo reminds us that projects allowed to grow out of control often become difficult to manage.
When building a webapp in JavaScript, you are using JavaScript in a very different way than it was originally intended when the language was designed. Case in point for this discussion: most languages designed for big projects provide some sort of mechanism for every source file to describe any other source files it depends upon. C/C++ has the “#include” directive, Java and C# have a strict class design that allows the compiler to determine where to find every source file, and Ruby has the “require” statement.
The JavaScript language has none of these techniques inherent in the language. Once you are writing code in a JavaScript file, there is no easy way to pull in other JavaScript files that your current file depends on. Fortunately, JavaScript developers have come up with several mechanisms to solve this problem.
In the old days before Visual Studio, C/C++ programmers used a tool called a ‘Makefile’ to tell the compiler which source files were needed to build a program (kids, ask your parents). The Makefile was, as its name implies, a separate file the programmer would need to open and add a new source file to every time a new file was written to add to the project. It was a cumbersome process and prone to error, but it’s also the easiest pattern for a JavaScript programmer to follow. If you’re building a web-based application, you can use the index.html page as your “Makefile” and add all JS files you need to the <head> element in your index page to have the browser load all needed files, like so:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>One webapp to rule them all</title>
<script src="thirdParty/theirResourceA.js"></script>
<script src="thirdParty/theirResourceB.js"></script>
<script src="lib/myResourceA.js"></script>
<script src="lib/myResourceB.js"></script>
<script src="lib/myResourceC.js"></script>
<script src="webApp.js"></script>
<script type="text/javascript">
var app = new WebApp();
window.addEventListener('load', function(){app.run();}, false);
</script>
</head>
<body>
<div>One does not simply hack into Mordor.</div>
</body>
</html>
There are a few problems with this approach. As your project grows, this list of files will become cumbersome and unwieldy. It will always be a pain for your developers to open the index.html file to add any new files to the architecture, and there’s no easy way to tell which files depend on which other files, which becomes especially onerous if you need to load the files in a specific order to make sure that the files that depend on certain other files are loaded after those files they are dependent upon. Finally, once your webapp is ready for production, you are probably going to want to run all these files through a minifier anyway, at which point you’ll need to edit the index.html file to load only the minified version of the app rather than all the resource files separately.
Don't let this happen to your project.
Fortunately, there are tools like RequireJS which allow us with a minimal amount of restructuring to declare our JavaScript dependencies within each JavaScript file. This makes the dependency tree much clearer which in turn makes it much easier to move a subset of code over to new projects. Developers no longer need to manage a resource list in an external file like the index.html file. And finally, when the project is complete, RequireJS has tools that assist in minifying the entire project for production.
10×10 Room
My company
Conclave
Our first game
archmagus 