以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