1. 背景介绍

前端开发的变化

随着 Node.js 的兴起，越来越多的人使用 JavaScript 开发后台的一些应用。同时促进了模块化开发和包管理生态系统的发展。所以目前在国外，越来越多的人使用 CommonJS 规范来处理模块加载。但是为了能让代码在浏览器上能正常运行，我们需要在上线前，将相互依赖的模块整合打包到一个文件，这样就可以避免 CommonJS 同步加载的缺陷。

Browserify 的热捧

最初在寻找打包工具时，发现大家都选择了 Browserify 这款打包工具。所以一开始我也毫不犹豫地选择了它。后来在使用过程中发现，Browserify 只能将所有文件打包成一个文件，如果需要分开打包，需要手动配置。那这样的打包方式，只适用如下一些场景：

• 小规模网站，即代码量小
• 很少更新网站，意味着业务代码很少更新
• 不太关心第一次页面加载时长

这显然不太适应大部分网站的使用场景。

2. 从 Browserify 叛逃到 Webpack

前提说明：本篇是在学习Backbone的时候，实战练习写了一个 TodoMVC，并在原有代码上基础做了部分改进工作。

主要的改进

• 引入模块开发并使用CommonJS规范
• 使用Webpack工具加载和打包模块
• 将 HTML 模板独立成单一模块文件，同时让模块 JS 文件加载对应的 HTML 模板文件
• 细化了View层的颗粒度，将 View 拆解成：AppView、FooterView、TodoView、TodoListView
• 优化了 View 中render方法监听的事件类型，防止当Model或Collection发生一次变化时，View 多次重复渲染。「原例子中简单监听了all事件」
  阅读全文 »

前提说明：
本文通过对比一些主流 JavaScript Style Guide, 摘录了一些值得借鉴的语法书写方式，以提高程序执行性能。而格式问题「Formatting: space, newline, etc」暂且被忽略了，因为一般可以通过 IDE 编辑器设置处理，写的时候可以按照自己的习惯来，通过编辑器格式配置方式以保持和团队风格统一，常见格式建议可查看参考资料。

在正式开始介绍前，我们先提出这样一个疑问：

当两个元素位置互相堆叠在一起时，CSS 样式是如何决定哪个元素显示在前，哪个元素显示在后的呢？

为了解决这个问题，在左右、上下的布局基础上，CSS 2.1 引入了第三维度Z 轴的概念。CSS 将所有元素都被纳入一个Stacking Context中，根据某种规则控制元素堆叠的优先顺序，下面主要详细介绍一下这种规则。

Stacking Context 介绍

CSS 2.1 Spec 对Stacking Context的描述：

The order in which the rendering tree is painted onto the canvas is described in terms of stacking contexts.

我对这句话的理解是：Stacking Context有着一套规范元素堆叠顺序的规则。在渲染页面时，根据这套顺序规则依次在 Z 轴上显示不同元素。

Stacking Context 的特性

• 每个文档布局中存在多个 Stacking Context。而产生一个新的 Stacking Context 是有条件的「详见下文」
• 在每个Stacking Context中可以嵌套其它的Stacking Context
• 每个Stacking Context中的元素位置和同级的Stacking Context中元素位置的顺序是互相独立的
• 每个Stacking Context是自包含的，即当父元素形成一个Stacking Context「此时作为后代元素的Parent Stacking Context」，所有内部后代元素的堆叠顺序都仅限在Parent Stacking Context比较
  阅读全文 »