云间连下榻，
天上接行杯。

瀑布流算是比较常见的布局了，一个般常见纵向瀑布流的交互，当我们滚动到底的时候加载下一页的数据追加到上去。因为一次加载的数据量不是很多，页面操作是也不会有太大的性能消耗。但是如果当你一直往下滚动加载，加载几十页的时候，就会开始感觉不那么流畅的，这是因为虽然每次操作的很少，但是页面的 DOM 越来越多，内存占用也会增大，而且发生重排重绘时候浏览器计算量耗时也会增大，就导致了慢慢不能那么流畅了。这个时候可以选择结合虚拟列表方式使用，虚拟列表本身就是用来解决超长列表时的处理方案。

数组转树形结构这种情况还是很常见的，有时候后端就只给你一个数组，需要前端自己处理。一般情况下一个递归就搞定了，但是数据量很多的时候就有点 hot 不住了。

说到 prototype、__proto__ 首先就得去理解 JavaScript 语言的继承机制。在典型的面向对象的语言中，如C#，都存在类（class）的概念， 类就是对象的模板，对象就是类的实例。C# 中的 继承允许我们根据一个类来定义另一个类，这使得创建和维护应用程序变得更容易。同时也有利于重用代码和节省开发时间。在 JavaScript 是不存在 类 和 子类 概念的，全靠原型链的模式来实现继承 (后面出 class 在这基础上的语法糖)。

事件！事件到底是怎么工作的？JavaScrip t出现了多久，对 JavaScript 异步事件模型就迷惘了多久。迷惘导致 bug，bug 导致愤怒，然后尤达大师就会教我们如何如何……不过本质上，从概念上看，JavaScript事件模型既优雅又实用。一旦大家接受了这种语言的单线程设计，就会觉得 JavaScript 事件模型更像是一种功能，而不是一种局限。它意味着我们的代码是不可中断的，也意味着调度的事件会整整齐齐排好队，有条不紊地运行。本章将介绍JavaScript的异步机制，并破除一些常见的误解。我们会看到setTimeout 真正做了些什么。接着会讨论回调中抛出错误的处理。最后会奠定本书的主旨：为了清晰和可维护性，努力组织异步代码。