緣由
當我看到_Franky兄的微博的時候：
我覺得我有必要出來詳細說說KMDjs到底有什麼本質上的優勢了，連教主_Franky、貘吃饃香都不能理解他的好處，那麼可想而知，在前端圈、或是全端圈、或是IT圈，能夠理解KMDjs優勢的碼夫更加是屈指可數。
Why Namespace？
KMDjs是能方便組織Namespace，並且Class Base。針對namespace，我還專門整合視覺化庫至KMDjs方便檢視Namespace Tree。那麼Why Namespace?不用會死嗎？答案是：不會。但，但是。我要開始唸書了（摘自《C#基於工程化的實現與擴充套件》）：
尷尬的現實狀況：
是否有很好的名稱空間規劃是工程化程式碼與非工程化程式碼一個明顯的區別。
尤其對於大型的組織而言，如果涉及的產品線、專案、公共平臺很多，如何通過名稱空間把所有的程式碼資源有效地組織起來，恐怕是實施專案前腰考慮的主要問題。作為一個樹形體系，最好有組織級統一的分類標準，目的很明確----用的時候很容易找到。
無論如果，為了您所帶領的團隊現在做的工作在以後能更容易地被應用，或者僅僅為你自己的職業生涯好好“儲蓄”，在動筆編寫第一行程式之前，先規劃好名稱空間吧。
可參考的建議來自Design Guideline,示例程式碼如下：
<Company>.(<Product>|<Technology>)[.<Feature>][.<Subnamespace>]
例如:Microsoft.WindowPhone.DirectX
一個大型軟體企業，總體名稱空間的規劃如下：
Company.Application
Company.Foundation
Company.Framework
Company.Utility
Company.Training
Application:代表專案或產品
Foundation：代表公共庫，類似Enterprise Library之類的公共基礎庫、基於企業裝置和作業系統平臺的通用的圖形處理引擎等，但都是純粹的Class Library，沒有UI元素。
Framework：組織通用的框架，基於Foundation之上，面向某個開發領域補充的Class Library和控制元件，其本身不能獨立執行，但完全可以整合在具體的專案或產品中，比如通用的授權框架，完全AJAX化的前後端組建、報表和列印中介軟體。
Utility:企業內部各種工具，比如現場故障排查工具、Dump和日誌分析工具。
Training：完全面向培訓用途，是對企業自身Application、Foundation、Framework（甚至Utility）使用的Examples。
當然這是作為C#的空間呼叫關係，如果僅是web前端的話，應當把CLR部分去掉，如下：
不論您最終如果定義名稱空間，其實它體現的是您意志中對程式碼資源的規劃。
Who Namespace？
其實早在KMDjs出現之前，google開發團隊早就意識到了Namespace的重要性，就弄個類似的東西。不過實現極度蹩腳。那就是老早以前，其程式碼被噴無數，但依然大名鼎鼎的google-closure-library。比如開啟其date.js，可以看到：
provide是暴露的東西，require是依賴的東西。
寫那麼多不累嗎？從上面其實就可以體現Class Base的重要性，但是我會另開一文詳細談下Why Class ？
微軟的winjs比google進步了不少，至少意識到了namespace和class的重要性：
但winjs還是被kmdjs甩開十條街，因為其沒有從工程化的角度考慮問題。
如果你一輩子就切個頁面寫個焦點圖或者打算一輩子切個頁面寫個焦點圖，請無視名稱空間，繼續require，繼續export，繼續切頁面，寫焦點圖，繼續拿著剛好能餬口的薪水，繼續過著買兩部iPhone6就月光的日子，庸庸碌碌得打發完一輩子寶貴的時光。
棄暗投明
再給自己一次重生的機會，轉生入口：https://github.com/kmdjs/kmdjs