本文试图阐明2种不同的技术方案：一个是启动到浏览器（如Fire OS, Chrome OS, HP Web OS, Tizen Web Rutime），另外一个我称为浏览器容器化

启动到浏览器相信大家多少已经有了解，它就是通过底层的驱动支持、HTML5 Device API等等，把浏览器内核做成整个操作系统的应用运行时，使用用户的所有应用都可以通过HTML + CSS + JavaScript的方式编写，这无疑节省了程序员大量的时间精力，但问题是，浏览器厂商不思进取，这种Web化应用方案有一些缺点：

1. 可能性能不够；（这可能是JS引擎的JIT还不够好）
2. 可能无法实现用原生UI框架（Android/iOS）能够做到的效果，比如说，自定义布局？灵活的多列+图文环绕的布局？
3. 缺少某些原始TCP/UDP Socket创建功能，WebSocket理论上是纯TCP的，但它不够通过，且依赖于HTTP本身完成会话初始化

来看后一种方案：浏览器容器化，这里的意思是说，不需要“启动到浏览器”，OS还是原来的OS，浏览器作为容器，托管了Web化的应用。照理来说，Emscripten这款LLVM到JS的编译器应该解决了大部分的问题，但它还不够成熟：容器化实际上要求对CPU/IO资源进行可控的管理（灵活调度、按需分配、配额限制），比方说，要能够允许Web应用可以动态调整它可以并发打开的Socket连接、JS执行应该不抢占太多CPU、。。。等等

基本上这2者的差别就相当于Xen/KVM这些虚拟机与Docker这种轻量级容器的差别，只不过一个对应OS和原生应用，一个对应浏览器和Web应用。

顺带说一句，Docker所使用的Overlay文件系统及快速的版本化快照可以视为容器技术的核心特色，那么“浏览器容器化”呢？