順應瀏覽器的特性§ 1

XMLHttpRequest(XHR) 載入器僅限於與頁面相同的網域，且會讓除錯更困難。某些瀏覽器允許跨網域 XHR 呼叫，並在使用 eval 時提供更佳的除錯慣例，但支援度因瀏覽器而異。

基於 eval 的載入器應避免使用，因為 eval 並非 JavaScript 的最佳實務，且在某些環境中不允許使用。eval 有其適用的時機和地點，但模組載入器可以做得比使用它更好。

也不需要伺服器程序來即時轉換腳本。讓所有人使用相同的伺服器程序，甚至為它們可以發出的通用格式制定規範，都是額外的負擔，需要撰寫更多程式碼。前端開發人員長期以來都習慣撰寫純文字檔，並讓它們在瀏覽器中載入，而不需要大量的伺服器硬體。

透過腳本標籤載入的腳本可以在任何地方使用，且可以在網域間使用。這是一種更簡單的載入樣式，它使用瀏覽器載入腳本的自然方式。

在頁面載入之前和之後載入程式碼§ 2

相同的系統應該可以在頁面載入之前和之後使用。延後載入程式碼，直到稍後的頁面動作，是關鍵的效能優勢。

腳本應該能夠指定依賴項§ 3

專案很容易超出需要幾個腳本的範圍。手動追蹤所有依賴關係和正確的載入順序很困難。腳本應該能夠指定其直接依賴關係。開發人員不應該擔心這些依賴關係需要載入什麼，並找出正確的載入順序。

載入器應該能夠載入巢狀依賴關係§ 4

如果每個模組指定其自己的直接依賴關係，載入器應該能夠找出整個系統中正確的依賴關係，甚至是巢狀依賴關係，也就是依賴關係的依賴關係。

腳本可以按順序評估，但模組需要根據依賴關係進行評估§ 5

使用具有巢狀依賴關係解析功能且在頁面載入後運作的瀏覽器原生腳本載入，表示腳本需要透過使用 appendChild 載入至少部分時間的腳本元素。

IE 和 WebKit 會執行透過 appendChild 新增的腳本，但不是依據 DOM 順序，而是依據網路接收順序執行。即使它們執行腳本的順序與其新增至 DOM 的順序相同，模組的依賴關係也是在載入模組腳本後才發現，因此依賴關係的腳本總是會在需要它們的腳本之後新增。

這會導致為腳本建構模組格式，將腳本主體放入函式中，並在其函式包裝器外部指定其依賴關係。這允許瀏覽器按順序評估腳本，但提供適當找出依賴關係的機會，然後按正確順序呼叫函式包裝器來建立腳本。

模組格式應該簡潔§ 6

樣板程式碼很麻煩。然而，函式包裝器是樣板程式碼的一部分。最好讓樣板程式碼盡可能簡潔，以利開發人員輕鬆手動編寫程式碼。避免使用過於明確的模組格式，為每個屬性使用名稱/值對，因為開發人員必須手動編寫這些程式碼。

擁有簡化的核心載入器，但允許未來擴充§ 7

載入器的核心，具備巢狀依賴關係解析功能的模組格式支援，應該簡潔，但允許外掛程式擴充依賴關係的概念及其載入方式。

在 Dojo 中，通常需要小工具建構的 i18n 字串組和 HTML 文字字串。允許載入器能夠載入這些內容，但作為外掛程式，因此核心保持輕量化。

允許模組保有乾淨的全局命名空間§ 8

隨著專案變大，在頁面中載入兩個模組版本的機會越來越常見。這應該能透過允許模組系統在全局命名空間中不定義模組的方式來實現。

如果模組想要與全局命名空間一起使用，這通常很容易在模組規格中允許。較困難的部分是建構一個格式，以避免全局命名空間運作良好。

載入任何指令碼§ 9

並非所有指令碼都會使用模組格式。允許載入現有指令碼並將其視為依賴項。

允許效能升級§ 10

這主要表示擁有能結合並最佳化模組的建置系統。這也表示載入器應該允許載入定義多個模組的指令碼，並僅擷取未包含在該指令碼檔案中的依賴項。