本文部分摘录自互联网。
Chromeium与Chrome
Chromium是Google为发展自家的浏览器Google Chrome而打开的项目，所以Chromium相当于Google Chrome的工程版或称实验版（尽管Google Chrome自身也有β版阶段），新功能会率先在Chromium上实现，待验证后才会应用在Google Chrome上，故Google Chrome的功能会相对落后但较稳定。
Chromium的更新速度很快，每隔数小时即有新的开发版本发布，而且可以免安装，下载zip封装版后解压缩即可使用（Windows下也有安装版）。Chrome虽然理论上也可以免安装，但Google仅提供安装版。
Google Chrome是基于Chromium制造，但包含非开放源代码包，主要是多媒体相关。
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更加的规范，但我觉得怎么编写代码是开发人员自身的问题，而不应该将其强制，比如：单标签的闭合，我觉得单标签闭合可有可无。
一次编写，到处运行(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的信息，后来其他浏览器厂商也纷纷效仿，导致最后用户代理异常混乱。
既然选择所有浏览器厂商都这样做了，还使用这种方式就没有什么用处了，我想以后浏览器厂商会重新回归到最初。
用户代理可以做什么
通过用户代理，我们可以用来判断用户使用的是什么浏览器，而根据浏览器的不同，使用不同的样式，又或是一次兼容问题，但如果涉及到一些安全性问题，千万别通过用户代理来判断，因为用户代理是可以通过人工修改的。
推荐阅读：
更改Chrome用户代理
浏览器内核
虽然使用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内容引擎应该提供的基本部分。
阅读(...) 评论()手机号码：
所在地区：
学员留言：
* 温馨提示:如果24小时内没有与您回复请直接电话联系学校，以免耽误您的报名!
小贴士：本页信息由用户及第三方发布，真实性、合法性由发布人负责，详情请阅读求学快递网免责条款。
本站所有课程均为网民自行发布，报名时请自行核查课程真实性，谨防上当受骗，举报邮件
让我们携手共同为中国教育事业的发展做出更多的贡献 无偿为学习者与教育者搭建免费资源共享信息发布平台
,免费招生信息,本站所有资源均来源于各网友上传分享,如果涉及任何版权方面的问题,请与本站联系,详见！javascript
webpack（1）
安装whatwg-fetch(和ajax一样，新的获取数据方式,支持语法)获取数据。安装方法：
npm install whatwg-fetch --
bower install fetch.
导入依赖。注意这里的导入只能使用**import 'whatwg-fetch';**接着是发送xhr请求的代码，我们将其封装成一个方法，如下
function myFetch(Url){
fetch(Url)
.then(function(response) {
console.log(response);
return response.text();
.then((data) =& {
console.log(data);
}).catch(e=&{console.log(e);})
解释下：以上方法接收一个url请求地址，请求后返回一个response文本。打印出来如下：
可见这个对象有一些自己的方法如OK、status等还有些原型方法如text()等。这里我们将text()的内容返回。
3. 接着将其暴露出去，给其他js文件引用。module.exports = myF
4. 定义另一个index.js文件，代码如下：
import myFetch from './index6'
myFetch("http://localhost:3000/users");
解释：从之前的文件导出myfetch方法并调用。其中from后面跟的是之前的js所在相对路径。
这个方法访问的是监听在3000端口的一个服务端程序。这里我们直接使用node搭建一个建议的web服务器。
5. 搭建过程如下：
随便拷贝一个node服务器最小化模版
var express = require('express');
var path = require('path');
var favicon = require('serve-favicon');
var logger = require('morgan');
var cookieParser = require('cookie-parser');
var bodyParser = require('body-parser');
var index = require('./routes/index');
var users = require('./routes/users');
var app = express();
app.set('views', path.join(__dirname, 'views'));
app.set('view engine', 'jade');
app.use(logger('dev'));
app.use(bodyParser.json());
app.use(bodyParser.urlencoded({ extended: false }));
app.use(cookieParser());
app.use(express.static(path.join(__dirname, 'public')));
app.use('/', index);
app.use('/users', users);
app.use(function(req, res, next) {
var err = new Error('Not Found');
err.status = 404;
next(err);
app.use(function(err, req, res, next) {
res.locals.message = err.
res.locals.error = req.app.get('env') === 'development' ? err : {};
res.status(err.status || 500);
res.render('error');
module.exports =
以上代码主要设计express的相关知识，大家可看。
最关键的部分：app.use('/', index);app.use('/users', users);这里就定义了，当访问的路径为hostname+/的时候交给index处理，当然访问hostname+/users的时候交给users处理。这里的我们只关注后一个路径。交给users处理也就是交给users.js处理。
我们看下users.js内容：
var express = require('express');
var router = express.Router();
router.get('/', function(req, res, next) {
res.send('respond with a resource');
module.exports =
解释：引入express的路由模块，并设置当请求的子域名是/的时候就response一个文本。这里的/和app.use(‘/users’, users);一起构成了一个完整的请求。例如，如果这里写/a,则这个请求为/users/a的时候才会触发这个路由规则。
6. 之前只是定义了路由规则，接下来引用这个app规则并启动，代码如下：
#!/usr/bin/env node
var app = require('../app');
var debug = require('debug')('react-demos:server');
var http = require('http');
var port = normalizePort(process.env.PORT || '3000');
app.set('port', port);
var server = http.createServer(app);
server.listen(port);
server.on('error', onError);
server.on('listening', onListening);
function normalizePort(val) {
var port = parseInt(val, 10);
if (isNaN(port)) {
if (port &= 0) {
return false;
function onError(error) {
if (error.syscall !== 'listen') {
var bind = typeof port === 'string'
? 'Pipe ' + port
: 'Port ' +
switch (error.code) {
case 'EACCES':
console.error(bind + ' requires elevated privileges');
process.exit(1);
case 'EADDRINUSE':
console.error(bind + ' is already in use');
process.exit(1);
function onListening() {
var addr = server.address();
var bind = typeof addr === 'string'
? 'pipe ' + addr
: 'port ' + addr.
debug('Listening on ' + bind);
这里引入了app，并且设置监听在3000端口，也就是我们需要提供数据的端口。
7. 接下来启动node，将上面的代码放到start.js中然后输入node start.js启动node
8. 然后，写一个html并引入刚刚的js文件，我们使用webpack打包。html文件内容如下：
&!DOCTYPE html&
lang="zh-cn"&
charset="UTF-8"&
id="example"&&
src="./bundle.js"&&
这里引用的是bundle.js这是打包后的js文件，可以自定义。
9. 我们看打包的配置文件，配置如下：
module.exports = {
entry: ['./index.js'],
filename: 'bundle.js',
path: './'
解释：将绝对路径下的index.js打包成当前路径下的bundle.js然后html就可以引用了。
10. 打包命令(最好使用本项目内的webpack来打包并指定配置文件)
../../node_modules/.bin/webpack --config webpack.config.js
访问，点击webstorm上的浏览器按钮，直接访问。此时会报错，已拦截跨源请求：同源策略禁止读取位于
的远程资源。（原因：CORS 头缺少 ‘Access-Control-Allow-Origin’）。这是因为，访问的网址和fetch请求资源的网址跨域了，跨域可见
解决跨域，node服务器端配置下允许访问的字段。代码如下：
app.all('*', function(req, res, next) {
res.header("Access-Control-Allow-Origin", "http://localhost:63343");
res.header("Access-Control-Allow-Headers", "X-Requested-With");
res.header("Access-Control-Allow-Credentials", "true");
res.header("Access-Control-Allow-Methods","PUT,POST,GET,DELETE,OPTIONS");
res.header("X-Powered-By",' 3.2.1');
res.header("Content-Type", "application/charset=utf-8");
原理：我们看下/users访问的请求头
可见origin字段（用来说明，本次请求来自哪个源（协议 + 域名 + 端口），来源于localhost:63343也就是webstorm自带的web服务器的端口。Host表示发起当前请求的域名 + 端口。可见这两个不一致，所以跨域产生。我们要做的就是，告诉服务器，这个域名是可以被接收的，也就是允许localhost:63343跨域请求，所以才会有以上的配置。
接着看下响应头
可以看到，node服务器返回了我们刚刚配置的响应Access-Control-Allow-Origin，浏览器接收到这个响应，就会正常处理，否则进入error处理。
最后正常的结果就是，控制台打印了如下内容：
Response { type: "cors", url: "http://localhost:3000/users", redirected: false, status: 200, ok: true, statusText: "OK", headers: Headers, bodyUsed: false }
bundle.js:7855:10
respond with a resource
以上就是，整个从安装fetch到使用fetch到使用node搭建服务器到解决fetch跨域问题的流程，下一篇，我们继续研究，敬请期待。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：1464次
排名：千里之外
原创：17篇
评论：34条
(2)(18)(4)(1)(1)}