What I Learned Building Google’s Web Frameworks
Post from July 25, 2017 (↻ June 19, 2019), filed under Web Development.
In The Little Book of HTML/CSS Frameworks I’ve shared a good overview and many best practices around web frameworks; I consider the book one of my better technical writings, no matter that not everyone agrees with its conclusion (in most cases, avoid external frameworks because they violate the vision, or the first paradigm, of web development).
Nowhere, however, have I talked about my experience developing some of the Web’s larger frameworks—neither about the 2004 framework (though back then, we didn’t call it that) of GMX and partner sites like 1&1 which facilitated probably the first European multi-billion visitors site based on valid HTML and entirely separate CSS (I’m still a little proud of our accomplishment back then), nor about the 2008 and 2012 frameworks I built at Google, in the end used on tens of thousands of Google webpages, likewise accessed billions of times. The following shares parts of the Google story.
The story should probably begin with the state of Google’s informational webpages back in 2008, when I and a few other quality-minded developers joined. In brief: It was somewhat of a mess, and we got a lot of criticism from reputable developers (a challenge which made for one of the reasons why it was exciting to join the Webmaster Team).
From the outside, an issue a number of Googlers were of course aware of, too, the mess consisted of the poor code quality of Google’s websites as well as products. Google homepages drew a lot of attention; products typically wowed visitors but code quality issues, particularly around accessibility, did not go unnoticed.
From the inside, and here I’ll move to only talking Google websites (not products), it was also clear that we lacked more effective priorities, processes, and, most importantly, tools; at this point, most of Google’s websites were pretty much all created and maintained manually.
On that end the team, notably the core team in Mountain View and a few developers in Zurich, were working on a solution, implementing a content management system that could operate at Google scale. We were regularly shipping sites and landing pages for dozens of locales, and our code base, HTML documents and all other assets, easily reached a six-digit number of files in 2008 alone.
A challenge and an opportunity was the diversity of sites and pages we were creating. Yes, there had been a core Google identity, and Google was just working on a corporate style guide (the UX organization led by Irene was on this piece)—but many of our sites, at least elements thereon, were unique. This uniqueness was one reason why there was no solid technical foundation yet, and I started developing the first Google HTML/CSS framework: Go (it preceded the programming language, whose team missed the naming conflict).
Go has been special, and I hope I manage to explain how so that this doesn’t just come off as a pat on my own back. Go is, and even in minified fashion you get an impression, a very compact framework. That’s by design. But how has it been designed, and why? That’s why we need to look at Google’s particular landscape for websites again—a look that is indeed compulsory when it comes to designing (and also using) frameworks.
Said landscape consisted of a distributed team—the Webmaster Team—with a diverse set of clients, ranging from Corporate Communications to Legal to Marketing, producing a large number of very different localized—up to 40, sometimes 50 languages—websites. That made for uniqueness. At the same time, all this work happened under the umbrella of Google, that is, some things design were shared by all pages.
Now, you get an idea that this shared piece was perhaps small, and that that, and not the vast number of differences, made for a central piece in Go’s vision: Go should not aim to cover “everything” we did but work well at the base. Find and reflect the lowest common denominator, that was the idea.
The next principle behind Go was simplicity, for that simplicity promised lucrative returns: For one, simplicity makes for a great many great technical benefits, from increased speed to improved maintainability. For another, simplicity makes for great developer usability including, something well relevant for the work on Go, a better chance of adoption.
This chance then resulted in something that I wish to illustrate off the top of my head, five or six years after I have last set up a Go page; one would write an HTML page like this:
<!DOCTYPE html> <title>Google Test</title> <meta charset=utf-8> <link rel=stylesheet href=/css/go.css> <h1><a href=/><img src=/logo alt=Google></a> Test</h1> <p>This is only a test .
And equally off the top of my head, Go then did with as few classes and IDs as possible, namely the following:
#aux. The basic page types were full width, full width with navigation, compact page (narrow), and compact page with navigation. Centering was achieved through the
.compact class (on the
body); adding a navigation list (
#nav) “automatically” triggered the navigation page types; &c. All page types were liquid and inherently mobile-ready. This to give an idea of simplicity and ease of use. (While HTML 5 was still cooking and CSS Logical Properties were unheard of,
#about reflected my preference over
#nav mirrored the later
How could Go, then, address all the many needs that would come up in projects with clients? As may already shine through: It didn’t. One of the design goals of Go was, in fact, to not even try. Go defined the very core of Google’s web pages in as simple a fashion as possible, and acknowledged the uniqueness and systemic non-manageability of all the different Google sites by two other decisions:
Define popular page elements (like forms) in an extended library, “Go X” (note for the interested, one was then importing go-x.css, adding truly little and only for that reason acceptable cognitive overhead).
Share the responsibility and leave everything else to the web developer working on the project (so they would import Go or Go X in their default.css project style sheets and do their thing).
Adoption was not only hoped for through ease of use—memorize the style sheet URL, plug into a plain, “common sense” HTML page with a Google logo—but by a few more factors that remind of QC-related logistics:
- a template generator (as this was pre-CMS, it helped the team create quality Go templates);
- a framework announcements mailing list the entire team was subscribed to;
- a framework development mailing list;
- makeshift instructional videos (Asim and I had fun creating those);
- coding guidelines that informed usage.
From a technical perspective, I consider Go one of the most elegant things I’ve so far written. It has been simple, light-weight, robust, extensible, scalable, and maintainable. It to this day comes off basal and unspectacular, but that was all very carefully thought out, and worked extraordinarily well. Eight years later, there’s little I’d change (I’d use newer HTML and CSS features to make Go more compact).
That said, from a tech lead perspective, I had failed to push harder on Go’s adoption. I had made mistakes including and working with other senior developers on the team. I had missed to explain Go’s advantages better, and to get more team and management support. Some team friction as well as much lost time making Go an organizational standard were the result of that. I had to learn.
Fast-forward. The most pressing question I was asking myself in 2012 was, at what point would we build a new framework? (When would you?) The thinking in my head had always been, update, iterate, without versioning, because web design, and development, is a process—and yet, for the first time, I deviated from that position. Why?
When we, still Google’s Webmaster Team, were then working on a new design for all of Google’s informational websites, it was evident that this would have consequences for any of our frameworks. As the lead for the project, at first this looked like a clear case of an update to Go. I did, however, change my mind based on our plans:
- The structure of our demands and our pages was about to change.
- The complexity of our pages was about to increase.
- It could prove useful to have a light-weight framework (Go) as a fallback.
- I wanted to protect the design philosophy behind and integrity of Go, in my not most trusting and team-oriented move (I feared I would lose an important accomplishment and responsibility).
These points led me to support and then spearhead an effort for a new Google web framework, a framework that I dubbed “Maia“ (it’s also still in use, though I’m not sure how much it has been maintained and modified)–“Maia” because of a faible for Greek mythology: Maia, mother of Hermes.
The story of Maia is much different from that of Go, in that Maia was then an officially sanctioned team effort, of a team of five webmasters whose development work I was accountable for. Its process and organization have been very similar, then, to what I describe in The Little Book of HTML/CSS Frameworks—starting with the motivation to build a custom solution to one’s own problems, to founding a team equipped with goals and tools, to communicating to an even wider organization. I believe The Little Book of HTML/CSS Frameworks is a useful book to turn to for that, but I’ll sketch some of the pillars of the work on Maia:
- defining framework design goals and development principles;
- building and organizing a small team of developers and designers (including the fabulous Tony and Zacky);
- setting up a working prototype that also hosts all framework documentation (a practice critical and proven);
- setting up mailing lists for developers and users as well as important announcements.
Apart from the more complex visual and technical demands, developing Maia as a team was the biggest difference to Go, and together with larger management buy-in and support probably the greatest factor in ensuring and accelerating ultimately wide adoption.
I realize I’m keeping Maia’s story brief, ending it abruptly even; yet the very fact that it was a team effort really makes me prefer outlining its very principles with the group, if that was possible.
The above is sprinkled with a few failures and lessons, but here’s what I wish to call out:
This isn’t something I learned at Google—I’ve long been an idealist—but rather something to call out because it’s so important: Not only through the focusing and segmentation of framework responsibilities (as done with Go and Go X) is it absolutely possible to build tailored, efficient, and still usable frameworks, and to maintain them. (That’s also a key point in The Little Book of HTML/CSS Frameworks. There’s no reason to accept bloat and poor quality.)
To build a high quality solution, communication is more important than consensus. I have my problems with democracy as a decision-making tool because I’ve rarely seen it return the best solution—and here, in the technical realm, there often is something like “best” to attain. But I’ve also run into problems ignoring a team to just push solutions that I deemed best. What I’ve made out as middle-ground is to improve communication: Listen to the team, get other team experts involved, get management support, &c.
This didn’t at all come up when I spoke about Maia, and in a way I disagree with my past self: Push until the end before you build another framework. The vision is to iterate and maintain, not to fire and forget. I hadn’t pushed, nor fought; I was cashing in the win with Go and took the comfortable route of halfheartedly guiding a little team to avoid wider organizational confrontation (corporate politics had gotten the better of me, too, it seems). That’s quite different talk here all of a sudden, but I probably chose the technically more complex path by allowing us to work on another framework, thus sacrificing some of what had benefited us the most and had made Go great.
❧ In closing, what I wish now is that there are a few pieces in here that can inform some of your own framework decisions, so that you can reap the rewards that we had reaped, without the mistakes I have made. Even if I’ve been fast admitting them. (And if you want more, check out The Little Book of HTML/CSS Frameworks and my other writings about web development.)
With cordial wishes to everyone on the old Webmaster Team. Working with all of you has been a great honor and pleasure, and I love thinking back to this day.
About the Author
Jens Oliver Meiert is a technical lead and author (sum.cumo, W3C, O’Reilly). He loves trying things, including in the realms of philosophy, art, and adventure. Here on meiert.com he shares and generalizes and exaggerates some of his thoughts and experiences.
If you have any thoughts or questions (or recommendations) about what he writes, leave a comment or a message.
Have a look at the most popular posts, possibly including:
Perhaps my most relevant book: CSS Optimization Basics (2018). Writing CSS is a craft. As craftspeople we strive to write high quality CSS. In CSS Optimization Basics I lay out the, at least some of the most important aspects of such CSS.
Looking for a way to comment? Comments have been disabled, unfortunately.