Ricardo Vega

Evolution of GumGum’s Third Party Javascript

Over the last 10 years or so we have seen an exponential evolution of the Internet experience, we went from the linear desktop-based low-bandwidth kind-of-ugly interfaces to the modern responsive video-driven asynchronous Web that we all love nowadays. This happened due multiple factors but importantly because of the popularization of JavaScript as the de facto language of the Web Browser.

When GumGum arrived to the Internet Advertising, in 2008, we presented innovative executions as our flagship, we were already pushing the boundaries of what was known and proven for Ad formats. When we introduced In-Image Ads it was something completely new and we had to create the first real-time JavaScript implementation for it.

What is Third Party Javascript?

Third Party Javascript is the JS code from vendors or companies that runs in most websites but is not created by the site owner - for example our ads code, or Facebook buttons or similar widgets from other social networks, code that is created for all kinds of websites, and that must do one or many tasks without compromising the existing site’s code or the user experience. It also helps a lot if its easy to integrate and works well in all kinds of browsers and across the world.

The first years

Since the beginning, the requirements of our innovative products had heavy reliance on JavaScript. Because we were walking an uphill road to sell them, we approached our implementation with these core values:

  • It must be easy to implement by all our publishers
  • It must be fast and performant for all visitors
  • It must to be fail proof
  • It must scale well

All of these might seem very attainable now, with current standards of Web Apps and code, but in 2008 we had a completely different landscape. IE6 and IE7 were kings of the browsers, Microsoft was the market leader and implementation of new tools in IE was sluggish. jQuery was 2 years old and it skyrocketed the web development all over the world. It was great for everyone, but we decided not to use it. It was a hard decision because it could have made our lives as developers much easier but at a high cost - the performance of our services in all our client’s websites.

So we went for a full in-house, mostly hand-crafted solution, that would run on most browsers as fast as possible. This project by itself is difficult enough. In addition to that we also had to implement the backend services at the same time. In spite of the difficulty, we were able to  build our first production ready implementation of a run-time client capable of showing In-Image Ads within relatively short amount of time.

At that point our Javascript technology consisted of the following:

  • Handcrafted EcmaScript 5 code with an in-house component system
  • No jQuery dependency. Only a couple of micro libraries to handle edge cases
  • Same build system as our backend code
  • Deployment with our backend code, and only in US datacenters
  • JSONP communication between client and serve

Products come and go, Visual Web is the king

Naturally as in any other company we tried many different things over time, some worked great and some did not. But over time it seems we got 2 important things right:

  1. Our initial approach proved to be right. The foundation we laid down allowed us to create modules for new products. This was great for our customers because it did not require them to do anything to try new modules. All we had to do was to enable such modules. No modifications or heavy customization per customer and also importantly no impact on the performance.

  2. A picture is worth a thousand words. The future of the web was going to be visual, we had found our thing. Our In-Image Ads and other highly visual formats became successful.

Along with learning a lot about browsers and JavaScript, we also ended up learning a lot about our business.

Node, ES6 and JS fever

Since 2012 more or less, JavaScript has become "the hot technology" in the industry, mostly because a production-ready implementation of JS for the server: NodeJS. And things really took off from here, new technology was being created on top of it, new stacks, new techniques. The developments were so rapid and vibrant that a new term was coined: "JavaScript Fatigue". It was (or still is) hard to keep up.

The critical question at this juncture was, how should the developments in the Javascript world affect our code? We took another values-first decision: not to change our javascript as rapidly as the rest of the world. We could have jumped just right in into each new thing, but we decided to take more time to figure out which one of the new technology would fit our services and serve our clients the best.

In the meantime we spent a lot of effort improving our infrastructure, our creative executions, and our backend performance.

We also underwent a massive expansion with international data centers with new markets and new partners and embraced the mobile world.  We setup a truly global CDN for our JS client and started to use node-based build tools on our dev cycle. On top of all this, we also finally dropped oldest IE browsers from our support grid allowing us to use newer JS functionality. We spent a lot of effort on safely modernizing our code. At this point the core of our client side code was still solid and performing well, "if it ain't broke...".

The Programmatic era

Around 2012, Advertising Industry was changing rapidly with the advent of programmatic advertising. Millions of transactions per minute without the need of human intervention across different platforms. Nobody could stay aside, if our technology wasn't capable of participating in Real time bidding, we were out.

Happily our JS client code foundation was still strong. We found newer ways to deliver, tweaked wherever needed, but at heart the values of the code remained the same. At the same time we also started realizing its age. The main challenge at the time  was to serve the javascript through all the different programmatic pipes.  It was a new medium for us - in which we sometimes have to give up the control completely. What it meant for us was we no longer could depend on our multi-purpose client code. We had to trust  all the new platforms for RTB, Header Bidding and other technologies to do some heavy lifting for us.

2017, 2018 and beyond

At GumGum we have always loved a new challenge, and the current one is the big one; the industry has changed a lot these past years and now more than ever it looks like we need more flexibility while infusing new life into our core values:

  • Be mobile. Be ready for what’s next.
  • Performance, performance, performance.
  • Easy to use, easy to integrate, be flexible.
  • Be safe, be good for the user.

In 2018 we are working on brand new technology, splitting concerns of our Advertising model and client code, using the best of the modern browsers and of our infrastructure. We are writing new ES6 modular code that can be easily reused and bundled for better file sizes and performance than before. We are using modern web standards like Custom Elements API to be flexible and expand our reach, we'll use the latest technology to write safe code that is automatically tested and deployed globally.

We're keeping our dependencies to a minimum and using "the platform" (the browser, in web lingo) wherever possible. We are also testing latest technologies like Web Assembly, Workers and other still experimental features. We can now also aim code to specific users, so that modern browsers will use the latest, and not-so-modern browsers will get our battle tested code with better performance.

Today our stack, though work in progress, looks like the following:

These are exciting times for us at GumGum Advertising, and we the Ad JS development team is eager to continue our journey into the world of 3rd Party JavaScript, and face all of its challenges and constraints.

Guides