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 语法,还提供了 React 插件,已经不单单是一个代码审查工具了。目前来说,JSLint 已经过时了,ESLint 可以替代 JSHint 和 JSCS 独树一帜了。

开发者可以根据自己的需求配置 ESLint,不过在这里我建议根据 AirBNB 的开发规范进行配置,也可以直接使用 ESLint airbnb config。当然这份规范中尚有不足之处,但保持团队整体代码的一致性,可以有效提高代码的可读性。

当你熟悉了 ESLint 之后,建议开发者深入地尝试其中的规则。ESLint 捕获的错误越多,产品的稳定性越高。

NPM,CommonJS 和 ES6 modules

忘记 Bower 吧,用 NPM 接管一切。类似 Browserify 和 Webpack 的构建工具间接提高了 NPM 在 web 开发中的地位。使用 NPM,版本管理将会更加简单,也将更多地与 Node.js 生态系统接触。目前对于 CSS 的处理尚不足够完善。

你可能会考虑如何在部署服务器上执行构建呢?与 Ruby 的 Bundler 有所不同,NPM 使用了通配符检索文件,且第三方包可以在代码开发中以及项目发布前做任意修改。使用 shrinkwrap 文件可以冻结项目中的第三方依赖,我建议使用 User 的 shrinkwrap,提高输出的一致性。此外,开发者也可以考虑使用类似 Sinopia 的工具托管自己的私有 NPM 服务器。

Babel 会将 ES6 module 语法转换为 CommonJS。CommonJS 是一种历经实践的语法,这意味着稳定和通用,此外,使用类似 tree shaking (Webpack 2.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 是因为其对异步的良好支持。强烈建议使用 Dirty Chai 避免某些问题。Webpack 的 mocha-leader 插件允许开发者自动执行测试。

对于 React 而言,开发者可以参考一下 AirBNB 的 Enzyme 和 Teaspoon。

我非常钟爱 Mocha 的特性,如果你想要的只是最基础的功能,可以参考这篇文章了解一下 Tape。

Lodash

JavaScript 并没有一个类似 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。每个人都在随波逐流的使用 RESTfull API,SOAP 已经成为了过去时。目前业界存在各种 API 协议,比如 HATEOAS、JSON API、HAL、GraphQL 等。

GraphQL 赋予了客户端进行任意查询的能力。搭配 Relay,可以更好地处理客户端的状态和缓存。不过,创建 GraphQL 的服务端接口的难度还较大,且大多数的文档都是面向 Node.js 的。

Netflix 的 Falcor 看起来提供了和 GraphQL/Relay 相似的能力,同时还降低了服务端的需求,但它目前尚处于开发者预览状态,尚未应用于实际开发。

所有已知的规范都各有缺陷,有些过于复杂,有些只能处理数据读取而不嗯那个更新,有些和 REST 差异显著。许多开发者选择自己开发,但是还会遇到上述的问题。

我不认为上述有一个完美的解决方案,但我对 API 有一个自己的认知:

  • 可预测,遵循一致性协议
  • 支持在一次查询中获取多个实体
  • 支持更新操作
  • 易于调试
  • 易于使用

到目前为止,我还没有发现满足上述所有条件的解决方案。

如果你正在使用 RESFful,建议参考 Swagger 来编写 API。

Electron

Electron 可以使用前端技术构建桌面程序,GitHub 团队出品的 Atom 编辑器就是基于 Electron 创建的。本质上,Electron 内部封装了一个 Node.js,可以打开 Chrome 窗口渲染 UI,还可以访问操作系统本地的 API,并且没有浏览器中的沙盒机制。开发者可以通过 Electron 打包和分发应用程序。

这是创建跨平台软件最简单的方式,而且还可以利用上述的所有工具。此外,Electron 有完整的文档和活跃的开发社区。

你可能听说过 nw.js 的大名,虽然它已经存在了多年,但相比来说,Electron 更加稳定和易用。

这里有一个基于 Electron、React 和 hot reload 的模板,尝试一下吧。

延伸

下面是一些我在 Twitter 上关注的对象:

  • Dan Abramov, Redux 的创建者
  • Christopher Chedeau, 非常活跃的 React 开发者,现就职与 Facebook
  • Jeff Morrison, Flow 的核心贡献者之一
  • Sebastian Markbåge, React 的创建者之一
  • Pete Hunt
  • React
  • 更多值得关注的对象请参考 React Influencers

建议阅读 Pate Hunt 的 Learning React!

Dan Abramov 发布一系列的视频教程 Getting started with Redux,强烈推荐!此外,Dan 还发布过一个关注列表,比上述更加详细。

Mark Erikson 的 React/Redux links 集合也是很好的学习材料。

按需使用

JavaScript 的生态环境发展迅速,正日益强大起来。React 的最佳实践正在固化,周边工具的职责和能力也日益清晰。

最重要的事情就是要牢记:保持简洁,按需使用。

如果你的应用程序只有两三屏,那么就无需使用路由系统;如果你正在创建一个单页应用,那么甚至不需要 Redux,只需要 React 自己的 state 属性即可;如果你正在创建一个简单的 CRUD 程序,那么你就不需要使用 Relay;如果你正在学习 ES6,并不需要深入地了解 Async/Await 或装饰器;如果你刚刚开始学习 React,并不需要使用热重载和服务端渲染;如果你刚刚接触 Webpack,你就不需要分离代码和合并多个资源;如果你刚刚学习 Redux,你不需要理解使用 Redux-Form 和 Redux-Sagas。

保持简洁,每次只做一件事!

链接:http://www.w3cplus.com/javascript/state-of-the-art-javascript-in-2016.html           译者:南北

原文:https://medium.com/javascript-and-opinions/state-of-the-art-javascript-in-2016-ab67fc68eb0b#.x7l3e5j4t

时间: 2024-10-12 23:51:13

2016年JavaScript技术栈展望的相关文章

2016年度 JavaScript 展望(下)

[编者按]本文作者为资深 Web 开发者 TJ VanToll, TJ 专注于移动端 Web 应用及其性能,是<jQuery UI 实践> 一书的作者. 本文系 OneAPM 工程师编译呈现,以下为正文的第二部分.点此阅读第一部分. 本地移动 apps 在2015年,出现了一种新的基于 JavaScript 的移动应用开发类别:JavaScript Native.与基于 Cordova 或 PhoneGap 的应用不同,JavaScript 本地应用使用平台的本地控制与范型建立用户界面,无需涉

2016 年前端技术

近几年前端技术盘点以及 2016 年技术发展方向 2016-01-09 10:33 by Barret Lee, 1175 阅读, 8 评论, 收藏, 编辑 Web 发展了几十个春秋,风起云涌,千变万化.我很庆幸自己没有完整地经历过这些年头,而是站在前人的肩膀上行走.Web 技术发展的速度让人感觉那几乎不是继承式的迭代,而是一次又一次的变革,一次又一次的创造.这几年的前端,更为之甚! 我从 12 年底开始接触前端,12 年之前的前端发展情况只能从上一辈的笔触中领会.本文会盘点从 09 年开始到

【Scala】Scala技术栈

快速了解Scala技术栈 我无可救药地成为了Scala的超级粉丝.在我使用Scala开发项目以及编写框架后,它就仿佛凝聚成为一个巨大的黑洞,吸引力使我不得不飞向它,以至于开始背离Java.固然Java 8为Java阵营增添了一丝亮色,却是望眼欲穿,千呼万唤始出来.而Scala程序员,却早就在享受lambda.高阶函数.trait.隐式转换等带来的福利了. Java像是一头史前巨兽,它在OO的方向上几乎走到了极致,硬将它拉入FP阵营,确乎有些强人所难了.而Scala则不,因为它的诞生就是OO与FP

“云”端的语雀:用 JavaScript 全栈打造商业级应用

作者|? 不四(死马)蚂蚁金服 语雀产品技术负责人 语雀是什么? 语雀是一个专业的云端知识库,面向个人和团队,提供与众不同的知识管理,打造轻松流畅的工作协同,它提供各种格式的在线文档(富文本.表格.设计稿等)编辑能力,支持实时在线多人协同编辑,数据云端保存不丢失.而语雀与其他文档工具最大的不同是,它通过知识库来对文档进行组织,让知识创作者更好的管理知识. 语雀技术架构演进 原型阶段 语雀诞生于 2016 年,当时蚂蚁金融云需要一个工具来承载它的文档.当时负责的技术同学利用业余时间,开始搭建这个文

互联网前端开发技术栈

互联网前端开发技术栈 前言 互联网建立60多年了,网站开发技术日新月异,但web前端始终离不开浏览器,最终还是HTML+JavaScript+CSS这3个核心,围绕这3个核心而开发出来大量技术框架/解决方案. 我从2000年初开始做网站开发,使用的技术不断迭代,一些消失了,更多的出现了. 最近写过  .NET技术大系概览 (迄今为止最全的.NET技术栈) ,相信很多网友感叹掌握的.NET技术远没有这个技术栈里面所描述的多. 问题 大家是否想过: Web前端开发究竟包含哪些技术呢? 我所掌握的技术

谈谈我的技术栈

还记得第一次源码安装nginx,make总是报错,说需要PCRE的函数库,于是乎卸载了机器自带的函数库,打算重装,导致折腾了一个星期的centOS7挂掉... 还记得手抖update没加条件,手工从其他表中恢复数据时的紧张... 还记得2015年4月份,杭州原型客户上线,四天四夜没有离开客户现场,每当凌晨1,2点要回酒店的时候,就发现了巨大的Bug 还记得2016年双11,第一次不再仅仅是个买家的身份,参与双十一... 种种场景仿佛历历在目,让我久久不能释怀,扯远啦......来说说我的技术栈吧

非对称技术栈实现AES加密解密

非对称技术栈实现AES加密解密 正如前面的一篇文章所述,https协议的SSL层是实现在传输层之上,应用层之下,也就是说在应用层上看到的请求还是明码的,对于某些场景下要求这些http请求参数是非可读的,这就要求在前端和后端不同的技术栈上完成信息的加密解密.当然我们通常完成这样专业的功能都会考虑使用相应的框架或者程序库来完成功能,前端或者NodeJS平台通常是JavaScript语言,JavaScript主流的加密解密库分别是SjclJS和CryptoJS, 本文以CryptoJS为例进行讨论.另

一个人的 ClojureScript 技术栈

作者:题叶链接:https://zhuanlan.zhihu.com/p/24425284来源:知乎著作权归作者所有.商业转载请联系作者获得授权,非商业转载请注明出处. 今天(昨天)分享完关于 ClojureScript 的话题, 算是如实重负. 我嗓子不好, 之前分享过 React, 但相比在网上总是差很多, 这次分享也是紧张, 会场的 Keynote 没有按照预想放在挺高的地方, 也没有下一页的预览, 看着大屏幕衔接没做好. 但是说真的心里还是忐忑的, 提问的同学很犀利, 几个都在点子上,

“MEAN”技术栈开发web应用

“MEAN”技术栈开发web应用 上一篇我们讲了如何使用angular搭建起项目的前端框架,前端抽象出一个service层来向后端发送请求,后端则返回相应的json数据.本篇我们来介绍一下,如何在nodejs环境下利用express来搭建起服务端,使之正确的响应前端的请求.本文所讲的示例还是基于我们的学习项目QuestionMaker(https://github.com/Double-Lv/QuestionMaker) 运行起基于express的web服务器 express是一个web应用开发