在上一篇关于作用域的文章中我们通过调用栈讲什么是作用域。
每当我们调用一个函数时就会在调用栈中为该函数创建执行上下文，到目前为止我们知道了该执行上下文中有变量环境，用于存储通过var声明的变量，也有一个词法环境，词法环境又是一个栈，依次放置了函数中通过let和const声明的在不同层级的块级作用域中的变量。
基于上面的变量环境和词法环境，我们可以明白如何在一个函数的执行上下文中找到正确的变量。
那如果我们所需要的变量其实不在当前执行上下文，而是在上一级的执行上下文中呢？我们怎么确定上一级的执行上下文是哪个？
这个问题就涉及了我们今天的主题：作用域链。
理解作用域链是理解闭包的基础，而闭包在 JavaScript 中几乎无处不在，同时作用域和作用域链还是所有编程语言的基础。所以，如果你想学透一门语言，作用域和作用域链一定是绕不开的。
无论你是想要设计高性能 Web 应用，还是要优化现有的 Web 应用，你都需要了解浏览器中的网络流程、页面渲染过程，JavaScript 执行流程，以及 Web 安全理论。
这篇文章简单介绍下浏览器的架构演进。
最近看了几篇关于浏览器原理的文章，对浏览器的渲染流程有了个比较系统的了解，在这里简单总结下并顺便讲下老生常谈的重排和重绘是怎么回事。
只有理解了 JavaScrip 的执行上下文，你才能更好地理解 JavaScript 语言本身，比如变量提升、作用域和闭包等。不仅如此，理解执行上下文和调用栈的概念还能助你成为一名更合格的前端开发者。这次我们就从上下文的角度讲一下js的变量提升。
上周的博客中我们讨论并实现了图的拓扑排序，这周我们继续学习图的另外一种基础的算法，最短路径算法Dijkstra算法，以及如何将其改造成我们平时导航或者游戏中经常使用中用到的寻路算法。
今天看了一篇关于拓扑排序的思路和应用的文章，自己手动实现记录一下。
算法是构建在具体的数据结构之上的。针对这个问题，我们先来看下，如何将问题背景抽象成具体的数据结构？
我们可以把源文件与源文件之间的依赖关系，抽象成一个有向图。每个源文件对应图中的一个顶点，源文件之间的依赖关系就是顶点之间的边。
如果 a 先于 b 执行，也就是说 b 依赖于 a，那么就在顶点 a 和顶点 b 之间，构建一条从 a 指向 b 的边。而且，这个图不仅要是有向图，还要是一个有向无环图，也就是不能存在像 a->b->c->a 这样的循环依赖关系。因为图中一旦出现环，拓扑排序就无法工作了。实际上，拓扑排序本身就是基于有向无环图的一个算法。
这周POC了几个渗透测试工具，分别是Burp Suite，OWASP Zap。
其中Burp的很多功能都是收费的，免费版基本只是用来做请求拦截的。
所以最后选择Zap对一个Express项目进行了扫描了漏洞修复，这里简单记录一下Zap的使用教程，以及Express的一些安全实践。
上周在使用一个elementUI的table是，发现每次点击table的checkbox的时候，页面都会卡顿接近两秒钟，于是就用vue的devtools去记录了下每次的操作时间消耗在哪里，发现主要是因为elementUI的table虽然提供了树形数据和懒加载的功能，虽然子级节点没有展开，但是已经渲染出来了。
所以elementUI的table提供了懒加载的功能，但是这个懒加载的功能是有问题的，因为懒加载函数只会调用一次，以后无论如何变化数据，子节点都不会发生改变。
经过对vue和elementUI的源码分析，找到原因后适当fix了一下，在这里记录一下。
前面的六篇博客已经帮助我们基本搞清楚了，vue的响应式原理，数据驱动，组件化和组件更新等概念和原理，而其中关于组件化和组件更新的部分，我们是在已有render函数的基础上来讲的，也就是说我们已经有了vnode，再去讨论的vnode如何渲染更新的。
这篇博客我们就回过头来看看vue的compiler是如何将template变成render函数的。
了解编译的流程有什么好处呢？我个人觉得可以帮助我们对于一些vue自身的语法糖的原理有个更好的理解。
由于Compiler的细节非常多，所以大概有个结论和印象即可，其中很多关于vue自身的语法处理也不会细讲，只会用slot来做个例子。