现代前端开发技术栈

时间:2017-07-29 17:43

首图

这篇文章将会介绍过去几年 JavaScript 开发方面的革命性发展。

最近几年,应用开发的方法论发生了翻天覆地的变化。随着微服务架构、云计算、单页应用和响应式设计的兴起和发展,在保证项目开发进度、用户体验和应用性能的同时,开发者需要做大量的决策。如今,对于前端开发和 JavaScript 更是如此。

为了帮助大家跟上节奏,我们先来简单了解下最近几年 JavaScript 开发方面的革命性发展。然后,我们会了解下前端开发社区所面临的一些挑战和机遇。

JavaScript 的文艺复兴

2009 年 NodeJS 横空出世时,它已经不仅仅是可以在命令行中运行或在 server 端运行的 JavaScript 了。NodeJS 围绕着迫切需要解决的软件开发方面的问题做出了革命性贡献:针对于前端开发者的成熟稳定的生态系统。正是由于 Node 和它默认的包管理器 npm 的存在,在应用开发和应用构建方面,JavaScript 兴起了一场文艺复兴。生态系统繁荣起来了,但是由于当时 Nodejs 还很年轻,所以经常会出问题。

让人欣慰的是,过去几年代码模式和代码规范达到了顶峰。2015 年,JavaScript 社区见证了 ES2015 的发布,生态系统再一次爆发式繁荣。下面的描述仅仅展示了 JavaScript 生态系统中最流行的一部分。

2017 年 JavaScript 生态系统一览

在 Kenzan,我们在多种平台上——从浏览器到机顶盒——使用 JavaScript 开发了十多年。我们目睹了前端生态系统的成长、发展,拥抱社区所付出的所有积极的努力。从 Grunt™ 到 Gulp,从 jQuery® 到 AngularJS,从复制脚本到使用 Bower 来管理前端依赖,这些我们都经历过了。

JavaScript 日渐成熟,我们的开发流程也是如此。在为客户端开发设计优雅、性能稳定、成熟的软件应用时,我们意识到健壮的本地开发工作流和技术栈是我们成功的基石。在开发过程中对可靠性、成熟性和高效性的追求让我们感受到整个开发环境不仅仅是一套工具的堆积,相反,好的开发环境有助于最终产品的成功。

挑战和机遇

伴随着如此多的选择、如此繁荣的生态系统,社区将何去何从?尽管有选择是件好事情,但是对于社区来说,确定从何开始、需要什么和为什么需要是有些困难的。随着用户期望的增长,应用程序应该如何运行和表现(加载速度更快,运行更顺畅,响应式,可以和原生应用媲美等等),在开发团队的生产力需求和该项目能够在预期市场上推出并取得成功之间求取平衡,变得越来越具有挑战性。针对于此,甚至有一个名为分析导致瘫痪(analysis paralysis)的术语:由于过于思考和不必要地使问题复杂化使得做决策变成了一个难题。

在工程开发周期,一味追求最新的工具和技术会制约开发速度,阻碍重大里程碑的实现,带来推迟上市和客户流失的风险。在一定程度上,一个团队需要明确自己的问题和需求,然后从可选的方案中做出决策,认清利弊,这样才可以更好地预测产品的长期可行性和可维护性。

在 Kenzan,我们的经验使我们能够定义和整合一些关键的概念和理论,以确保我们的决策有助于解决我们在开发前端软件时所预料到的挑战:

利用 JavaScript 语言提供的最新功能来支持更优雅、一致和可维护的代码(比如import/export (modules)、class 和 async/await)。

提供一个稳定成熟的、低到无需维护的(即,开发人员不需要安装或维护全局的开发依赖,且具有直观的工作流/任务流)本地开发环境。

利用包管理器来管理前端构建依赖。

部署优化过的、基于功能特性的 bundles(已经打包了HTML、CSS和JS),为用户提供更智能、更快速的分发和下载。结合 HTTP/2,可以获得小投入大产出的效果,可以大大提高用户体验和产品性能。

新的技术栈

在这篇系列里,我们的关注点是前端开发技术栈的三个部分。对于每个部分,我们将了解下我们认为能够为现代 JavaScript 应用程序开发的可靠性、高效性和可维护性提供最佳平衡的工具。

包管理器:Yarn

如何以可靠和持续重现的方式管理和安装外部 vendor 或内部包的挑战,对于开发者的工作流来说是至关重要的。同时,维护 CI/CD(持续集成/持续交付)也是至关重要的。但是,你选择哪个包管理器来评估上述所有的功能呢?npm?jspm?Bower?CDN?或者说你只是从网上复制粘贴,然后提交到版本控制器上?