Browse Prior Art Database

A Method for Server-Driven JavaScript Module Mapping with AMD

IP.com Disclosure Number: IPCOM000244142D
Publication Date: 2015-Nov-13
Document File: 6 page(s) / 87K

Publishing Venue

The IP.com Prior Art Database

Abstract

Disclosed is a method to improve the performance and efficiency of Asynchronous Module Definition (AMD) during JavaScript* development by moving the point of the module mapping from the AMD loader to the server. The key advantage to this approach is that the AMD loader can request modules with no prior knowledge of how these modules have been bundled.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 01 of 6

A Method for Server-Driven JavaScript Module Mapping with AMD

Asynchronous Module Definition (AMD) is a JavaScript* development technique that allows developers to write code as modules and 'required' at run time. This is aids in maintainability of code and ease of development.

The first problem with this approach is that AMD can result in poor performance , as each module needs to be fetched from the server, causing many Hypertext Transfer Protocol (HTTP) requests. To avoid this performance penalty, related modules may be packaged into single JavaScript files (i.e. layers), reducing the number of HTTP requests.

The second problem with this approach is that the AMD module loader needs to be configured to know which modules belong to

which layers. This means that the developer of the system must either know the complete mapping of all modules -to-layers before the application is loaded or update the mapping at run-time. The former option is error prone and difficult to maintain , especially across many teams. Any new module for any given layer must be added back to the 'master' module map. The latter option, to update the mapping at run-time, requires an additional request to get the module that knows how to update the mapping. This can lead to a chicken-and-egg issue, whereby the system does not know the location of the module that may be used to update its mapping.

The novel solution is to move the point of the module mapping from the AMD loader to the server . The key advantage to this approach is that the AMD loader can request modules with no prior knowledge of how these modules have been bundled . A given system may contain JavaScript code consisting of many modules mapped to different layers . The AMD loader has not been configured to know which module is contained in which layer.

Example:


File: component_A/layer_A.js
Contains modules:

component_A/layer_A/module_A

component_A/layer_A/module_B

component_A/layer_A/module_C

File: component_A/layer_B.js

Contains modules:

component_A/layer_B/module_A

1


Page 02 of 6

component_A/layer_B/module_B

component_A/layer_B/module_C

File: component_B/layer_A.js

Contains modules:

component_B/layer_A/module_A

component_B/layer_A/module_B

component_B/layer_A/module_C

The client side code requires two modules: 'component_A/layer_A/module_B' and 'component_B/layer_A/module_A

require(['component_A/layer_A/module_B', 'component_B/layer_A/module_A'], function(module_B, module_A) {

// callback

module_A.doSomething();

module_B.doSomething(); });

With the novel system, the AMD loader has no knowledge of where the modules...