2016 年 JavaScript 技术栈展望

\o"2016年JavaScript技术栈展望-码农网"2016年JavaScript技术栈展望如果你正在筹划新的前端项目或者重构现有项目，那么你需要认识到现在的前端开发环境已经今非昔比，这其中有太多的选择了：React、\o"Flux"Flux、Angular、Aurelia、Mocha、Jasmine、Babel、TypeScript、Flow……它们的本意是将开发简单化，却无形中提高了学习成本，也给未来项目的维护带来了不确定性。好在这一现象正在退热，优胜劣汰，优秀的项目慢慢沉淀下来，开发方式也越来越清晰。有些开发者正在尝试使用基于上述技术的框架进行开发，也在一定程度上减少了学习成本。本文中主要介绍了一些我在web应用开发中所涉及和推崇的技术，其中有一些技术上存在争议，所以我对于每一技术都只做简单的介绍和分析。所有的这些观点都是基于我个人的经验和对社区的接触总结而来的，所以各位还请按需各取所用。ReactReact可谓风头正盛一时无两：组件化使应用程序更易于开发和维护学习曲线平缓，核心API简洁清晰，易于学习JSX语法不落俗套，充分发挥了JavaScript的能量天生适配Flux和Redux社区活跃且具有创造力，奉献了诸多优秀的开发工具单向数据流比双向数据绑定的方式更适合复杂应用程序，质量更高支持服务端渲染虽然比起Ember、Aurelia和Angular这些功能丰富的框架，React不是全能手，但React的开发环境更加健壮。就目前而言，使用React已经不是一个技术选择，而是一个商业行为，它能提供更高效和更有效的生产力。当你想开发移动应用时，因为已经学习了React语法，所以可以直接上手ReactNative开发跨平台应用。Redux现在，我们已经具有了开发视图层的能力，接下来，我们需要使用其他工具管理应用程序中的状态和生命周期，在这里推荐的工具就是：Redux。为了配合React，Facebook开发了管理单向数据流的工具Flux，虽然Flux基本上实现了对单项数据流的支持，但是同时也带了其他问题，比如如何保存状态、何处发起Ajax请求等等。为了解决这些问题，又衍生了一系列效仿Flux模式的框架：Fluxible、Reflux、Alt、Flummox、Lux、Nuclear、Fluxxor……目前来说被开发社区广泛支持的一个实现就是Redux。在Redux中，大多数的组件都是纯函数式的组件，也只有一个集中的存储和资源中心。Redux的实例方法负责整个数据的操作和维护。相比Flux来说，Redux的思路更加清晰。更重要的是，Redux非常易于学习。Redux的作者DanAbramov是一个优秀的教师，他制作了一系列深入浅出的Redux视频教程。通过观看这些视频，即可成为一个Redux方面的专家。我曾经见识到一个零基础的React团队在短短几周内迅速开发出了测试版产品，且代码非常稳健和老练。Redux周边的生态系统和Redux本身一样健壮。从神奇的

devtool

到强大的记忆化工具

reselect，Redux开发社区为开发者提供了应有尽有的工具。开发者可能会本能地去尝试抽象出一个Redux模板，这么做有诸多好处，但请在认清需求的基础上来封装模板，而不要盲目的去尝试。ES6和Babel是时候抛弃CoffeeScript了，这是因为它的诸多特性已在ES6中出现类似的语法，而ES6是实施标准，代表了JavaScript未来的发展方向。目前最新的浏览器已经支持了ES6的大部分特性。Babel是一个强大的转换工具，用于将ES6转换为ES5。此外，根据目标浏览器可以调整代码转换的程度。那么是否有类型系统呢？TypeScript和Flow都为JavaScript提供了静态类型系统，使用静态类型检查，可以有效捕获错误，减少测试量。目前来说，我建议对此持观望态度。TypeScript在尽力让JavaScript向C#或Java的方向发展，但缺少了许多高级的类型系统特性，比如代数数据类型（algebraicdatatypes）。此外，它不能像Flow一样有效地处理null。相比而言，Flow更加强大，捕获的错误类型也更多，但难于配置。此外，它对JavaScript新特性的支持弱于Babel，也不支持Windows系统。就我个人的角度而言，在前端开发中类型系统并不是至关重要的一环（此处可能有争议）。在类型系统更加健壮且对Babel更友好之前，还是让我们静观其变吧。ESLint另一个无可争议的工具是ESLint。ESLint支持ES6语法，还提供了React插件，已经不单单是一个\o"代码审查工具"代码审查工具了。目前来说，JSLint已经过时了，ESLint可以替代JSHint和JSCS独树一帜了。开发者可以根据自己的需求配置ESLint，不过在这里我建议根据

AirBNB的开发规范进行配置，也可以直接使用

ESLintairbnbconfig。当然这份规范中尚有不足之处，但保持团队整体代码的一致性，可以有效提高代码的可读性。当你熟悉了ESLint之后，建议开发者深入地尝试其中的规则。ESLint捕获的错误越多，产品的稳定性越高。NPM，CommonJS和ES6modules忘记Bower吧，用NPM接管一切。类似Browserify和Webpack的构建工具间接提高了NPM在web开发中的地位。使用NPM，版本管理将会更加简单，也将更多地与Node.js生态系统接触。目前对于CSS的处理尚不足够完善。你可能会考虑如何在部署服务器上执行构建呢？与Ruby的Bundler有所不同，NPM使用了通配符检索文件，且第三方包可以在代码开发中以及项目发布前做任意修改。使用

shrinkwrap

文件可以冻结项目中的第三方依赖，我建议使用User的shrinkwrap，提高输出的一致性。此外，开发者也可以考虑使用类似Sinopia

的工具托管自己的私有NPM服务器。Babel会将ES6module语法转换为CommonJS。CommonJS是一种历经实践的语法，这意味着稳定和通用，此外，使用类似

treeshaking

（Webpack2.0和Rollup已经支持该特性）的机制我们还能实现静态代码分析。Webpack除非你乐意在页面添加数百个脚本标签，否则的话你应该尝试用构建工具来打包页面的资源了。此外，你还需要某些工具让浏览器支持NPM第三方包。在这里，我推荐你使用Webpack。一年之前对于上述工作，开发者还有诸多工具可以选择，比如基于JavaScript的RequireJS、Browserify和Webpack解决方案，此外还有号称能对ES6的模块进行最佳优化的RollupJS.在尝试了所有的工具之后，我强烈建议开发者选择Webpack:通过配置可以应对各种情况支持主流的模块加载方式（AMD，CommonJS，globals）内部机制可以修复破损的模块可以处理CSS全面的缓存系统支持热重载可以加载大多数的资源提供高效的性能优化方案Webpack也非常善于处理大型的单页应用，支持代码分割和惰性加载。但是值得注意的是，Webpack的学习曲线异常陡峭。不过一旦你学会了它，那么你就掌握了最强大的构建系统。那么Gulp和Grunt呢？相比而言，Webpack更善于处理各类资源。如果你需要执行其他类型的构建任务，那么Gulp和Grunt还是有用的。对于类似运行Webpack的基本任务，我建议直接使用

NPM脚本。Mocha+Chai+Sinon在JavaScript中，有大量可选的单元测试工具，每一个都很稳定和健壮。如果你只是用于单元测试，那么现有工具完全可以胜任你的需求。常见的测试工具有Jasmine、Mocha、Tape、Ava、Jest等，它们各有所长。我对一个测试框架的要求有如下几条：可以在浏览器运行，便于调试执行速度快便于处理异步测试便于在命令行中使用可以兼容任意断言和数据模拟的第三方库第一条标准就排除了Ava和Jest。我喜欢Chai断言是因为其种类丰富、功能齐全的插件，喜欢Mocha是因为其对异步的良好支持。强烈建议使用

DirtyChai

避免某些问题。Webpack的

mocha-leader

插件允许开发者自动执行测试。对于React而言，开发者可以参考一下AirBNB的

Enzyme

和

Teaspoon。我非常钟爱Mocha的特性，如果你想要的只是最基础的功能，可以参考这篇文章了解一下Tape。LodashJavaScript并没有一个类似Java或.NET的核心工具库，所以开发者大都会从外部引用一个外部工具库。目前来说，Lodash是此类工具中的佼佼者。此外，由于它惰性执行的特性，也让它是目前性能最佳的工具之一。使用Lodash时无需引用全部资源，开发者可以按需使用其中的函数。在4.x版本中，Lodash为偏爱函数式编程的开发者提供了一个“函数式开发”模式。如果你熟悉函数式编程，你可以了解一下

Ramda。如果你决定使用这个库，可能需要引用一些Lodash函数。fetch许多基于React的应用程序都不再使用jQuery了。除非你正在维护一个陈旧的项目或者用到的第三方库依赖了jQuery，否则已经没有必要使用它了。我喜欢让项目保持简洁，在代码中只使用

fetch

。fetch基于promise，Firefox和Chrome都封装了该接口。对于其他浏览器，则需要提供一个腻子脚本。我建议使用

isomorphic-fetch

在各个浏览器和服务端保持功能的一致性。当然也可以其他优秀的第三方库异步获取数据，但我觉得fetch已经够用了。同构JavaScript同构JavaScript是指同时运行在客户端和服务端的JavaScript，常用于在服务端预先渲染页面，提高性能，便于SEO。使用React可以实现同构JavaScript，但是并不简单，它提高了程序的复杂度，限制了开发者可选的工具和第三方库。如果你正在构建一个B2C的站点，比如电商网站，那么你可能就需要使用同构JavaScript。不过，对于内部站点或者B2B程序，性能就不是最重要的了，则同构JavaScript也就不是太重要了。API最近每个人好像都在思考如何处理API。每个人都在随波逐流的使用

RESTfullAPI，SOAP

已经成为了过去时。目前业界存在各种API协议，比如HATEOAS、JSONAPI、HAL、GraphQL等。GraphQL赋予了客户端进行任意查询的能力。搭配

Relay，可以更好地处理客户端的状态和缓存。不过，创建GraphQL的服务端接口的难度还较大，且大多数的文档都是面向Node.js的。Netflix的

Falcor

看起来提供了和GraphQL/Relay相似的能力，同时还降低了服务端的需求，但它目前尚处于开发者预览状态，尚未应用于实际开发。所有已知的规范都各有缺陷，有些过于复杂，有些只能处理数据读取而不嗯那个更新，有些和REST差异显著。许多开发者选择自己开发，但是还会遇到上述的问题。我不认为上述有一个完美的解决方案，但我对API有一个自己的认知：可预测，遵循一致性协议支持在一次查询中获取多个实体支持更新操作易于调试易于使用到目前为止，我还没有发现满足上述所有条件的解决方案。如果你正在使用RESFful，建议参考

Swagger

来编写API。ElectronElectron

可以使用前端技术构建桌面程序，GitHub团队出品的Atom编辑器就是基于Electron创建的。本质上，Electron内部封装了一个Node.js，可以打开Chrome窗口渲染UI，还可以访问操作系统本地的API，并且没有浏览器中的沙盒机制。开发者可以通过Electron打包和分发应用程序。这是创建跨平台软件最简单的方式，而且还可以利用上述的所有工具。此外，Electron有完整的文档和活跃的开发社区。你可能听说过

nw.js

的大名，虽然它已经存在了多年，但相比来说，Electron更加稳定和易用。这里有一个基于

Electron、React和hotreload的模板，尝试一下吧。延伸下面是一些我在Twitter上关注的对象：DanAbramov,Redux的创建者ChristopherChedeau,非常活跃的React开发者，现就职与FacebookJeffMorrison,Flow的核心贡献者之一SebastianMarkbåge,React的创建者之一PeteHuntReact更多值得关注的对象请参考

React