Introduction
- Aubergine
Overview
Backport lets Javascript developers work more easily with the evolving Warzone JS API...Why Backport?
Many years ago I worked on a large project (which used Flash 6 ActionScript, which is based on ECMA-262 and therefore very similar to Javascript) and had to deal with ongoing API changes such as:
- Deprecation of old features, and eventually their removal from the API
- Changes to existing features in new versions
- Features being renamed to avoid naming conflicts and ensure consistent naming
Warzone is already going through these sorts of changes, and will continue to do so as the API evolves.
The problems start when your scripts have to work with multiple versions of the API, because you want to make life easy for end-users. You end up with lots of cruft creeping in to your code to first detect what version of the API you're working with and then adapt to that version of the API. This is relatively easy to add when API changes first occur, but it rarely gets removed afterwards. And it makes code harder to understand and maintain - especially for people not familiar with the older versions of the API.
If you then scale these problems to large numbers of scripts, written by lots of people, over long periods of time, the pain level increases exponentially both for developers (who have to maintain increasingly complex code) and end-users (who get exposed to the resulting bugs and incompatibilities).
One solution would be to stop changing the API. But we don't want to stop changing the API – we want it to keep getting better and better so we can do more awesome things with it.
Another solution is to make all scripts version-specific, so that each time the API is changed new versions of scripts are released. If you've got the infrastructure to achieve this and also the infrastructure to help end-users update to the correct versions of scripts, it's probably the best approach. But Warzone is an open source project with a small number of developers working in their spare time on practically zero budget - it's just not going to be possible to do this.
So that leaves one last option, and it's the option that any web developer will be familiar with: Create something that covers the cracks or make a full abstraction layer.
I'm working on both those approaches. Backport.js covers the cracks (wherever possible) and Vault.js (not released yet) is a full abstraction layer that sits on top of everything.
Backport goals / philosophy
There's no point covering cracks if the result is an ugly mess. That's why Backport has these goals:
- Easy to develop – abstract away complexities
- Easy to deploy – just include() a few scripts
- No code changes – use the normal JS API
- Audit trail – expose information about what's changed
- Low overheads – don't slow scripts down
- Retain originals – allow access to original JS API features
- Unix-like scripts – do one thing and do it well
