InfoWorld: Explain the workings of RequireJS.
Burke: It uses script tags to load modules but relies on a "define" function wrapper that is placed around the modules. So those scripts can be loaded async and out of order but then executed in proper dependency sequence based on the dependencies specified in the define wrapper. By using a define function wrapper, it avoids XMLHttpRequest and eval usage, which means the modules are easier to use in cross-domain/CDN situations and where CSP (Content Security Policy) in the Web page prevents eval use. It uses string module IDs to reference dependencies, and it has a convention to convert those IDs to file paths as well as configuration options to control that ID-to-path conversion.
InfoWorld: How widespread is usage of RequireJS?
InfoWorld: At what stage of development is RequireJS? How old is the project? What version are you on at this point?
Burke: First commit to the repo was in September of 2009, but it was called runjs at that point. Over time and after more discussions of the module API with others, it was renamed to RequireJS. There were many 0.X releases. A 1.0 [release was] announced October 18, 2011. It's now in a 2.1.x stage of releases, with it very stable. 2.1.11 is the latest release, done in February. I do regular maintenance releases about one every few months. I am into fixing bugs for the 2.1.12 release at the moment. I am planning a 3.0 release to align better with any changes that are coming with ECMAScript 6, including modules in the language. But that's still in the early planning stages since ES6 modules, along with its module loader API, are still underspecified. [Also for the future,] I should also be able to lose some of the legacy browser hacks too, and rely on promises in the platform over time to shrink the overall size of the loader.
InfoWorld: Why is it called RequireJS?
Burke: It was originally runjs. But I thought I was able to bridge the CommonJS module system with what was needed for the browser and the main API in that system, as well as in AMD, for referencing a dependency is the require API. In retrospect, it was probably premature to use that name, as later discussions with the CommonJS folks made it clear there were some fundamental differences that could not be bridged and which led to AMD modules becoming a separate API. If I were to do it over again, I would probably pick a different name, not something based on one of the module API calls, just to avoid any secondary confusion. However, it grew organically and started to gain adoption, and the name stuck.