标签：前端
最近几年，应用开发的方法论发生了翻天覆地的变化。随着微服务架构、云计算、单页应用和响应式设计的兴起和发展，在保证项目开发进度、用户体验和应用性能的同时，开发者需要做大量的决策。如今，对于前端开发和 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？或者说你只是从网上复制粘贴，然后提交到版本控制器上？
我们的第一篇文章将会简单地了解下 Yarn，了解下它是如何专注于速度和提供稳定的构建流程的。Yarn 保证这次安装的依赖的版本和下次安装的依赖的版本是完全一致的。保证整个过程平滑、可靠、分布式和规模化是必需的，因为任何停顿都会影响到开发者编程或部署应用的节奏。Yarn 旨在通过为 npm cli 提供快速可靠的替代方案来解决这些问题、管理依赖，但是依然继续使用 npm registry 来安装公共 Node 包。而且，Yarn 是由 Facebook 来维护的，他们在开发这个工具的时候是有所规划的。
应用打包：webpack
我们构建的前端应用程序，通常是由 HTML、CSS 和 JS 以及图像和字体等二进制格式组成的，可能难以维护，甚至会更具挑战性。那么，如何将一个代码库转换为一个优化过的、可部署的项目？Gulp？Grunt？Browerify？Rollup？Systemjs？这些东西都各有优缺点，但是我们需要确保我们的选择能够实现我们上述讨论过的那些原则。
Webpack 是一个专门将 web 应用打包构建为一个优化过的载体传递给用户而打造的一款构建工具，web 应用可能会包含 HTML、CSS、JS、图片、字体等等。如果我们想使用最新的语言特性，比如 import/export 和 class，来使我们的代码更整洁，让工具来打包代码，使其对浏览器和用户都进行优化，那么 Webpack 可以做到这些，而且还可以做的更多！
语言规范：TypeScript
编写整洁的代码从盘古开天辟地时起就是一个巨大的挑战。JavaScript 是一种动态、弱类型语言，为开发人员提供了应用于各种设计模式和规范的媒介。现在，通过最新的 JavaScript 规范，我们可以看到编程社区更加坚实的模式。支持使用 import/export 和 class 等功能给 JavaScript 应用程序开发带来了一个基本的范式转变，并可以确保代码更容易编写、阅读和维护。但是，编程语言中仍然存在着缺陷，通常随着应用程序的增长应用程序本身也开始受到影响：源代码的可维护性和完整性以及系统的可预测性（运行时的应用程序状态）。
TypeScript 是 JavaScript 的一个超集，增加了类型安全、访问修饰符（私有的和公共的）和下一版 JavaScript 的新特性。强类型语言的安全性有助于代码在应用到浏览器中之前通过编译器来验证代码，促进并强化架构设计模式，这有助于缩短开发者的开发周期，同时也可以进行自我记录。这是特别有利的，因为随着应用程序的增长、代码在代码库中发生变化，TypeScript 有助于保持回归检测，同时增加代码库的清晰度和置信度。同时，IDE 集成也是一个巨大的胜利。
如何选择前端框架？
你可能也发现了，目前为止我们都在回避推荐前端框架或库，比如 Angular 或 React。那么，现在我们该聊聊了。
不同的应用需要基于开发团队经验、规模、团队偏好以及对于响应式编程或函数式编程等概念的熟悉程度等因素来选择不同的开发方式。在 Kenzan，我们坚信，无论是 Angular2 还是 React，评估和选择任何与 ES2015/TypeScript 兼容的库或框架，都应该基于当时的开发场景下特定的特征来定夺。
如果我们重新审视早期的项目，我们就会看到一套新的在前端框架选择方面提供了极大灵活性的技术栈。
在前端框架选择方面提供了极大灵活性的现代开发技术栈
在上面的“视图”层之下有一个共同的节点，我们可以通过包含一些关键原则的工具来进行构建应用。在 Kenzan，我们认为这个技术栈给用户需求和开发者体验都提供了一个选择空间。这样的结果可以使任何团队、任何应用（大型应用或者小型应用）都受益匪浅。请牢记，这里介绍的工具是用于特定类型的项目开发的（前端 UI 应用程序），并不是一个可以应用到所有应用的一刀切方案。权衡能力、判断力和团队需求应该是决策的重要因素。
接下来要做的
到目前为止，我们回顾了过去几年 JavaScript 复兴如何导致了快速成熟的 JavaScript 生态系统的形成。我们制定了核心理念，帮助我们应对前端软件开发时遇到的挑战和机遇。我们概述了现代前端开发技术栈的三个主要组成部分。在本系列的剩余章节中，我们将会深入了解每个部分。我们希望，最终你将能够更好地评估你的前端应用程序所需要的基础架构。
我们也希望你能够以一套核心原则、范式和理念为指导，认识到我们所提供的工具的价值。这个系列无疑已经将我们自己的开发经验和开发流程都暴露到了众目睽睽之下，并且在提及前端工具的时候也巩固了我们的理念。希望你能够喜欢我们分享的这些东西，我们也随时欢迎你的任何想法、问题或反馈。
本文出自 “11903871” 博客，请务必保留此出处http://11913871.blog.51cto.com/11903871/1975688
标签：前端
原文地址：http://11913871.blog.51cto.com/11903871/1975688
