高耦和，低內聚，無重用是工程師的三大噩夢，每每工作遇到這樣的代碼，總會夜半驚醒。而移動軟件的模塊化，組件化應該是兩個爛大街的詞。這是一個軟件的代碼量和維持人數上增之後的必然結果。我們知道移動應用業務邏輯達到一定程度，項目工程的代碼就需要進行劃分，如微信Android早期版本使用到的架構。
從圖中可以看到，在業務工程劃分出多個模塊，這些不同模塊可能由於不同的工程師維護，如朋友圈、搖一搖、附近的人等功能依次疊加於該代碼之上。
而組件化是一個更進階的方案，組件化後每個組件都有自己獨立的版本,可以獨立的編譯,測試,打包和部署。當然其依然依賴公共的 基礎庫。如蘑菇街的APP就有這樣的架構。
我們可以認爲模塊化粒度更小，更側重於代碼的重用,而組件化粒度稍大於模塊，更側重於業務解耦。
從以上兩圖可以看出，模塊化，組件化依然依賴我們的公共代碼庫的能力，比如在蘑菇家的架構上，我們可以看到基礎組件，Hybird，或者是圖上未表明Route設計在發揮着它的作用。但是這樣的架構就夠用了麼？先來看看支付寶的首頁
單單這個頁面上有幾十個功能，都是由不同團隊複雜，這樣的一個APP有成千上萬的功能，傳統的組件化無法實現這樣熱插拔的功能，即使內部團隊能夠按照設計標準完成，而外部團隊呢，APP的功能如果由合作伙伴提供的話，這個又是一個問題。在Hybrid概念出來之後，藉助Javascript 調用本地接口的能力，工程師們將接口一一設計出來暴露給Web應用調用。但是這裏也會存在一些問題：
1、團隊構建web應用方式問題。每一個團隊因爲其偏好的原因，使用庫或者工具鏈完全不一致。
2、團隊開發能力問題。不同團隊開發能力不一樣，基礎不一樣，開發出來的應用質量參次不齊。
3、宿主應用技術支撐問題。比如宿主應用提供了緩存能力，但是這個緩存的能力在web標準中併爲涉及。那作爲web應用本身是否有應用到這個能力完全由開發團隊的偏好決定。
於是Web應用給予用戶的產品體驗完全是不可控的。