尤大大讲编译时优化

make code smaller

压缩器其实本身也是一个编译器。目前市面的压缩器： uglifyJs、 closure Compiler、babili（基于babel的）过程： source code - > parser -> AST -> Tagert Code

main.js

import {  foo } from './foo.js'
import {  bar } from './bar.js'

foo(bar)

foo.js

export function foo() {

}

bar.js

export const bar = 123

module scopre hoistion

// foo.js
function() {
   //...
}

// bar.js
const bar = 123

// main.js
foo(bar)

聪明的压缩器会将不需要的一些函数去掉。

vue 的模版中编译时优化

<div>
    <p class="foo">
         {{ msg }}
    </p>
</div>

编译后：

 return h('div', [
    h(
       'p',
       {  staticClass: 'foo'},
       [....]
    )
])

对于变化的模版

<ul>
    <li v-for="i in 10>
         {{ i }}
    </li>
</ul>

编译后：

return h('ul', [
   renderList(10, i => {
        return h('li', i)
   })
])

不得不说virtual Dom 是有好处实在太多，对于手写render function ,对于自定义组件啊，但是其性能肯定是比不上直接的字符串拼接，因为它首先创建那么多对象后，再进行stringfy(). 所以ract ssr，它深深的受制于这种over head ，性能方面受到了很大的限制。首先 vue底层是用了virtual Dom 的，找到所有可以不变的部分写成字符串，但是对于自定义组建使用render function。

在编译的时，首先要加载main.js , 在渲染main.js 后发现需要a.js ，此时再去加载a.js这期间是有等待的，所以vue在进行首屏加载的时候，会有一个 manifist 纪录首屏都需要什么。一次性取得。

基于virtual Dom 进行服务端渲染时，肯定比不上模版语言的，直接字符串拼接的。因为它首先创建那么多对象后，再进行stringfy(). react 服务端渲染受制于这个原因。有一些小众的marko.js他们也做了服务端渲染，并且性能非常好，因为他们限制了只能使用模版语言。

css 是在该组建被构建的时候，当他的生命周期的钩子被触发时，加载对应钩子所需要的css.

oliver1204 / randomNotes