Which framework is good for web developers

What I learned while developing Google's frameworks

Article dated October 5, 2017. ISSN 1614-3124, # 54.

The often mentioned book on frameworks is also available in German: The little book of HTML / CSS frameworks. It also includes this article.

In The Little Book of HTML / CSS Frameworks I have published an overview and many practical tips on frameworks; I think the book is one of my best works, even if not everyone agrees with its recommendations (in most cases we should avoid external frameworks because they violate the vision or the first paradigm of web development).

But nowhere have I talked about the experience of having developed some larger frameworks - neither about the 2004 framework (even if we didn't call it that at the time) from GMX and partner sites like 1 & 1, which may be the first European billion-euro visitor Website, which meant on valid HTML and completely decoupled CSS (I'm still a little proud of what we achieved back then), over and above the 2008 and 2012 frameworks I built at Google, which ultimately used on tens of thousands of Google websites and have been viewed a few billion times. What follows tells part of the Google story.

This story should begin with the state of Google's information related websites in 2008 when some quality conscious web developers, one of them myself, started working at Google. To say the least, it wasn't nice, and we received a lot of criticism from a variety of respected developers (which made up one of the reasons why it was exciting to join the webmasters team).

From the outside, and quite a few other Googlers were aware, the main problem was the poor code quality of Google's websites and products. The Google homepages got the most attention, but quality problems were not overlooked by experts even with products that were otherwise well received.

From within, and from here on I'll only be talking about Google websites (and no more products), it was clear that we were missing more effective priorities, processes and - more importantly - tools; at the time, most of Google's websites were built and maintained by hand.

The team, especially the core team in Mountain View and a few developers in Zurich, worked on this problem to implement a content management system that also worked in Google dimensions. We regularly published websites and entry pages in dozens of languages, and our code base, HTML documents and other accessories, comprised a six-digit number of files as early as 2008.

A challenge as well as an opportunity was the diversity of the sites and pages we created. Yes, there was a core Google identity and Google was working on a company-wide style guide (Irene's UX organization had taken care of it) - but many of our websites, at least elements on them, were unique and one of a kind. This uniqueness was one reason why there was still no solid technical basis, and I proactively began to develop the first Google’s HTML / CSS framework: Go (it preceded the programming language whose team escaped the name conflict).


Go was special, which is simply due to the unique circumstances. Go is, and even in miniature form you get an impression of it, a compact framework. This is by design. But how was it designed and why? To do this, we should take another look at Google's landscape of websites - a look that is actually mandatory when we design (but also use) frameworks.

Said landscape consisted of an internationally distributed team - the webmaster team - with a colorful mix of internal customers, ranging from Google Corporate Communications to Legal to Marketing, which a large number of very different, localized - up to 40, sometimes 50 languages - Website operation. That created quite a bit of uniqueness. At the same time, all work was done under the umbrella of Google, so some design aspects were shared by all sides.

You can already see that this coherent part was small, and that that, and not the large number of differences, had to make up a central part of Go's vision: Go shouldn't try to cover "everything" we did, but rather work well at the base. Finding and mapping the lowest common denominator, that was the idea.

The next principle behind Go was simplicity, since this simplicity promised great gains: On the one hand, simplicity has a large number of great technical advantages, from higher speed to greater robustness to easier maintainability. On the other hand, simplicity leads to good ones Developer ease of use (Developer friendliness?) Along with something that was relevant to the work on Go, a better chance of acceptance and acceptance.

That chance then resulted in something I want to memorize five or six years after I created the last Go Page; you could write an HTML document like this:

Also dug out by heart, Go then used as few classes and IDs as possible - namely the following:,,, and. The basic page types were full width, full width with navigation, compact (narrow) page, and compact page with navigation. Centering was achieved by the class (on); adding a navigation list () "automatically" created the navigation page types; & c. All of the page types were liquid and inherently mobile-ready. Just to give an impression of the simplicity and ease of use. (When HTML 5 was still germinating and there were no logical properties in CSS, it was based on my preference and reflected the element that was still being planned at the time.)

How did Go then satisfy the many needs that arose in the projects with our internal customers? As it may already shine through: Go didn't do that. Indeed, one of the design goals was not to try this in the first place. Go defined the core of Google's websites in a way that was kept as simple as possible and recognized the uniqueness and systemic unmanageability of all the different Google sites through two other decisions:

  1. defining other popular page elements (such as forms) in a library extension, "Go X" (in this case you imported go-x.css, which meant very little cognitive overhead);

  2. sharing responsibility and leaving everything else to the web developer working on the particular project (so that they would import Go or Go X into their default.css project stylesheet and do their own thing).

I hoped for quick acceptance and acceptance not only through user friendliness - internalize the stylesheet URL and pack it in a simple HTML document with the Google logo - but also through a few other factors that are reminiscent of quality-related logistics:

  • a template generator (since this was pre-CMS, it helped the team create consistent Go templates);
  • an announcement mailing list that featured the entire team;
  • a framework development mailing list;
  • Documentation;
  • improvised videos (Asim and I made this special delight);
  • Code guidelines that directed usage.

From a technical point of view, I think Go is one of the most elegant things I have developed so far. Go was simple, lightweight, robust, expandable, scalable, and maintainable. To this day it seems basic and unspectacular, and that was exactly what was thought out very carefully and worked extremely well. Eight years later, there is little that I would change (I would use newer HTML and CSS features to make Go even more compact).

In spite of all of this, however, I have to say that from a technical and managerial perspective I had failed to find greater acceptance for Go. I made the mistake of including other experienced developers on the team and working better with them. I had neglected to explain Go's advantages in more detail and thus gained more support from the team and management. Some friction in the team and some lost time in making Go the standard were the result. I had to learn.


Forward. One of the most pressing questions I had to ask myself in 2012 was when we would build a new framework. When would you? update, iterate, without versioning, because web design, just as web development, is a process - and yet I deviated from this position for the first time. Why?

When we - still Google's webmaster team - were working on a new design for all information-related Google sites, it was foreseeable that this would have consequences for our use of frameworks. As the head of the project, this only appeared to me after an update for Go. However, I changed that view based on the following considerations:

  • The structure our requirements and our sides was about to change a lot.
  • The complexity our pages would increase.
  • It could be useful and legitimate to have a lightweight framework (Go) as a Fallback to have in the hindquarters.
  • I wanted to protect Go's design philosophy and integrity, which certainly wasn't my most trustful and team-oriented move (I feared I would lose an important achievement and responsibility).

These points led me to support and then lead efforts to develop a new Google web framework, a framework that I dubbed "Maia" (it's also still in use, though I don't know if it's been maintained or how it has been modified a lot) - "Maia" because of a soft spot for Greek mythology: Maia, mother of Hermes.

Maia's story is different from Go, especially in that Maia was an officially sanctioned team venture with a team of five webmasters that I was responsible for. The process and organization were similar to what I was in The Little Book of HTML / CSS Frameworks describe - starting with the motivation to create a tailor-made solution to your own (design) problems, to establishing a team with appropriate goals and tools, to communicating with an even larger organization. I believe that The Little Book of HTML / CSS Frameworks is a useful book for learning more about such development, but here are the cornerstones of Maia work:

  • defining framework design goals and development principles;
  • putting together and organizing a small team of developers and designers (with the great Tony and Zacky);
  • setting up a working prototype that also included all framework documentation (an important and proven approach);
  • setting up mailing lists for developers and users for important announcements.

Apart from the more complex visual and technical requirements, Maia was developing as a team the biggest difference to working on Go, and together with stronger management support, probably the essential factor in ensuring wide-ranging acceptance and even accelerating it.

It is noticeable that I keep Maia's story very briefly, even ending it abruptly; but it is precisely the fact that Maia was teamwork that makes me prefer to talk about this - if that were possible - With to write to the team.


There are already some lessons in what has been said, but this is what I want to emphasize.

  1. Even if I didn't learn this directly from Google - I'm an idealist - I want to mention it because it seems important to me: Not just by focusing and segmenting framework responsibilities (as done with Go and Go X) it is absolutely possible to build and maintain tailored, efficient and still usable frameworks. (This is also a key point in The Little Book of HTML / CSS Frameworks. There's no need to put up with unnecessary code and poor quality.)

  2. 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 rarely see it bring the best solution - and in technical terms there is often such a thing as a "best". But I've also struggled neglecting a team to simply advance the solutions that only I thought were best. An alternative is to improve two-way communication: listening to the team, involving other experts from the team, getting support from management, & c.

  3. This didn't come up when I was talking about Maia, and I also contradict my past self: It is critical to avoid building an additional framework. The vision has to be to iterate and wait, never “fire and forget”. I hadn't tried anything great, hadn't fought; I took the profit I had with Go and then took the easy route of half-heartedly leading a small team in order to avoid confrontation within the organization (corporate policy then reached me too, it seems). It's a very different freak so suddenly, but I had taken the technically inferior path when I admitted to working on a different framework, and thus sacrificed some of what we had previously benefited from and what made Go stand out.

❧ To conclude, I wish there were a few things here that will be useful for your own framework decisions so that you can reap what we have reaped without making the mistakes I made. Even if I only touched it. (And if you like even more, take a look at The Little Book of HTML / CSS Frameworks and my English posts on web development.)

With warm wishes to the old webmaster team. It has been a great honor and pleasure to work with all of you. I like to think back on it.

About me

I'm Jens Oliver Meiert, and I'm an engineering manager and author. I like to experiment, sometimes in the areas of philosophy, art and adventure. Here at meiert.com I share some of my views and experiences.

If you have any questions or suggestions about what I'm writing, feel free to send me a message.