- Wednesday, June 10, 2015
It's been five years since I first began using Google Closure in a professional setting, and nearly as long since I wrote my introduction to it here. Over that time, we (Seattle-based startup Appature, now IMS Health) used Google Closure to build a very large web application for digital marketing.
At the time we began using it, Google Closure had been public for around 6 months. While it wasn't gaining much traction, it promised to solve a number of difficult problems we were experiencing. As with most web applications of the era, ours was built using a small base library (prototype.js, though jQuery had conquered the world for newer applications).
Worse, these additional libraries were typically authored by a completely different team, individual or organization, making code quality and even implementation patterns (such as event handling) highly variable. Absent standards for UI elements, each new library added additional costs for users as well. For example, our pre-Google Closure application's WYSIWYG editor had its own system for dialog boxes, whose look and function were completely different from those found elsewhere in the application.
At the time of our initial investigation, Closure was not widely used outside of Google, and documentation (particularly conceptual documentation) was scant. However, given its usage on very high profile Google projects (Gmail, Docs, etc), we dove in and have used Google Closure ever since.
More importantly, the Closure Compiler has allowed us to turn the massive size of the Closure Library into a huge asset. We compile our script with advanced optimizations, which eliminates dead code automatically, meaning we only pay for exactly the code we are using. Closure Complier also supports splitting code into modules, which again is done automatically (like most non-Google users, we use plovr). We have a base module for common code and separate modules for major areas of functionality (email, SMS, customer search, settings, and many more).
Our consumption of Closure Library has grown significantly over time. Shortly after our initial adoption, we extended our localization support and found support for locale-aware parsing of dates, numbers and currency right in the box. Below is a list of classes and namespaces we've consumed from Closure Library. This only accounts for elements of the library we've directly referenced from our own application code:
As you would expect given its usage within Google, both Closure Library and Closure Compiler have done an excellent job of staying up-to-date. As HTML5 has blossomed, and browsers have evolved, Google Closure has been quick to respond, adding to and evolving its existing functionality.
That's not to say that adoption doesn't matter. The absence of a rich community around Google Closure has been disappointing. Only a single book on Google Closure has been published, and the surrounding tools have been slow to evolve. Contrast this with Angular, which has achieved off-the-charts hype and has developed a massive community despite minimal usage in production Google applications. Many books and countless blog posts have been authored explaining various patterns and concepts, making it much easier to get started.
Despite the lack of popularity, a number of companies have successfully used Google Closure for their production applications. Medium, Yelp, CloudKick (acquired by Rackspace), Cue (acquired by Apple), and IMS Health (my company) all use (or have used) Google Closure to power their production applications. And, importantly, the majority of Google's flagship applications continue to be powered by Google Closure.
So, what about the next five years? I expect that we'll be using Google Closure in some form over that time period, though our usage will likely evolve. One area where we're currently venturing outside of Closure Library is for our UI components, which have not been as quick to evolve as other parts of the library. Specifically, we're using React, whose component architecture has fit in very nicely with our existing Google Closure code. With a bit of effort, React components can also take advantage of Closure Compiler.
goog.provide("my.app"); goog.require("goog.dom"); goog.require("goog.dom.classes"); var d1 = goog.dom.getElement("decorateme-1"); var d2 = goog.dom.getElement("decorateme-2"); goog.dom.classes.toggle(d1, "aaa"); goog.dom.classes.remove(d1, "bbb"); goog.dom.classes.add(d2, "bbb");Closure Library in ClojureScript
(ns my.app (:require [goog.dom :as dom] [goog.dom.classes :as c])) (let [d1 (dom/getElement "decorateme-1") d2 (dom/getElement "decorateme-2")] (c/toggle d1 "aaa") (c/remove d1 "bbb") (c/add d2 "bbb"))
The ClojureScript community over the past couple of years has been a great source of innovation for application models using React's immediate mode rendering (read this post for a taste). Libraries like Om and Reagent have demonstrated the simplifying effect immutable data brings to UI development, and re-frame has provided a pattern for extending beyond the rendering layer.
Figwheel deserves special mention, as it enables a unique interactive coding environment. Using Figwheel to build reloadable UIs in the style promoted by the libraries above, you can update code live while in the middle of a user workflow. The concept is best presented visually, see this brief video by the author, Bruce Hauman. Having built a couple of UI applications in this style, the traditional browser refresh workflow simply feels slow.
Googe Closure is a first class citizen in the ClojureScript universe. Consider the recent support for Closure Compiler modules, and the many libraries which provide idiomatic wrappers around the robust functionality of Closure Library. ClojureScript promises to be a well supported platform for building rich web applications with Google Closure for many years to come.