Web Development optimize

Zoosk's 'in a relationship' with Google Closure

Zoosk's VP of engineering explains why their development team chose the scalable Google Closure, a JavaScript tool set, as a replacement to a PHP-based architecture.

This guest post was written by Peter Offringa, VP of engineering, Zoosk.

Zoosk is a fast-growing romantic social network site with a twist. We not only help singles browse, flirt, or find their soul mates. We also help them keep romance alive once they've become a couple by allowing them to share experiences and photos with their friends, create a couple's profile, and more.

The demands that Zoosk developers must meet, both from users and from inside the company, amount to a laundry list of reasons why development groups have increasingly abandoned html page-based architectures in favor of JavaScript apps.

Once our users have filled out their ‘date card' (or dating profile), they're presented with a screen that has multiple tabs, allowing them to search a database of tens of millions of members (in more than twenty-five different languages), call up individual profiles, send messages, chat, wink, or break the ice. There are also numerous conditions where pop-up windows must appear to offer members an upgrade that provides new capabilities.

The engine for all this is a cross-platform application that runs as a desktop client, a web page, and an iPhone, iPad, or Android app. In the beginning, it had a page-based architecture (php), but we soon realized that this approach couldn't deliver the speed and richness we envisioned. Moving to JavaScript seemed like the obvious choice, but such a move would pose a different set of problems: How would it be possible to maintain an application of this size and complexity using a dynamically-typed language, without good tooling support?

Google Closure to the rescue

Our answer was to go with Google Closure. For readers who aren't familiar with Closure, it's a JavaScript tool set originally developed by Google employees as a "20 percent" project. It consists of:

  • A compiler that removes dead code, rewrites and minimizes what's left, and also performs other crucial functions like syntax, variable reference, and type checking.
  • A cross-browser JavaScript library that includes UI widgets and controls as well as lower level utilities for the DOM, server communication, data structures, unit testing and a lot more.
  • A template engine that compiles templates into JavaScript, which can then be fed back into the compiler.

We didn't dive into Closure with both feet. We started out with a single page - the date card, which involves multiple tabs (text, pictures, messaging history) plus chat windows and pop-overs. After that experience, which was positive, we began systematically converting the rest of the pages in our site to JavaScript using the Closure tools.

Of course, we did have other options for our JavaScript stack: jQuery was a contender for DOM manipulation, and we considered several templating alternatives such as Mustache. Early on, we identified the Closure Compiler as the state-of-the-art in JavaScript minification and code analysis. Once you're committed to using the Compiler, you'll get better performance out of it if your library and templates are in compiler-annotated code. Thus the integration points of Closure's components ultimately drove us to use all of them.

As we worked with Closure, a subtle principal of the tools came into focus: this system is designed to scale. Not just in terms of site traffic (which of course it can handle) but in terms of code size, team size, and code re-use. After our humble beginnings with one full-time JS developer, we've advanced. Today, every member of our web team works primarily in Closure; we've added 100K lines of source to our JS codebase; other Closure-based projects are springing up around the company; and code reuse is happening between teams (thanks to shared training and the well-modularized JS code style that Closure allows).

In addition to these major benefits, Closure has lots of small but important features that add up to a smooth and speedy development process. For example, the power of the Compiler allows the use of readable names. Therefore the code becomes self-documenting, so newcomers to a project don't have to struggle to get up to speed. We've also taken advantage of Closure's extension points for L18N.

When Closure was first released, it was not exactly embraced with enthusiasm by the development community. It's true that some of the code looks awkward to a non-closure developer, but that's generally because they're used to compacting their JavaScript code as they write it. Also, Closure was initially released as a suite of separate tools, and we've had to invest time creating our own build system that brings all the pieces together. But all and all, we are very pleased with Closure, and like many of our users, we anticipate a long-term relationship.

Keep your engineering skills up to date by signing up for TechRepublic's free Software Engineer newsletter, delivered each Tuesday.

0 comments