Blog

Blog

PHODAL

2019 年(大)前端技术规划

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

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

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

技术规划

W-H-Y

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

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

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

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

HOW

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

  1. 调研技术远景
  2. 从社区获得相应的输入
  3. 整理潜在的技术方案、架构、技术栈
  4. 从利益相关者获得想法。
  5. 制定相关的实施计划

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

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

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

  • 从业务现状出发。譬如,在下一年里,我们的团队将从 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 年,有越来越多的团队将构建自己的组件库。一种颇为简单的方案,便是:

  1. 评审一个开源组件库 Ant Design、Material Design 等
  2. 在开源组件库的基础上,进行二次封装。如 <AutoComplete /> 变成 <pho-AutoComplete>
  3. 替换部分的开源组件代码

随后,在那些的基础上,加入自己的模式库和设计系统。

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 年,也不得不进行相应的安全机制的设计。

……

关于我

Github: @phodal     微博:@phodal     知乎:@phodal    

微信公众号(Phodal)

围观我的Github Idea墙, 也许,你会遇到心仪的项目

QQ技术交流群: 321689806
comment

Feeds

RSS / Atom

最近文章

关于作者

Phodal Huang

Developer, Consultant, Writer, Designer

ThoughtWorks 高级咨询师

工程师 / 咨询师 / 作家 / 设计学徒

开源深度爱好者

出版有《自己动手设计物联网》、《全栈应用开发:精益实践》

联系我: h@phodal.com

微信公众号: 与我沟通

标签