本文部分摘录自互联网。
Chromeium与Chrome
Chromium是Google为发展自家的浏览器Google Chrome而打开的项目，所以Chromium相当于Google Chrome的工程版或称实验版（尽管Google Chrome自身也有β版阶段），新功能会率先在Chromium上实现，待验证后才会应用在Google Chrome上，故Google Chrome的功能会相对落后但较稳定。
Chromium的更新速度很快，每隔数小时即有新的开发版本发布，而且可以免安装，下载zip封装版后解压缩即可使用（Windows下也有安装版）。Chrome虽然理论上也可以免安装，但Google仅提供安装版。
Google Chrome是基于Chromium制造，但包含非开放源代码包，主要是多媒体相关。
Blink
Google希望未来在Blink中加入的新技术如下：
实现跨进程的iframe。iframe允许网页中嵌入其他页面，这存在潜在的安全问题。一个新的想法就是为iframe创建一个单独的沙箱进程。该部分的介绍在第12章展开。
重新整理和修改WebKit关于网络方面的架构和接口。长期以来，WebKit中的一些实现是以Mac OS平台为基础的，所以存在某些方面的限制，Blink将会在这方面做比较大的调整。
一个更为胆大更为激进的想法就是将DOM树引入JavaScript引擎中。由前面的介绍可以看到，目前DOM和JavaScript引擎是分开的，这意味着JavaScript引擎访问DOM树需要较高的代价。笔者认为这是一个大胆而又具有革命性的尝试，会带来性能的极大提升，为什么呢？原因是JavaScript引擎访问DOM树需要额外的负担，这影响了访问速度。
就是针对各种技术的性能优化，包括但是不限于图形、JavaScript引擎、内存使用、编译的二进制文件大小等。
whatwg与w3c
浏览器厂商和标准组织博弈出来的产物，重要的是明白它们背后的人是谁。WHATWG受到了Opera, Mozilla和Chrome, Safari的支持，而W3C的背后则隐藏着IE这个微软菊苣。私以为在工业发展速度远远超过标准定义的今天，WHATWG或许会更权威一点。关于HTML5标准的定制，最开始是WHATWG在做的，由于到后期大部分浏览器厂商都已经实现了统一标准，W3C想不支持也是不行的啊，这就是传说中的霸王硬上弓
xhtml还是html
总的来说我还是更喜欢html一点，尽管xhtml更加的规范，但我觉得怎么编写代码是开发人员自身的问题，而不应该将其强制，比如：单标签的闭合，我觉得单标签闭合可有可无。
html5
一次编写，到处运行(Write once, Run anywhere)是每一个程序员的梦想。当年的Java没有做到，原本程序员们指望Web标准能够做到。然而事实上是，只要浏览器大战没有消停，HTML5也做不到。
有人说HTML5不好，因为用户讨厌打开浏览器输入URL的过程。我想说这种想法是对HTML5的片面理解。HTML5!=传统浏览器，虽然编程语言还是HTML、Javascript、CSS，但发行方式绝不是传统网站那么简单。HTML5应用的入口，反而很少是启动浏览器输入URL，它可以是存在于手机桌面的图标、也可以来自超级App（如微信朋友圈）、以及搜索引擎、应用市场、广告联盟，到处都是它的入口。它的入口，比原生App更多。
目前各路浏览器厂商、应用市场厂商、甚至rom厂商，都在努力整合更优质的浏览器引擎。假使微信内嵌的webview可以运行更优秀的canvas游戏、假使360手机助手可以发行即点即用的HTML5应用并且能力体验与原生一致、假使小米rom内置更强大的webview使得所有HTML5应用在小米手机上运行的更流畅。所有巨头都会闻风而动，没错，这场战役会是移动互联网世界的二次世界大战。
早期HTML只需要记事本写几个Tag，中期的HTML、JS、CSS比较复杂，需要更高级的文本编辑器，但HTML5到来后，它的代码量、复杂度、开发模型将与原生开发看齐，需要类似XCode、Eclipse等专业的IDE工具来解决开发、调试的问题。一些以会使用记事本写代码为荣的开发者，将面临思路转换甚至被更高效的开发者淘汰。
web的不断发展意味着，会有更多的api，因此如果我们还靠去死记硬背是不行的了，同时也意味着你不可能将web的所有技术掌握，我们需要更强大的IDE工具，以及学习能力。
混乱的用户代理
早期内容供应商为了给用户提供更好的网站体验，为不同的浏览器提供了不同的内容，而IE厂商发现，很多内容供应商为Mozilla提供的内容比自己更加的丰富，后来IE厂商想出了一个法子，在用户代理中加入一条Mozilla的信息，后来其他浏览器厂商也纷纷效仿，导致最后用户代理异常混乱。
既然选择所有浏览器厂商都这样做了，还使用这种方式就没有什么用处了，我想以后浏览器厂商会重新回归到最初。
用户代理可以做什么
通过用户代理，我们可以用来判断用户使用的是什么浏览器，而根据浏览器的不同，使用不同的样式，又或是一次兼容问题，但如果涉及到一些安全性问题，千万别通过用户代理来判断，因为用户代理是可以通过人工修改的。
推荐阅读：自定义UserAgent绕过安全狗
更改Chrome用户代理
chrome 下修改 agent 的方法
Change User Agent in Google Chrome
浏览器USER-AGENT（用户代理）的介绍
浏览器内核
虽然使用Linux内核的操作系统非常多，但某些操作系统对内核做了很多改变，因此虽然很多操作系统使用的内核是一样的，但它们的差别还是很大的。
之前比较疑问，既然移动端大部分浏览器使用的是webkit内核的，但是显示出的效果差别却那么大，今天算是明白了，虽然它们是同一个内核，但是每个浏览器厂商却做了不同的处理。
多线程
一个应用程序是否是多线程，不仅仅是应用程序的问题，更取决于操作系统是否支持多线程，因为你的程序是在人家操作系统上跑的。
webkit于webkit2
WebKit2是面向WebKit的一个新的API层，从底层设计，以支持拆分过程模型，其中Web内容（JavaScript，HTML，布局等）与应用程序UI在一个单独的过程中。 该模型与Google Chrome提供的模式非常相似，主要区别在于我们将流程分割模型直接构建到框架中，允许WebKit的其他客户端使用它。
这与Chromium WebKit有何不同？
Chromium采用不同的多进程方法：
请注意，在这种情况下，进程边界是*以上的API边界。 Chromium WebKit不直接提供多进程框架，而是针对多进程应用程序的一个组件进行了优化，它可以执行所有代理和进程管理。谷歌的Chrome团队在开发Chrome浏览器的多进程浏览方面做得非常出色。但是很难重用他们的工作，因为进程管理，流程和沙盒之间的代理关键逻辑都是Chrome应用程序的一部分，而不是API层的一部分。因此，如果另一个基于WebKit的应用程序或另一个端口想要基于Chromium WebKit进行多进程，则需要重新创建或剪切并粘贴大量代码。
这是Google的一个可以理解的选择 - Chrome被开发为一个秘密项目多年，并且深入投资于这种方法。此外，还没有任何其他重要的API客户端。有Chrome浏览器，然后有紧密相关的Chrome框架。
WebKit2有一个不同的目标 - 我们希望流程管理成为WebKit本身提供的一部分，以便任何应用程序都可以轻松使用。我们希望聊天客户端，邮件客户端，twitter客户端以及人们使用WebKit构建的所有创意应用程序，以便能够利用此技术。我们相信这是Web内容引擎应该提供的基本部分。