早期桌面应用的开发主要借助原生 C/C++ API 进行，由于需要反复经历编译过程，且无法分离界面 UI 与业务代码，开发调试极为不便。后期出现的 QT 和 WPF 在一定程度上解决了界面代码分离和跨平台的问题，却依然无法避免较长时间的编译过程。近几年伴随互联网行业的迅猛发展，尤其是 NodeJS、Chromium 这类基于 W3C 标准开源应用的不断涌现，原生代码与 Web 浏览器开发逐步走向融合，Electron 正是在这种背景下诞生的。

Electron 是由 Github 开发，通过将Chromium和NodeJS整合为一个运行时环境，实现使用 HTML、CSS、JavaScript 构建跨平台的桌面应用程序的目的。Electron 源于 2013 年 Github 社区提供的开源编辑器 Atom，后于 2014 年在社区开源，并在 2016 年的 5 月和 8 月，通过了 Mac App Store 和 Windows Store 的上架许可，VSCode、Skype 等著名开源或商业应用程序，都是基于 Electron 打造。为了方便编写测试用例，笔者在 Github 搭建了一个简单的 Electron 种子项目Octopus，读者可以基于此来运行本文涉及的示例代码。

全文翻译自React 16.6.0 英文文档，适当精简了生产环境不经常使用的内容，并对部分较为复杂的概念进行了更加翔实的解读，以及与 Vue2 进行了一些特性方面的比较。本文首先会介绍React 16带来的一系列变化与新特性，然后解读 React 官方文档Docs当中Quick Start和Advanced Guides的内容，最后基于项目上的使用实践，开源了一个较为完整的脚手架项目Rhino，适合已经具备组件式前端框架开发经验的同学快速上手。

2017 年 9 月 Facebook 释出React v16.0.x，宣布使用对商业使用更加友好的 MIT license 开源许可，并带来了全新的render()函数返回类型、更加健壮的错误处理机制、全新的Fragment和Portal 特性，并完全重写了类库的核心架构，带来更为优异服务器端渲染性能的同时，有效缩小了类库代码本身的体积，更重要的意义在于杜绝了 Preact 等衍生框架对 React 社区所造成的分裂。

Vue 是一款高度封装的、开箱即用的、一栈式的前端框架，既可以结合 webpack 进行编译式前端开发，也适用基于 gulp、grunt 等自动化工具直接挂载至全局window使用。本文成文于 Vue2.4.x 版本发布之初，笔者生产环境当前使用的最新版本为 2.6.12。在经历多个前端重度交互项目的开发实践之后，笔者结合官方文档对 Vue 技术栈进行了全面的梳理、归纳和注解，因此本文可以作为 Vue2 官方《Get Started》 的补充性读物。

Vue 2 框架体系及技术栈日趋完善，相较于React+Reflux/Redux/MobX技术栈，Vue 更加贴近 W3C 技术规范（例如实现仍处于 W3C 草案阶段的<template>、<slot>、is等新特性，提供了良好易用的模板书写环境），并且开源生态更加完整且易于配置，将 React 手动编码才能处理的细节，整合成为最佳实践并抽象为语法糖（比如 Vuex 中提供的store的模块化特性），使得开发人员得以将注意力聚焦于业务逻辑本身。

Flux是由 Facebook 在 2014 年 7 月提出的一种 React 应用体系架构，主要用于解决多层级组件之间数据传递以及状态管理的问题。并由此派生出了Reflux、Redux、MobX等一系列单向数据流框架。为 Web 前端页面实现组件化拆分之后，组件间的通信与协同机制提供了一套较为完善的方法学。其核心理念在于将所有应用状态放置在Store内进行统一管理，视图层组件只能通过触发Action修改Store中的应用状态。

本文首先系统的概括 Facebook 官方的Flux以及单向数据流思想，然后遵循近几年Flux 衍生框架的发展历程，逐步进行概括性的分析与比较，并顺带介绍了 Vue 技术栈当中的类 Flux 框架 VueX，最后，由于通常将Action视为 Flux 工作流的核心与起点，本文还对《Flux Standard Action》自述文档进行了翻译，以期更为全面的展现 Flux 生态的演进过程。

Webpack 是现代 Web 应用程序的静态模块打包工具，它会递归的构建应用程序各个模块的依赖关系图，然后将所有模块打包成一个或多个bundle。目前 Webpack 已经更新至 4.29.6 版本，增加了诸多打包和执行性能相关的支持，是目前应用最广泛、社区最活跃的 Web 前端代码打包方案。而更新版本的 Webpack 5 已经进入 Beta 发布阶段，未来将会带来更多构建性能的提升，本文依然以更为稳定的 Webpack 4 为讲解对象。

Webpack 提出了入口entry、输出output、加载器loader、插件plugin这四个核心概念，本文将会在简单介绍 Webpack 相关基础概念之后，对其原生实现的import模块导入机制进行分析，以清晰的展现 Wepback 在底层所进行的工作；最后逐步备注笔者在开发、生产环境下使用到的各类插件和加载器，并分享在aves和rhino两个开源脚手架项目当中（分别基于 Vue2 和 React16）所使用到的最佳配置实践。

HTTP 是基于 TCP/IP 协议而建立 Web 基础协议，从 1989 年早期的简单 HTTP/0.9 单行协议开始，至 1996 年逐步扩展了状态码、协议头等特性发展到 HTTP/1.0，然后在 1997 年的 HTTP/1.1 增加了 TCP 连接复用、流水线支持、响应分块、缓存控制、内容协商等特性。2015 年 HTTP/2 协议正式标准化之后，传统 HTTP 的文本协议被二进制协议替代，让并行的请求在同 1 个 TCP 连接中处理，并移除了header中的重复数据，大幅提升通信效率。

在各类现代化 Web 服务器与开发框架群雄并起的年代，无论是 Python 的Django、Tornado，还是 Java 的Servlet或者是 Go 上的BeeGo，其本质上都是基于HTTP 协议的封装。因此了解 HTTP 相关协议规范能够提升 Web 开发的透明度，能够从协议角度理解 Web 报文的通信过程，而非仅仅从各类 Web 开发框架及其 API 封装的角度。

开发团队当前正在全面切换到ES6 + Vue/React + Webpack这套技术栈，小伙伴们在开发过程中对编码规范以及 ES6 使用约定方面存在诸多困惑，所以参考了 Github 以及互联网企业 UED 的相关技术文档，结合团队之前积累的大量开发约定和范式，整理了这篇 code style 并且开源出来，计划在 Team 小伙伴们熟练掌握以后，逐步在项目中推广使用 ESLint 校验代码风格。

本文撰写过程中参考了爱彼迎的 《Airbnb JavaScript Style Guide》，以及网易 NEC 团队的《CSS 基础库命名约定》等开源规范，结合笔者之前撰写的 《HTML5 语义化标签概览》一文，总体上分为总体原则、JavaScript/ES6、CSS/SCSS、HTML四个部分，分门别类的从命名约定、选择器使用、DOM 结构组织等纬度进行阐述，以帮助小组成员形成良好的编码习惯。

NodeJS 开源项目于 2009 年由 Google Brain 团队的软件工程师 Ryan Dahl 发起创建，后被美国云计算企业 Joyent 招入麾下，2015 年后正式被 NodeJS 基金会 接管，三星公司于 2016 年完成了对 Joyent 的收购。经过将近 10 年的发展，NodeJS 已经成为现代化前端开发过程中不可或缺的基础架构，即可以作为页面渲染的分布式服务器，也可以作为前端自动化的宿主环境。

本文基于笔者在 2015 年所写的一篇读书笔记整理，彼时 node.js 的版本号还停留在v0.12.x，社区也还未完成与 io.js 的最终合并，文中出现的部分 API 时至今日已经被废弃或者迁移。但是这些 API 层面的变化都可以对照 《官方文档》找到相应说明以及替代 API，总体上并不会影响通过本文快速了解 NodeJS 的全套技术栈特性。

Sass 是成熟、稳定、强大的CSS 预处理器，截止到目前为止已经发展有 10 年，前当最新 release 版本为3.5.5。而SCSS是Sass3版本当中引入的新语法特性，完全兼容 CSS3 的同时继承了Sass强大的动态功能。本文翻译自《Sass Guide》和《Sass Syntactically Awesome StyleSheets》两篇官方文档，讲解了现代化前端开发当中经常使用的 SCSS 语法特性，便于开发小组的同学快速上手。

基于 Gulp 完成前端自动化的年代，出于快速上手以及 npm 安装方便的考虑，开发团队一直沿用Less和gulp-less作为 CSS 预处理工具，但是 Sass 提供了更加丰富的动态语法特征，因此逐步淘汰基于 Gulp 的beaver前端项目脚手架以后，新项目全部基于 Webpack 的node-sass和sass-loader作为预处理工具。Sass 和 Less 的详细比较可以参考sass-vs-less和Sass 与 Less 比拼两篇文章，里面对两者的优劣做了非常详实的比较。

伴随着 W3C 协议规范的不断更新，以及现代化浏览器技术的快速进步，Web 前端技术整体取得了日新月异发展，交互体验更加丰富与多样化，与此同时业务逻辑也在极速的膨胀。开发人员函需从大量 DOM 底层处理的劳动中解放出来，更加从容的面对纷繁复杂的各式交互需求。本文开头先简单的梳理一下历史，然后基于现代化前端框架的主要特性，逐一与 Backbone 进行比较和剖析。

从前端技术发展趋势的角度而言，目前层出不穷的现代化前端框架的诞生，都可以认为是 Angular 和 Backbone 等古典前端框架设计思想走向融合之后的产物。虽然截至到本文执笔的时间点，Backbone 已经略微old school，但之所以依然单独对 Backbone 着重笔墨，主要是在组件化和作用域控制等方面，Backbone 更加接近于现代化前端框架的设计理念，而这两点又正好是同一时期的 Angular 并没有解决好的问题。