被靠北游戏业钓上来了，来认真发一个技术文......
不过在这之前，我的主观认定是这样的：
* Web 上，Flash 或插件为主的游戏会在接下来两年逐渐消失
* 手机上，主力仍会是无法在 App Store 或 Google Play 上架的游戏
“大作”仍然会遇到各种麻烦的技术限制
（因为这里是讲免上架 HTML5 浏览器游戏，容我跳过 JS + Native 的方案
例如已经成形的 Cordova / PhoneGap, Titanium 还有很有可能窜起的 react-native）
好了，以下技术长文。
大体来说，现在 HTML5 的游戏技术实践
可以先以 Rendering（渲染）和 Scripting（程式）这两方面去作区别
Rendering 可以走 DOM、2D Canvas 或 WebGL
走 DOM 不用多说，手机看很多网页卷动还是超卡，基本上不实际
2D Canvas 或是 WebGL 才是比较理想的解答，其中 2D Canvas 的支援比较理想。
iOS 直到去年的 8.0 才默认开启 WebGL，所以这可以说是比较新的领域。
WebGL 1.0 其实基本上就是整个 OpenGL ES 2.0 API 开个网页用，
用在游戏上“照理说”可以一样的 3D 效果，但问题卡在 Scripting，后述。
Scripting 的部份，很遗憾目前我们还是只有 JavaScript
目前大概就是纯 JS 与 asm.js (Emscripten) 两个方向了
（tl;dr: JIT 加速 / ES6+ -> GC pauses -> 多绪困境 -> asm.js -> WebAssembly）
这几年纯 JavaScript 如同推文说的，慢的问题已经随着 JIT 解决
语法脏的问题已经随着 ES6 / Harmony 的发展走进历史，ES7+ 根本是外星语言
虽然对于写游戏来讲，我觉得 JavaScript 已经足够，用什么语法只是个人喜好
实务上，像 Chrome 的 V8 都已经作到两段式的 JIT 加速
第一段基础加速，猜测物件型别，在第二段时将瓶颈编译成机器码
所以对于非常简单的 Loop benchmark，现在的 node.js / Chrome / Firefox 都能乐胜
问题在于 JIT 造成的内存消耗，以及最大的致命伤，GC Pauses。
JavaScript 必须仰赖 Garbage Collection（垃圾收集简称 GC）作物件清洁
但垃圾清洁就需要时间，这个时间会变成一个定时炸弹
你永远不知道浏览器什么时候会作 GC，也很难从外界直接干涉
另一个问题大家也讲到了，JavaScript 很难作多序。
JavaScript 一开始就像所有的 UI 框架一样采用单序 Event Loop 的设计
所以到了后来要加上平行运算就只能用像 Web Worker 一样的作法
因为 GC Pauses 与平行运算的限制，WebGL 的 Game Loop 几乎无法作任何复杂运算
但如今产业已经慢慢在克服这个问题，从早期的 asm.js 到现在的 WebAssembly
也许在过几年，我们会慢慢看到不需要插件的复杂 3D 游戏在网页上出现