译文：http://2ality.com/2015/12/webpack-tree-shaking.html

作者: Dr. Axel Rauschmayer, Twitter, Mastodon

tree shaking, 顾名思义：摇树，把树上面的枯枝烂叶子甩下来，目的是减小bundle size。这个构建优化手段起源于另一个打包工具rollup.

工作原理

举例有es6模块如下：

1
2
3
4
5
6

export function foo() {
    return 'foo';
}
export function bar() {
    return 'bar';
}

首先，webpack将所有的es6 module打包到bundle文件里面。那些从来没有被import的export, 不再被export， 变成了dead code。 dead code就是在编译时不被export或者跟本用不到的函数、变量等等。比如代码中的bar.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

function(module, exports, __webpack_require__) {
	/* harmony export */ exports["foo"] = foo;
	
    /* unused harmony export bar */;
  function foo() {
    return 'foo';
  }
  // i am dead function .... 
  function bar() {
    return 'bar';
  }
}

需要注意的是， babel-preset-es2015默认会用transform-es2015-modules-commonjs把es6 module处理成commonjs。这就干掉了es6 module的静态特性。但是由于cmd模块系统是个对象，运行时才能确定模块的特定属性，那么在编译时就不能确定哪些exports是没用的了。模块将被转化成为如下cmd：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

function(module, exports) {
	'use strict';
	Object.defineProperty(exports, "__esModule", {
	    value: true
	});
	exports.foo = foo;
	exports.bar = bar;
	function foo() {
	    return 'foo';
	}
	function bar() {
	    return 'bar';
	}
}

目前babel有个简单的配置可以跳过模块的处理, 保留es6 module：

1

module: false;

然后，利用ulglify工具干掉dead code, 进行混淆:

1
2
3
4
5
6

function (t, n, r) {
    function e() {
        return "foo"
    }
    n.foo = e
}

最后对bundle进行压缩操作, 有效减小了bundle文件体积。

下面一段是瞎写写的：

有些人觉得自己不会写出这些dead code、垃圾代码，因而怀疑tree shaking的意义。其实现在很多库是设计成可以按需加载的，如echarts, rxjs, ramda，目的就是为了不引入所有的代码， 减小bundle体积。比如工具类的ramda有各种list, object, logic的各种方法， 你可能只用到了一个，是不需要将所有的方法都打包到bundle里面的。echarts可能只用到柱状图，也不需要把其他所有种类的图形打包起来， 这个太大了。就算现在网速快，流量也是要钱的。。。

1.preset-*

官方preset

举例：preset-es2015将ES6编译成ES5，preset-2017处理2017中的语法特性.

babel-preset-env

支持所有es标准的特性，能够根据配置采用特定语法处理插件。比方说配置成支持chrome 56, 很多es6已经支持了，就不需要在转成一大坨es5了，减小了bundle的体积。原理比较粗暴，他参考compat-table 把每个浏览器版本支持哪些特性都写在本地的文件里了。

preset-latest

顾名思义，最新的，包括所有的官方preset-*, 但是已经deprecated, 因为env的存在。

stage-X

相对于preset-*, 此插件支持尚未被发布为es标准的实验性质的语法特性，意思就是后面可能会被干掉的。比如说object-rest-spread.
这个比较蛋疼，只能说是特定时间，处于某个状态（0，1，2，3，4）的一系列特性的集合。 babel正在考虑废除，因为直接配置插件更加直观。

babel处于构建时，只处理语法，不处理api.

2. babel-core(标准库)

顾名思义，核心！核心！核心！各种es5,6,7各种polyfill。
例如对Arry.from进行Polyfill:

1
2

var core = require('core-js/library');
core.Array.from(new core.Set([1, 2, 3, 2, 1]));

3. babel-runtime

由core-js 与 regenerator-runtime构成。
使用方法：const Promise = require(‘babel-runtime/core-js/promise’), 比较原始。
供编译模块复用工具函数, 主要目的是减小包体积。对比babel-polyfill, 后者是会污染全局的，使用也很粗暴：

1

import 'babel-polyfill';

4. babel-plugin-transform-runtime, babel-polyfill

transform-runtime对于JavaScript新增的API和一些全局对象上的方法，在运行时动态插入兼容补丁，避免在每个文件插入重复的补丁。调试的时候可以看一下每个文件头部被插入了一段的代码。
配置简单(.babelrc)，比babel-runtime更加智能，实际上是站在babel-runtime的肩膀上，而babel-runtime是站在了babel-core的肩膀上。
容易和babel-polyfill搞混。参考知乎上的一篇文章。
主要区别在于babel-polyfill侵入性太强，会修改builtins 和 prototype, 类似于很早的prototype.js, 因此绝对不能用来搞轮子，容易破坏别人的轮子。babel-plugin-transform-runtime采用sandbox，不修改全局变量, 而且不修改prototype， 适合开发第三方库。

5. babel-register,babel-node

其他参考阮老师文章 http://www.ruanyifeng.com/blog/2016/01/babel.html

关于构建优化

对于后台系统开发，大部分情况下可以考虑现在浏览器. 由于目前现在浏览器对es6的适配已经非常高了，chrome60达到90%, 那么就没有必要将es6一股脑都编译成es5了。 我们只需要配置preset-env和一些transform插件就可以愉快地跑起来了。
对ts可以做同样的优化：先将ts编译的target设置为es6, 再送到babel按浏览器环境进行polyfill， 最终在浏览器里调试的代码要好看的多。我觉得最好的一点就可以保留class， 而不是其他的方式去实现它。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

{
  "presets": [
    ["env", {
      "modules": false,
      "debug": true,
      "targets": {
        "chrome": 56
      }
    }]
  ],
  "plugins": [
    "transform-runtime",
    "transform-object-rest-spread"
  ],
}

最近涉及到一些即时通讯的知识，大概记录一下

通讯协议及方式

1. TCP/IP （普遍采用该方式）
2. UDP
3. 如果是web通讯，那么包含以下方式：短轮询、Comet、Websocket、SSE。由于浏览器只是一个客户端，那么通讯是依赖于服务器的，这是跟移动应用或者桌面应用一个区别的地方。

通讯方式

1. 对等通讯方式（Peer To Peer） ，不经过IM服务器
2. 通过IM服务器中转（代理通讯）
3. 离线通讯（离线消息，通过服务器缓存）

步骤：

1. 登陆，Im服务器进行验证，更新登陆状态
2. 读取IM服务器好友列表，获取Ip，端口等信息
3. 直接根据好友信息进行对等通讯，或者通过服务器进行中转通讯