被靠北遊戲業釣上來了，來認真發一個技術文......
不過在這之前，我的主觀認定是這樣的：
* 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 遊戲在網頁上出現