以Javascript判定Web App太慢是否合理？

        Drew Crawford 的《Web App 真的很慢》 一文一經發表即引來轟動討論，無數的評論、tweet 皆圍繞 web app 與 native app 性能之問相持不下。依據 Drew 的觀點——web app 由 Javascript 寫成，但 Javascript 對于 Web app 來說是不可取的，因為速度太慢，而且影響體驗，這個狀況在中短期內（5-10 年）都不會有顯著改善。

        這是否意味著開發者收拾好 web app 的包袱，站回 native app 陣營才是上策？

        No。

        Drew 認為，當有垃圾回收的需求時，Javascript 提供的可替代性選擇非常少，因此開發者必須妥善管理內存。他由此建議那些十分容易因為垃圾回收而引發瞬間中斷的 app，嘗試一下 native 在這方面的良好表現，因為 native 可以合理地執行內存管理。

        但 Drew 忽略了一個事實，JS 只不過是影響 web app 性能的一個子因素，除了 JS，HTML、CSS、SVG 都在消耗著 CPU/GPU，甚至有一些 web app 的布局和對 HTML/CSS/SVG 的渲染占用了絕大多數的 CPU（甚至不用 JS 寫出一個游戲也是可能的）。這說明垃圾回收只占用 web app 整體執行中的一小部分運算空間，換言之，JS 僅僅只是 web app 代碼的一部分，它的優缺點也僅能影響到被它把控的那部分運算。

        但也有人會問：為什么我們要選擇一個運算速度比 native 慢的語言？難道“以快取勝”不是每個人都想要的嗎？

        這個問題的答案正如 Drew 文中指出的那樣：對于開發者來說，產出效率是很重要的衡量指標。他以 hashmap（基 于哈希表的 Map 接口，提供可選的映射操作）舉例，很多托管語言中都會內置 hashmap，但通常 native app 中的 hashmap 不是因為更新慢而過于難用，就是選擇自己開發一個 hashmap 而非使用現有的接口。所以許多開發者有了使用 JS 的動力，因為 JS 使用起來簡單易行，兼有動態屬性，并且 JS 語言支持跨平臺與多種設備，但 native 代碼只針對某一個特定的平臺。因此哪怕在性能上略有丟失，多平臺和廣泛的受眾到達仍然會吸引許多開發者選擇 JS。

        另外若可善用 JS，實際上可以在瀏覽器引擎中實現類似 native 的效果。因為我曾經嘗試過，一段簡短的 JS 代碼便可讓瀏覽器引擎實現從 CSS 布局、重塑到硬件實現的加速動畫等多種 native 功能。事實上，即便假設 native 圖形數據庫可以提供和瀏覽器引擎相近的圖形、動畫、布局功能，我也不認為 native 能做到 web 平臺給桌面端帶來的同樣靈活度和普遍性的到達效果。

        最后，web app 不僅僅只是簡單的客戶端代碼。就 web 的核心概念來說，“分發”、“內容”和“代碼”同等重要。web app 可以通過 web 來分發其計算需求，比如 3D 協作 app Lagoa。Lagoa 就是將計算需求交給云端，從而實現了 native 代碼都無法實現的效果的絕佳例子。

        因此，速度并非開發者在選擇 web app 和 native app 中做選擇的最關鍵因素，出于速度的原因而一頭扎進 native app 中是不明智的論調。最終的決定還要看開發者在高生產力、高普及性與運行性能間的取舍。       

英文原文：are mobile web apps slow