The first years
- 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.
- 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:
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.
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.
Node, ES6 and JS fever
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.
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:
- Babel, RollupJS and Gulp for development
- ES6, Web Components and Observers in our code
- Karma, Jasmine, Jest, Headless browsers and automated browser testing
- AWS CloudFront and Lambda for infrastructure
- And of course, the evergreen and better than ever backend Ad Server that our team builds too.