Closure: The Definitive Guide

Foreword

Nick Santos

Former Closure Compiler Tech Lead

I was sitting on a balcony on the west side of Manhattan, sipping on a warm glass of scotch with a few others. Michael Bolin joined us. Michael wrote this book. At the time, Michael was working on Google Tasks. I was the tech lead on our JavaScript optimizer, later named Closure Compiler. Michael didn’t join us to talk about JavaScript optimization though. He didn’t want to talk scotch either, to his detriment. He wanted to talk JavaScript-driven text editing, and thus he wanted to talk to Julie.

You will receive a proper introduction to Julie in Chapter 9, but for now, just know that Julie is our expert on how text editors are implemented in each web browser.

Michael found that, when managing a task list in a web browser, you want a few features built into your plain text editor. You want to make words bold for emphasis. You want a keyboard shortcut to move your cursor to the next task item. He didn’t want to have to write a whole editor. He just wanted a few tweaks on top of what the browser provides, to make the experience smoother for the user. How would you implement this?

Julie explained that there are many, many choices for such a thing. “Should you use a textarea?” “Should you use a contentEditable region?” “Should you rely on the browser’s built-in rich text functions?” “Should you implement the ‘bold’ function in JavaScript?” “How do you make sure the cursor ends up on the right line, given that browsers each implement cursor selection differently?” “Should you put all the text editing in an iframe to isolate it from the rest of the page?”^[†]

“Is there code you can reuse for this?”

You don’t really want to implement all these things from scratch. A lot of them will need to call into esoteric browser APIs in complex ways. Many of those APIs are buggy, poorly documented, or simply do not perform very well. For some of those APIs, it’s easier to read the browser source code than to find reasonable documentation.

You’ll find answers to many of those specific questions throughout this book. But I think the question that the book is most interested in (and rightly so) is about how to make it easy to reuse code for Ajax apps. It spins off into a few other equally substantial questions.

How do you share JavaScript code? How do you organize large amounts of common JavaScript, often built for highly specialized tasks? How do you weigh one team’s need for boatloads of new features and customizations against another team’s need to keep the size of the JavaScript they’re sending to the user small?

The Closure Tools were designed to solve many of these problems. Maybe that’s understating the point. These problems are at the very core of their design. Many of the tools were started by our friends on Gmail. Gmail began as a relatively modest JavaScript app. Then they added more and more features, and watched it grow beyond any hope of control or maintainability. Frederick P. Brooks, Jr., famously described large-system programming as “a tar pit, and many great and powerful beasts have thrashed violently in it.” In a language like JavaScript, a highly dynamic environment where almost everything can be mutated and there’s no standard way to specify contracts (type checking or otherwise), the tar is fast and can suck down even a small group of developers.

The Closure Tools developers tried to bring “closure” to this mess. (I agree the pun is terrible. It is not mine.) They followed strict idioms for namespacing code and defining classes. They adopted ECMAScript 4’s type language for specifying contracts. The compiler forced the developer to declare their variables, and emitted warnings for other frowned-upon idioms. The Closure Tools, in short, tried to add some structure to the language. Many engineering teams at Google found this structure useful, and built their products on top of it.

A long time passed. The Closure Tools remained proprietary for years. This wasn’t meant to be. Both the compiler and the libraries were always designed to be open source projects. But more importantly, they were designed for building Google apps first, and to be open source projects second. So releasing them publicly took a back seat to other things.

Have you ever tried to publicly open up the code of a proprietary project? Several engineers had tried to release Closure Compiler. They had all given up. It is surprisingly difficult. There are two major parts. First, you have to release the code: port it to a public build system like Apache Ant, remove all of its nonopen dependencies, and rewrite any dependencies that you can’t remove. Second, you have to write documentation: loads of documentation.

You can imagine how skeptical I was when Michael first came by my desk to talk about making Closure Compiler an open source project. This was early 2009. By this point, “publicly releasing Closure Compiler” was the sort of daunting chore that you’ve procrastinated forever and a half. We’d work on it for a month, realize that we seemed no closer to completion, and then procrastinate some more. It was sort of like reading Infinite Jest. Or cleaning my apartment.

Obviously, Michael succeeded in his effort to release the compiler. I think it was some combination of being persistent, asking a lot of good questions, and commissioning a lot of good help from smart people. Of course, Michael is a web app developer first, and a open source engineer second, so he also helped design and write the Closure Compiler web frontend. By pure serendipity, Closure Library, Closure Templates, and Closure Debugger were all released along with it.

But making the code available was just the first part of opening up the project. This book marks a major milestone in the second: documenting it all. There’s surprisingly comprehensive knowledge in this book, more than any one engineer on the project knows. I’ve already started telling our interns to stop bothering me, and instead just read this Closure book’s sections on appending DocumentFragments, or on using XHRs, or on the binding of the “this” keyword. You can read this book like an API reference manual for the Closure Tools. You can even read it more generally as an API reference for web application development.

If you want to get the most out of it, pay attention to Michael’s explanations of how and why these tools came to be. Michael explains how they can help you to manage complexity. There were many missteps and false starts. Along the way, Michael will drop hints about pitfalls to watch out for, mistakes that we made and how you can avoid them too. You’ll even learn how to build your own tools and compiler plugins to help tame your own large codebase.

Just remember that this is first and foremost a practical guide to how to build your own rich web apps. So quit reading this foreword and go to it!

---

^[†] Fun fact: as the number of JavaScript developers in a room increases, the probability that someone will suggest “iframes” as the solution to your problem asymptotically approaches 1.