現在，Require.js是我最喜歡的Javascript程式設計方式。它可以使程式碼化整為零，並且易於管理。而Require.js Optimizer能幫助我們將一個較大的應用分散成多個較小的應用，並且透過依賴串聯起來，最後在編譯打包時合併起來。這些原因促使我們使用require.js。
那麼，讓我們來看看require.js有什麼屌的特性吧！
相容於CommonJS
AMD (非同步模組定義規格) 出現自CommonJS工作群組。 CommonJS旨在創造Javascript的生態系統。 CommonJS的一個重要部分是transport/c， 即AMD的前身，而require.js則是該規範的實作。
CommonJS模組和AMD模組的語法差異，主要由於AMD需要支援瀏覽器的非同步特性。而CommonJS模組則需要同步進行，例如：
var someModule = require( "someModule" );
var anotherModule = require( "anotherModule" );
exports.asplode = function() {
someModule.doTehAwesome();
anotherModule.doMoarAwesome();
};
AMD模組是非同步載入模組的，故而模組定義需要一個陣列作為第一個參數，而模組載入完畢後回呼的函數作為第二個參數傳入。
define( [ "someModule"], function( someModule ) {
return {
asplode: function() {
someModule.doTehAwesome();
// 這將會非同步執行
require( [ "anotherModule" ], function( anotherModule ) {
anotherModule.doMoarAwesome();
});
}
};
});
然而，在require.js中AMD也能相容於CommonJS語法。透過AMD的define函數包裝CommonJS模組，你也可以再AMD中擁有一個CommonJS模組，例如：
define(function( require, exports, module )
var someModule = require( "someModule" );
var anotherModule = require( "anotherModule" );
someModule.doTehAwesome();
anotherModule.doMoarAwesome();
exports.asplode = function() {
someModule.doTehAwesome();
anotherModule.doMoarAwesome();
};
});
實際上，require.js透過函數.toString解釋回呼函數的模組內容，找到其正確的依賴，將其變成一個通常的AMD模組。需要注意，如果你使用這種方式編寫模組，可能會發生與其他AMD載入器不相容的情況，因為這違反了AMD規範，但它能很好的理解這種格式的寫法。
這裡發生了什麼，require.js實際上做了function.toString的回呼函數解析模組的內容，找到正確的依賴，就像它，如果它是一個正常的AMD模組。重要的是要注意，如果您選擇這樣寫模組，他們將最有可能不相容於與其他AMD模組裝載機，因為這違反了AMD規範，但它是很好的了解這個格式存在！
CDN回退
另一個隱藏的require.js瑰寶是，其支援當CDN載入不正確時，回退載入本機對應的函式庫。我們可以透過require.config達到這個目的：
requirejs.config({
paths: {
jquery: [
'//cdnjs.cloudflare.com/ajax/libs/jquery/2.0.0/jquery.min.js',
'lib/jquery'
]
}
});
沒有依賴？對象字面量？沒問題！
當你寫一個沒有任何依賴的模組，並且只是傳回一個物件包含一些功能函數，那麼我們可以使用一個簡單的語法：
define({
forceChoke: function() {
},
forceLighting: function() {
},
forceRun: function() {
}
});
很簡單，也很有用，如果該模組只是功能的集合，或者只是一個資料包。
循環依賴
在某些情況中，我們可能需要模組moduleA和moduleA中的函數需要依賴一些應用。這就是循環依賴。
// js/app/moduleA.js
define( [ "require", "app/app"],
function( require, app ) {
return {
foo: function( title ) {
var app = require( "app/app" );
return app.something();
}
}
}
);
得到模組的位址
如果你需要得到模組的位址，你可以這麼做…
var path = require.toUrl("./style.css");
BaseUrl
通常，在進行的單元測試時，你的原始程式碼可能會放在類似src的資料夾裡，同時，可能你的測試放在類似tests的資料夾裡。這可能比較難讓測試配置正確。
例如我們在tests資料夾有一個index.html文件，需要本地載入tests/spec/*.js。並假設，所有原始程式碼在為src/js/*.js，並有一個main.js在該資料夾。
index.html中，不在載入require.js時設定data-main。
<script><br />
require( [ "../src/js/main.js" ], function() {<br />
require.config({<br />
baseUrl: "../src/js/"<br />
});<br />
<br />
require([ <br />
"./spec/test.spec.js",<br />
"./spec/moar.spec.js"<br />
], function() {<br />
// start your test framework<br />
});<br />
});<br />
</script>
你可以發現main.js被載入。然而由於沒有設定data-main，因此所欲我們需要製定一個baseUrl。而當使用data-main時，baseUrl會根據其設定的檔案來自動設定。
在這裡，你可以看到main.js被載入。然而，由於它沒有載入資料主要腳本標記，那麼您必須指定一個base即可。當資料主要用於baseURL時從主文件中的位置推斷。透過自訂baseUrl我們可以輕鬆地將測試程式碼和應用程式碼分開存放。
JSONP
我們可以這樣處理JSONP終端：
require( [
"http://someapi.com/foo?callback=define"
], function (data) {
console.log(data);
});
對於非AMD庫，使用shim來解決
在許多請款下，我們需要使用非AMD函式庫。例如Backbone和Underscore並未適應AMD規範。而jQuery其實只是將自己定義成一個名為jQuery全域變量，所以對於jQuery什麼都不用做。
幸運的是，我們可以使用shim配置來解決這個問題。
require.config({
paths: {
"backbone": "vendor/backbone",
"underscore": "vendor/underscore"
},
shim: {
"backbone": {
deps: [ "underscore" ],
exports: "Backbone"
},
"underscore": {
exports: "_"
}
}
});
