JavaScript的模組載入可能有害

　　就像原文評論所指出，作者批評的是在前端領域過度使用非同步模組載入方式。通常的Web應用會對JavaScript檔案進行合併，壓縮（Minify）以減小連線數，和檔案體積，以更好的利用快取，提升使用者體驗。原先的JS原始檔最終會變化一個或兩個上線。這跟後端（NodeJS）分散的程式碼組織方式會有所不同。

　　簡介

　　我最近傾向一個觀點：JavaScript的模組載入是非常不好的，我認為從總體上來說，這不是一個好主意。其實也有適合他們應用的場合，最後我會提到。

　　現在，估計我是這裡的少數派。除了CommonJS和AMD模組載入方式, (參見：JavaScript模組化程式設計：AMD規範及require.js用法)，其他載入系統像RequireJS或者（說實話我非常吃驚）Google Module Server，Node濃重的文化正在影響著Javascript世界，你很難去說JavaScript模組載入的不好。純指令碼太老了，太傻了，太不方便了。每個人都知道，所以他們不會指責自己喜歡的東西，對嗎？

　　我準備走出這個群體，並說：“JavaScript模組載入可能有害”，下面希望我能說服你認同我。

　　危害#1：混亂的除錯

　　模組載入機制在一些明顯和微妙的地方除錯困難。

　　壓縮，轉換還有其他的預處理都支援模組載入（有些其實並不是必須，僅是為了保持一致），從原檔案載入模組通常都是由瀏覽器來完成的。所以當你除錯程式碼時經瀏覽器載入的程式碼經常會與實際程式碼不匹配。Source Maps可以解決這個問題，但在高度其它瀏覽器時還是會有問題。(注*Source Maps為一種新的排程方法)

　　通常，在原始碼沒有改變或者source maps正常工作時，模組載入所產生的動態標籤會產生一些問題。偵錯程式可能無法區別在頁面載入時裝載的指令碼，例如，如果不寫成內聯的script標籤，你設定的斷點可能消失。

　　其實很難評價模組載入所帶來的便利和他們所引起的問題，總的來說他們應該幫助你組織結構和保持簡單，而不是增加工作量。

　　危害#2：模組載入順序

　　也許模組載入的最常見和折磨人的瓿就是指令碼的載入順序。跟在你的頁面按順序載入SCRIPT標籤相比，理解模組何時被執行是非常折騰的人的。

　　通常最先載入的模組會被執行，但內部模組依賴決定了他需要等依辣的模組載入完了才執行。

　　這有一個明顯的優點，可以幫助我們定義並理解依辣關係，這些引用可以通過require()呼叫清晰地表達出來，是非常令人欽佩的。

　　然後，實際情況裡，我們的專案通常沒有如此複雜的內部模組依賴。

　　危害#3:工作併發症

　　顯而易見，使用模組載入系統代替簡單的指令碼工作起來非常困難。

　　因為整合這個眾所周知的困難，很多第三方庫並不使用相似的模組載入系統。多個系統會讓他的工作更加複雜。這些庫的作者不得不新增將模組新增額外的封裝，以便不同的模組載入系統去呼叫，不管使用者是不是採用。

　　當你帶一位新的程式設計師到一個專案中，或者一個程式設計師找到一個有用庫，但這個庫使用模組載入（如RequireJS）組織，這就給他帶來了一些障礙，其實他只想新增一個簡單的script。這值得嗎？我擔心這樣會導致我們的系統碎片化。

　　結論

　　最後還是要看這種載入方式所帶來的便利性和成本的對比，如果載入方式帶來的便利性大於支出，說它有害是沒有道理的。比如你有一個非常龐大的程式碼庫，如果一開始就載入所有內容會影響效能，使用者體驗時，你可以採用。

　　原文 techblog.ironfroggy.com