Labs/Jetpack/Reboot/Architecture Overview

The Jetpack architecture is designed to provide a variety of advantages over traditional extension development, while building on the existing extension architecture in a way that allows both Mozilla newcomers and veterans alike to easily create powerful, secure extensions.

The key design principles for this new architecture are:

• Modular functionality. Providing a simple, standards-compliant way to create and share modules and packages of code that can exist side-by-side different versions of one another will help encourage code reuse—not only among Jetpack developers, but among the JavaScript community as a whole.

• Developer ergonomics. It must be as easy as possible for developers to figure out why their code is behaving the way it is. This means a quick edit-compile-test loop, full stack tracebacks when something goes wrong, built-in logging, debugging functionality, and other features present in many modern development environments.

• High quality. Tools and associated best practices should exist to make it as easy and straightforward as possible to create code that is robust and fault-tolerant. This means, for instance, that writing test suites for one's code should be as easy as possible, and ensuring one's code has no memory leaks should be straightforward too.

• Zero restarts. It must be possible for Jetpacks to be installed, uninstalled, and upgraded without requiring the end-user to restart their browser.

• Security. Within the constraints of pragmatism, Jetpacks should obey the Principle of Least Authority, i.e. be given access only to what they need to accomplish their task. This ensures that if the Jetpack is somehow compromised, the user's system is placed at as little risk as possible.

Modular Functionality

The Jetpack architecture uses the CommonJS Standard when possible. This standard helps ensure that code can be reused across multiple JS frameworks, such as on a Web page, in a Jetpack, or on a server. It also serves as a sort of dynamic linker that can connect the client of an interface with an actual implementation—something typically done on the Mozilla platform by XPCOM.

The foundation of this standard, the CommonJS module specification, is quite simple. Here's an example module, contained in a file called sue.js:

exports.add = function add(a, b) {
  return a + b;
}

The exports global above starts out as an "empty" object. To export data, functions, or objects for use by other code, a module simply "attaches" things to exports. Everything else is part of the module's private global scope, ensuring that namespace conflicts don't occur.

Using this module from another file is easy:

var sue = require("sue");
sue.add(1, 2);

The require global function is used to import our sue module, and it essentially returns the exports object from sue.

In addition to CommonJS modules, the Jetpack architecture provides a way to group several modules, their testing suites, documentation, data files, and other resources into packages.