一般新开发一个项目时，我们会首先搭建好一个脚手架，然后才会开始写代码。搭建脚手架可以用 create-react-app、vue-cli、yeoman 等命令行工具，也可以直接用 html5-boilerplate、react-boilerplate、hackathon-starter 等模板，如果这些都不能满足你的个性化需求，可以尝试搭建自己的前端脚手架。

web 的三要素 html, css, js 在前端组件化的过程中，比如 react、vue 等组件化框架的运用，使 html 的弱化与 js 的强化 成为了一种趋势，而在这个过程中，其实还有另一种趋势也在慢慢形成：css 的弱化与 js 的强化。

相对 java、.net 之类的强类型语言，js 有一点很大的区别就是，数据结构只有 array 与 object，并且都是动态可变的，而 java 有 List, Set, Map 等数据结构。所以，为了能在 js 中也使用这些数据结构，immutable-js 就应运而生。

现在前端打包基本上都会用 webpack，但经常使用 webpack 的开发者基本都有一个体会：配置比较复杂，尤其是有很多项目的时候，更新需要到处改配置。

js 性能优化利器：prepack 1. js 性能优化 js 性能优化不外乎从三个角度入手： 1.1 开发者在编写程序时，尽量避免不必要的冗余代码，包括冗余的第三方库 首先要避免不必要的冗余代码，包括不必要的闭包、不必要的变量与函数声明、不必要的模块分割等。 比如： {代码...} 其次是要避免使用不必要的第三方库，因为一般第三...

由于众所周知的原因，npm 官方仓库在国内特别的慢，所以我们需要用一些替代性方案，一种方案就是切换 npm registry 到国内的镜像仓库。

yarn: 类似 npm 的依赖管理工具，但 yarn 缓存了每个下载过的包，所以再次使用时无需重复下载，同时利用并行下载以最大化资源利用率，因此安装速度更快。

对于前端开发来说，组件化技术已经是一门必修课了，这其中又主要以 react 和 vue 为主。但平时在开发组件，尤其是公共组件或者第三方组件库的时候，往往会有一些困扰：

bootstrap: 由 twitter 出品的 UI 框架。经过多年的发展，社区构建出了一个强大的生态，以及各种各样的插件，基本上你所需要的都能找到。框架主要以 css 为主，js 为辅，js 组件部分依赖 jquery。也有针对 react 的适配 react-bootstrap 和 vue 的适配 bootstrap-vue。

facebook 在 2013 年开源了 react 后，紧接着在 2015 年就又开源了 react-native，就此打开了用 js 和前端技术写原生 android&ios APP 之路。尽管到目前为止 react-native 最新版本是 0.56.0，还没有发布正式 1.0 版，但使用 react-native 开发原生 APP 的技术已经比较成熟了，很多商业公司和商业软件都在用 react-n...

js 中一些意想不到的使用技巧（持续更新，欢迎补充） 1. 箭头函数 => 返回 map 对象 {代码...} 2. 对象属性名不确定，需要动态的传入 {代码...} 3. 复制一个对象，并重写其中的一些属性 {代码...} 4. 数组解构为函数参数 {代码...} 5. 向一个数组添加另一数组的所有元素 {代码...} 6. 回调函数简写 {代码...} 7. 多级...

webpack 对前端来说是再熟悉不过的工具了，它提供了强大的功能来构建前端的资源，包括 html/js/ts/css/less/scss ... 等语言脚本，也包括 images/fonts ... 等二进制文件。

js 语言与 java、C 系列等语言有一点很大的不同，就是 js 语言是弱类型语言。js 语言的这个特性可能让大家觉得 js 很自由，没有强制性的约束，但是当遇到大型项目的时候，js 的这个特性就会变得比较麻烦，因为这会导致团队的代码很不可控。这个原因也是促使 TypeScript 诞生的一个很重要的原因。

目前用 js 和前端技术写桌面软件的方案主要有两种：electron 和 nw.js。这两者在底层实现上有所不同，简单的说，electron 是 node + chromium，nw.js 是 node + webkit。从使用上来说，electron 的使用更为广泛，社区也更活跃，有一大批成熟的商用软件，像 vscode, atom等。所以，现在一般推荐使用 electron 来写桌面软件。

现在前端的项目基本上都会用 webpack 打包代码，并且文件名（html 文件除外）都是 hash 化的，这样可以去除浏览器的缓存。但是会产生另外一个问题，就是服务器上会堆积大量过期（不会被用到）的 hash 文件，这些文件又主要是 js 和 css 文件，因为基本上每构建一次都会产生新的 js 和 css 文件。如果这些文件不清除的话...

尽管写了多年的代码，但是始终有一件事不敢确定，就是自己的代码究竟写得好不好？这个问题很难有确切的答案，因为这个跟风格、规范有很大关系，而风格、规范很难说好还是不好。

现在前端项目越来越变得像大型工程了，而且越来越复杂了，需要处理好组员之间的协作，也需要做好业务分块、去耦合来降低维护成本，并且还要保持高效率开发。

CSS(Cascading Style Sheets)，从诞生之初就决定了它无法编程，甚至连解释性语言都算不上，只能作为一种简单的层叠样式表，对 HTML 元素进行格式化。

在前后端分离之后，后端语言的模板功能被弱化，整个页面的渲染基本上都由前端 js 动态渲染，但这样对于一些应用来说是有缺陷的。比如需要 SEO 的，需要打开页面不用等待就能看到页面的，这尤其对于电商类应用是必需的。

单页面应用（SPA）、按需加载 1. 多页面应用 传统多页面是由后端控制一个 url 对应一个 html 文件，页面之间的跳转需要根据后端给出的 url 跳转到新的 html 上。比如： {代码...} 多数情况下，这种方式都是没问题的，但对一些业务逻辑相似，重前端的应用就不是很友好了，比如系统管理应用。 页面之间的跳转需要重新加载...

私有 npm 仓库 1. “私有 npm 仓库” 有何用 组件化之后，搭建 “私有 npm 仓库” 是个不错选择。 私有 npm 仓库可以让我们使用组件就像 npm 官方仓库里的包一样方便。 一般私有 npm 仓库有以下一些特性： 私有包托管在内部服务器或者单独的服务器上； 可以同步整个官方仓库，也可以只同步需要的； 下载的时候，可以让公共包...

组件化就是将项目中可以共用的代码提取出来，单独成一个组件，以便在多个地方调用此组件，这样便可以做到只维护一份代码，而不需要每次更新都要改多个地方，而且还不能保证都一样。

现在对于构建工具的使用已经非常广泛了，从 grunt 到 gulp，再到 webpack，一个个更加强大工具在不断出现，前端的技术更新节奏之快真的有点让人应接不暇呢（^_-）。但这些构建工具也只是提供了一些基础子集，对于团队来说，还需要把这些子集进行组合，打造适合团队开发的构建工具。

JSDoc 是一个根据 javascript 文件中注释信息，生成 JavaScript 应用程序或库、模块的 API 文档 的工具。你可以使用他记录如：命名空间，类，方法，方法参数等，并且很多编辑器和 IDE 都是直接支持智能提示的。

前端开发规范 1. 为什么需要 “前端开发规范” 规范不是强制性的，对代码的编写和程序的运行不会有致命的问题，但是没有规范会有一系列的问题，比如： 缺乏规范，第一个问题就是团队编码风格不一，增加了成员之间代码的阅读成本，加大了团队协作成本和维护成本； 随着团队人员的变化（多人开发一个应用，或者应用更换开发...

在前后端分离之前，前后端的数据交流以及页面渲染使用后端的模板（如 java > jsp、php > smarty）是很常见的，所以前端对页面的开发与调试总是依赖后端程序，而不能本地运行，这就导致前端开发很耗时，并且毫无意义。前后端分离之后，前端能够在本地运行服务程序、开发、调试，这让前端开发人员从与后端耦合开发的...

html/css/js 从设计之初开始，都只为浏览器服务，并且在整个web程序中，是以后端为主，前端为辅，前端需要配合不同的后端做出调整（如不同后端语言的模板），因此前端程序往往是与后端程序耦合在一起的；