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

此文由Adobe Web Platform团队的工程师Vincent Hardy发表于Adobe博客上。Adobe Web Platform团队在为Web标准 (CSS、FX Task force、SVG)、开源项目(WebKit、 Chromium Embedded Framework)和Apache Cordova项目做努力，想让开发者可以使用JS、CSS和HTML5来写native 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中是不明智的论调。最终的决定还要看开发者在高生产力、高普及性与运行性能间的取舍。

更多web app的讨论，请见北极社区讨论列：Web App