為什麼前端盡量少用iframe？

01-21

最近在做一個項目，前端引擎是velocity。
布局如下：

左邊菜單是頂部菜單的下級，本身也包含多級，可伸縮。
在布局的時候嵌套了2個iframe，分別是圖中紅、藍部分。初衷是為了方便維護，而且代碼量也更少，主頁面在紅色iframe里打開就可以了。
但是被一位前輩說了，iframe用太多，影響載入速度，還有兼容性問題，不過他重點放在數據傳遞的問題上，點擊頂部菜單的時候，藍色部分怎麼獲取變更通知。
我是覺得，如果把菜單都用velocity的control封裝起來，每個頁面打開的時候都需要重新載入一遍head、foot、還有2個菜單模塊，渲染速度不是一樣有問題？

而且菜單都是資料庫配置的，點擊左邊菜單的時候，需要重新定位頂部和左邊菜單的「當前選中」狀態，如果沒有後端配合，怎麼實現？目前能想到的就辦法就是靠後端傳值了。

因為iframe等於打開一個新的網頁，所有的JS/CSS全部載入一遍，內存會*2，無法釋放，典型的內存泄露，GOOGLE很多啊，這個問題

(以EXTJS3,+ FF為例，每次刷新頁面，內存增加8M，不釋放！如果2個小時不關，瀏覽器內存消耗500M)

我也補充個，其他技術博客上看來的

1：iframe會阻塞主頁面的Onload事件；

2：iframe和主頁面共享連接池，而瀏覽器對相同域的連接有限制，所以會影響頁面的並行載入。

我補充一個，移動端對iframe不友好

盡量少用不是不用。

首先iframe算是一個過時的技術，已經被新工具取代。

其次，iframe是(幾乎)不能訪問外部數據的，js的作用域也會很奇怪。

如果有局部刷新需求，重型的上MVVM或者databinding框架，輕型的上ajax。

有iframe潔癖的(比如我，連php，裸html，裸xml都忍不了，何況你iframe乎)絕對不會碰，不過要是給(足夠的)錢，一切好說。

很簡單的一個例子:統計代碼對iframe不友好

做過兩次登錄註冊使用iframe，出於組件化開發考慮，把登錄註冊彈框做成通用插件，那麼就要用到iframe，可能最大的問題是跨域問題，其他也沒什麼，而且只要你父頁面和子頁面的頂級域名是一致的，跨域問題也很好解決，兩邊都設置document.domain就Ok啦。所以有的時候是必要的，看具體情境下是否利大於弊從而進行權衡。

補充一下

兩年前做過一個項目，和題主類似，頁面布局的時候，頂部導航，左邊菜單，以及右邊主內容區域，都使用了iframe，

當時是基於布局方便考慮的，沒成想這是一個巨大的坑，內容區域iframe高度自適應可把我們坑苦了，然後布局上出現各種怪異的問題，

看了這麼多,我決定不用iframe了

為什麼要這麼做，公共模塊用include不就好了。一個iframe就是開了一個新窗口

類似上述結構，大神們用的什麼方法實現的？