2016年JavaScript技术栈展望.docxVIP

/ 2016年JavaScript技术栈展望 如果你正在筹划新的前端项目或者重构现有项目，那么你需要认识到现在的前端开发环境已经今非昔比，这其中有太多的选择了：React、Flux、Angular、Aurelia、Mocha、Jasmine、Babel、TypeScript、Flow…… 它们的本意是将开发简单化，却无形中提高了学习成本，也给未来项目的维护带来了不确定性。 好在这一现象正在退热，优胜劣汰，优秀的项目慢慢沉淀下来，开发方式也越来越清晰。有些开发者正在尝试使用基于上述技术的框架进行开发，也在一定程度上减少了学习成本。 本文中主要介绍了一些我在 Web 应用开发中所涉及和推崇的技术，其中有一些技术上存在争议，所以我对于每一技术都只做简单的介绍和分析。所有的这些观点都是基于我个人的经验和对社区的接触总结而来的，所以各位还请按需各取所用。 React React 可谓风头正盛一时无两： 组件化使应用程序更易于开发和维护 学习曲线平缓，核心 API 简洁清晰，易于学习 JSX 语法不落俗套，充分发挥了 JavaScript 的能量 天生适配 Flux 和 Redux 社区活跃且具有创造力，奉献了诸多优秀的开发工具 单向数据流比双向数据绑定的方式更适合复杂应用程序，质量更高 支持服务端渲染 虽然比起 Ember、Aurelia 和 Angular 这些功能丰富的框架，React 不是全能手，但 React 的开发环境更加健壮。就目前而言，使用 React 已经不是一个技术选择，而是一个商业行为，它能提供更高效和更有效的生产力。 当你想开发移动应用时，因为已经学习了 React 语法，所以可以直接上手 React Native 开发跨平台应用。 Redux 现在，我们已经具有了开发视图层的能力，接下来，我们需要使用其他工具管理应用程序中的状态和生命周期，在这里推荐的工具就是：Redux。 为了配合 React，Facebook 开发了管理单向数据流的工具 Flux，虽然 Flux 基本上实现了对单项数据流的支持，但是同时也带了其他问题，比如如何保存状态、何处发起 Ajax 请求等等。 为了解决这些问题，又衍生了一系列效仿 Flux 模式的框架：Fluxible、Reflux、Alt、Flummox、Lux、Nuclear、Fluxxor…… 目前来说被开发社区广泛支持的一个实现就是 Redux。 在 Redux 中，大多数的组件都是纯函数式的组件，也只有一个集中的存储和资源中心。Redux 的实例方法负责整个数据的操作和维护。相比 Flux 来说，Redux 的思路更加清晰。 更重要的是，Redux 非常易于学习。Redux 的作者 Dan Abramov 是一个优秀的教师，他制作了一系列深入浅出的 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 的方向发展，但缺少了许多高级的类型系统特性，比如代数数据类型（algebraic data types）。此外，它不能像 Flow 一样有效地处理 null。 相比而言，Flow 更加强大，捕获的错误类型也更多，但难于配置。此外，它对 JavaScript 新特性的支持弱于 Babel，也不支持 Windows 系统。 就我个人的角度而言，在前端开发中类型系统并不是至关重要的一环（此处可能有争议）。在类型系统更加健壮且对 Babel 更友好之前，还是让我们静观其变吧。 ESLint 另一个无可争议的工具是 ESLint。ESLint 支持 ES6 语法，