Cleartrip Account gets a new front-end architecture

A few days back we launched a shiny new Cleartrip Account. Aside from a host of new features — one-click flight bookings with Expressway, simpler and faster bookings for friends and family and Facebook Connect integration — the biggest piece to this launch is the gorgeous new design.

Hidden underneath that beautiful new user interface is a completely revamped technology architecture, designed from the ground up to exploit the best that modern browsers have to offer. The technology under the hood was the biggest single change that went into the launch and today we’re going to share some of the details about the technology.

Under the hood, it’s a completely new front-end architecture

Our first encounter with HTML5 and CSS3 was while building Cleartrip Mobile for smartphones. Since then, we’ve experimented with CSS3 in small ways on our site. For example, the new buttons we recently introduced across the site. We had shied away from a complete embrace of HTML5 and CSS3 due to the massive development effort required for cross-browser support. In the recent past, however, browsers have been evolving at a pace we’ve never seen before. Support for the HTML5 and CSS3 specifications is getting better with every passing day.

The writing on the wall couldn’t be clearer — we had to move whole-hog to HTML5 and CSS3 and the change would entail completely retooling the way we build and deliver our user interfaces at Cleartrip. In addition to leveraging all the new browser capabilities, our new front-end architecture has also significantly streamlined and simplified our front-end development process.

The debate

One of the key things we wanted to achieve with our new front-end architecture was a transition from the old web paradigm of page-by-page loads to the new single-page paradigm, where static assets are downloaded only once to the browser, after which only dynamically needed data is fetched from the server. Cleartrip Account was long overdue for an overhaul and it was the perfect candidate to serve as a pilot for delivering a single page app.

One of the biggest challenges with building single-page apps is managing the many different states of an application and making them readily accessible — supporting the browser’s back and forward buttons, making URLs bookmarkable etc. As we canvassed the many single-page web apps out there to review their approaches, we found that the most widely used approach involved appending #! (a hashbang) to the ends of URLs. The approach gained popularity when Google announced it as an approach developers could use to allow Google to crawl Ajax-heavy websites. Twitter uses this approach on their web site.

While the approach was widely used in practice, there was plenty that we didn’t like about it — it’s an ugly hack applied to one of the most important components of the web as we know it, the URL. Dan Webb nails down the most problematic areas of the approach in his post, It’s About The Hashbangs, explaining all the reasons why hashbangs are an ugly and temporary hack to the web.

Once you hashbang, you can’t go back. This is probably the stickiest issue. Earlier I stated that URLs are forever, they get indexed and archived and generally kept around. We don’t want to disconnect ourselves from all the valuable links to our content. If you’ve implemented hashbang URLs at any point then want to change them without breaking links the only way you can do it is by running some JavaScript on the root document of your domain. Forever. It’s in no way temporary, you are stuck with it.

At Cleartrip, we’re practitioners of REST-style architectures and we wanted Cleartrip Account to be consistent with that practice. We’ve always cared about URLs and we weren’t ready to compromise that, especially, when the HTML5 History API is now well supported by a variety of popular browsers. We decided to take the opportunity to build a single-page with properly RESTful URLs, which weren’t an ugly hack.

Single page app built on HTML5

Like Cleartrip Mobile for smartphones, the new Cleartrip Account is marked up using HTML5 and delivered as a single-page app using the HTML5 History API to manage different states in the app. There’s a fair amount of behind-the-scenes rigour involved in getting multiple services to work together while effectively managing state on the client side. To make this possible, we’ve knitted several different JavaScript libraries together. This is what our JavaScript stack looks like:

This diagram depicts how the browser and the server interact to display the list of booked trips for a user:

When a browser first makes a request to our web site for a URL starting with /account/ the server returns a static HTML skeleton, along with all the requisite scripts, stylesheets and images. The HTML skeleton already contains placeholders and hooks for all the content that will be fetched on demand. The server ignores any part of the URL after /account/ and simply sends the HTML skeleton to the browser. After the HTML skeleton is sent to the browser, we make an AJAX call to fetch the additional content required to render the correct state and display for the browser. Almost all the templating is managed on the client side in JavaScript; only a few particularly complex views are handled by the server.

The browser never goes back to the server to render different pages or views — static elements of the applicaton like headers and navigation are already downloaded to the browser.

New CSS Framework

With this new architecture, we’ve moved to progressive enhancement with CSS3. To make this leap, we had to completely rethink the way we write our front-end code. We’ve written a new CSS framework for front-end development at Cleartrip and adopted LESS, a dynamic stylesheet language, which has dramatically enhanced the speed with which we can prototype and deliver new products and features. We have a ton more to share about our new framework and approach, but that’s a story for another day.

Now using jQuery

Since we launched, we’ve used prototype.js as our core JavaScript library. Those days are over — our new core JavaScript library is jQuery. jQuery scores well over prototype on many fronts, but access to one of the most active communities was the key advantage which convinced us to switch.

We’ve got a long way to go before our new architecture is perfect, but we’re glad to have gotten our hands dirty with it. We’ve learned a lot and are looking forward to learning even more now that our users can get their hands on it.