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?
“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.
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!