|
|
| (3 intermediate revisions by 3 users not shown) |
| Line 1: |
Line 1: |
| The Jetpack architecture is designed to provide a variety of
| | {{Jetpack/Moved to SDK}} |
| 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.
| |
| | |
| The foundation of this standard, the CommonJS module specification, is
| |
| quite simple. Here's an example module, contained in a file called
| |
| <tt>sue.js</tt>:
| |
| | |
| <pre>exports.add = function add(a, b) {
| |
| return a + b;
| |
| }</pre> | |
| | |
| The <tt>exports</tt> 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 <tt>exports</tt>. 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:
| |
| | |
| <pre>var sue = require("sue");
| |
| sue.add(1, 2);</pre>
| |
| | |
| The <tt>require</tt> global function is used to import our
| |
| <tt>sue</tt> module, and it essentially returns the <tt>exports</tt>
| |
| object from <tt>sue</tt>.
| |
| | |
| 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.
| |