2019 年（大）前端技术规划

新的一年里，有些新的技术会从实验走向试用；有些技术，则会从试用走向采用；有些技术，则会从采用走向弃用。若是以此为出发点，那么这个 2019 年和过去的 2018 年相比，并不会有太大的区别。学一些新的技术，忘掉一些不同使用的技术。只是前端一个这么广的领域，到底要关心什么技术，到底要忽略什么技术呢？

这便也是我写下这篇文章的意义。可是呢，在写作的过程中：“不行啊，我光告诉你 2019 将会流行什么，可能并没有多大的意义。你们需要自己去学会拥有这样的技能，学会去分析出 2020 需要规划什么内容。”

于此，本文便分为了两部分，如何做前端规划以及 2019 年我们需要什么。

技术规划

W-H-Y

每每谈到技术规划，我们谈的总是下一年、下一个阶段、下一个五年的目标。可为什么我们需要做技术规划？或许是出于 KPI 的影响，或者是出于预算的原因，或是在追求技术卓越。

我们的目的是： 变得更好 。于是乎：“为什么我们就不能使用现在的架构？现在的架构不是挺好的吗？？”

为此，我们只需要尝试回答这么几个问题：项目的编译速度快吗？编写新功能的速度快吗？能满足快速上线的需求吗？多个团队并行开发，会出现问题吗？我们依赖的第三方组件，会出现问题吗？……

嗯，对这个问题就好像，别人在问你，“你有什么不足？”。

HOW

从这篇文章的写作过程，及笔者的相应规划步骤来看，可以分为这么几步：

调研技术远景

从社区获得相应的输入

整理潜在的技术方案、架构、技术栈

从利益相关者获得想法。

制定相关的实施计划

规划，它类似于技术远景的味道。可一谈到远景，那么要谈论的东西可多了。说不到我们还需要寻找利益相关者——如团队成员、项目领导，了解一下，他/她对于技术团队的一些期望。我们在社区上看到相似的问题，总有一个相似的开头：“我们的领导……。”

谈理想都特别有意思，因为我们不一定会去做。我们有了一个宏大的想法，只是受限于多个因素，我们只能做这么一点。比如说，我们未来想造一个笔记本，那么现在我们可以只选一个螺丝钉。

而在我们获取更进一步方向的时候，需要从这么几个维度来考虑问题：

从业务现状出发 。譬如，在下一年里，我们的团队将从 20 人扩大到 100 人，为了支撑这么大的团队。我们需要拥有培训机制，来应对这样的人员扩张；需要设计一个更好的架构，来实现多个团队的并行开发。 从技术、架构出发 。在项目中引入新的技术，改进原有的技术方案。 架构的预研 。提前试用未来可能使用的技术，如 AR、VR。这些往往是一些非必需的规划，但是有了它们会更好。 团队能力规则 。谈论到团队规划，我怕是并不是那么擅长。大抵上，哪怕是技术负责人也不是 KPI 的制定者，我们只能谈谈理想，聊聊团队建设的一些建议。有针对性地培养项目的 2nd Tier，至少对方是否能接受，那便不在我们的控制之下。这大抵也是个人发展的好处，可以选择自己感兴趣的内容学习。 当然了，其它相当多的东西，还是要落地的——我们还是得造螺丝钉。只有落地的东西，才能证明它是真正有价值的东西。为此我们要用 SMART 原则制定一个 smart 目标。当然了，如果你还要对领导汇报，请不到忘了你的时间节点。

总之，保持现在，探索扩展，尝试未来。

WHAT

是不是我们规划每件的事，都值得去做？是不是我们只做规划的事情？未来是一直在发生变化的。而规划，只针对我们知道的内容提出的。它无法用于我们不知道的领域。它也无法应对未知的事务，如产生了一个新的技术，它提高了三倍的生产力。那么，先前我们设计的一些规划，可能在此被新的技术替代掉了。

这方面的实践，便有点类似于演进式架构的味道。我们定好了一个大体的目标，核心的部分，只在真正实现的时候完善。为此，它需要具备一定的可演进式，也因此不会受过去的设计所限制。倘若基于这一点因素考虑，那便是容易得多了。只需要去寻找那些真正可能影响我们的趋势，套上一个模糊的概念，就可以这么轻装上阵。

可是呢，在做这件事情的时候， 每个人心里都有了一个答案 。事实上，你心底也已经有了一个答案，只是说呢，你不敢、不想直接说出自己的想法——一来，受限于能力；二来，怕做了错误的决定。而直接、间接地，你在社区上看到一个大佬的回答，与你想要的答案是类似的。便将这个答案怀chen出来，信心也就有了，再说 “我们也可以这么搞”。好了，以后一旦出现了问题，还有一个人可以莫名地帮你背锅。

大家活着都不容易，背锅事小，不带人身攻击就好。责任，它与能力和屁股的位置是成正比的。

前端 in 后端

所谓的前端 in 后端，便是 在后端开发中，使用前端相关的语言和技术栈 。最典型的场景，便是使用 Node.js 开发后端服务。虽然 Node.js 已经有了 10 年的历史了，但是以我（Phodal）的角度来看，我更希望的是使用编译型语言，来开发后端服务。动态语言，无法使用编译器来检测错误，难以约束代码变动。

Node.js 打造后端服务

从社区的探索来看，存在一些完全使用 Node.js 开发的后台服务。但是，也存在一系列由于代码不规范造成的问题。从社区的经验来看，Node.js + Express + MongoDB + Angular/Vue/React，便是一些不错的选择。当然了，也有相当多的应用，只是采用了 Node.js 来完成 BFF 层（Backend For Frontends）。在这一层业务上，它只做业务数据的中间处理。

虽然，我经常建议在一些关键的节点上，不要采用 Node.js 来打造后台服务。可一旦涉及到 SPA 的服务端渲染，我们就不得不使用 Express、Koa 等这样的服务端 JavaScript/TypeScript 框架，来解决这样的问题。

Serverless

作为一种折中方案，也是我最喜欢的方案。Serverless 架构是指大量依赖第三方服务（也叫做后端即服务，即“BaaS”）或暂存容器中运行的自定义代码（函数即服务，即“FaaS”）的应用程序，函数是无服务器架构中抽象语言运行时的最小单位。

采用 Serverless 架构，也就意味着，我们提取出了大量的基础设施。而使用 Node.js + JavaScript 作为胶水，来快速连接不同的服务，以形成一个快速有效的方案。并且，编写更少的代码，也意味着更安全、快速。

除了直接基于 AWS 的 Serverless Framework 框架的方案，还有 OpenFaaS、Kubeless、OpenWhisk、Fission 等不同的 Serverless 框架。

前端架构

由于前端的代码量在不断地增加，前端不在是一个大泥球架构，越来越多的新架构，将出现在前端领域。

微前端架构

微前端是一种类似于微服务的架构，它将微服务的理念应用于浏览器端，即将 Web 应用由单一的单体应用转变为多个小型前端应用聚合为一的应用。各个前端应用还可以独立运行、独立开发、独立部署。

从笔者在 2018 年的实践经历来看，微前端架构确实是一个不错的架构方案。它能有效地解决臃肿前端应用、遗留前端应用和复杂前端应用。我们在项目上尝试使用了多种不同的实践方式：微件化、微应用化、路由分发、前端微服务化等。将一个应用分解，拆解成更多的应用，确实能相对高效地提升开发效率。

如果你们的应用已经相当的大，记得采用微前端相应的技术。还有阅读我写的《微前端的那些事儿》。

组件库及设计系统

自 Ant Design 的圣诞节事件之后，我相信： 在 2019 年，有越来越多的团队将构建自己的组件库 。一种颇为简单的方案，便是：

评审一个开源组件库 Ant Design、Material Design 等 在开源组件库的基础上，进行二次封装。如 <AutoComplete /> 变成 <pho-AutoComplete> 替换部分的开源组件代码 随后，在那些的基础上，加入自己的模式库和设计系统。

BFF 架构

有越来越多的系统中，出于应对多端（Android、iOS、Web）变化的考虑，便在后端做数据相关的处理工作。为了更好的解耦业务逻辑，并提供更快的业务响应，便在这一层级采用了 BFF 架构。BFF 全称是 Backends For Frontends （服务于前端的后端），它是指在设计 API 时根据不同的设备类型，来返回不同的结果。

除了，采用 Node.js 中相应的后端框架，作为 BFF 层的开发模式。GraphQL 是在 2018 年特别流行的一种 BFF 模式，毫无疑问在 2019 年也是一个值得考虑的方案。

HTML 5 大型游戏

随着移动端的性能不断变好，在 2019 年，我开始看好使用 HTML 5 技术来开发一些游戏。当然了，主要原因还是微信小游戏的出现。但是，不管怎样，我开始尝试在这个领域的探索。

前端 in 前端

前端领域，在 2018 年已经趋于平衡，Angular、Vue、React 都没有出现太大的变化。

框架

架构选型上，也趋势于平衡。该用啥的还是用啥，偶尔还是会出现一些框架切换的新闻。尽管在 2019 年，会出现一些新的框架，但是还不太可能快引起变化。

TypeScript

TypeScript 真香。

前端，没什么好看——除了，娱乐新闻。

前端 in IoT

从 2018 年的趋势来看，至少物联网会在 2019 出现一定的上升趋势。目前的主要表现阶段，是在智能家居相关的领域。如果只是就一领域而言，那大抵还是不错的。

笔者在撰写《自己动手设计物联网》时，使用的技术便是 JavaScript 作为后端和 Web 前端、移动应用的开发技术。而无疑的物联网领域，除了现有的 Web 领域，还有各个地方都可以使用 JavaScript 作为开发语言。

嵌入式 UI 界面。对于处理器资源丰富的设计来说，它们可以采用完整的浏览器来运行前端应用，而不再是裁剪过的引擎。 智能音箱。在过去一年里，已经成为了一个新的入口了。而诸如 AWS Alexa 等都可以采用 Node.js 来开发语言技能。 嵌入式开发语言。诸如可以使用 JavaScript 作为开发语言的 IoT.js。事实上，它会变成类似于 Emacs 架构，由原生来实现编译器，由动态语言来增长特性。 …… 你觉得呢？

开发工具完善

开发工具的完善，一直在每年的规划里。在 2019 年里，也是如此，引入更好的工具，如更好的拖拽工具，更好的代码生成工具——由 AI 生成。

前端 in mobile

前端 in mobile，指的是用前端的技术来开发移动应用。

RN 及 Flutter

依我的角度来看，使用什么跨平台框架来看，区别并不是太大。目前主流的方案，仍然是原生（含跨平台框架） + HTML5 应用。从业务的角度上来看待这个问题，那么还是希望，可以用 HTML 5 的地方多——更新功能方便。

也因此，虽然在过去，笔者写过基于 React Native 的混合应用框架 Dore。我相信：Flutter 也会出现这样的混合应用框架。不过，对于有原生开发能力的团队来说，它们的框架还会是三部分：

原生功能部分

原生 + H5 的频繁更新部分

Fultter 的跨平台部分

写业务嘛，框架都只是工具。

小程序

小程序，即 HTML5 小程序，即无需安装即可下载运行的应用程序。与普通的移动 Web 应用不同的是， 小程序相当于是高阶版的混合应用 。

如果只是从这一点上来看，其实是不是和微信一样的定制型小程序，并不是那么重要。重要的，在于与原生 界面结合，并提供离线使用功能。 它也是小程序与普通的 HTML 应用的区别。

安全

从 2018 年的前端社区经验来看，NPM 包的安全，也成为了一个值得考虑的问题。

也因此 2019 年，也不得不进行相应的安全机制的设计。

也因此 2020年，也不得不进行相应的安全机制的设计。

也因此 2021 年，也不得不进行相应的安全机制的设计。