2021 前端会有什么新变化？

[zzzzzzggggggg]

2021 前端会有什么新变化，首先需要搞清楚我们关注这些新技术的目的是什么？

相信对于关注这个问题的人包括我来说，除了了解技术发展风向作为饭后谈资以外，最重要的是看能不能在公司内部落地、做出一番成绩来，当然升职加薪那都是后话了。

回望过去

首先定义一下我说的“过去”是 2019 年及以前。

以史为镜，可以知兴替。回望一下过去，有利于我们对未来做出更好的判断。我们先细数一下过去的几年间大厂的前端都在做什么。

前端工程化

这个应该是前几年社区讨论的最多、面试问到最多的一个名词，那么什么是前端工程化呢？我觉得需要从以下几个概念开始讲起。

模块化

先说 JavaScript 的模块化。

从 ES6 开始，JavaScript 语言有了自己原生支持的模块化方案——ES6 Module，这样有个好处，前端们不用去使用社区定制的模块加载方案，直接使用统一的就好。统一模块方案之后，既可以不用额外引入模块化解决方案的代码，又可以为后面的自动化统一处理做好准备。

再说 CSS 的模块化。

CSS 模块化主要是解决的 CSS 类名冲突的问题，比如常见的 BEM 约定以及社区丰富的 CSS module 解决方案，有了这些东西，前端工程多人开发就可以优雅的解决类名冲突的问题。

组件化

随着 React 生态和 Vue 生态在国内各大前端团队的落地，组件化开发已经是标配了，并且开源社区也沉淀出了以 Element 、Ant Design 为代表的优秀组件库。

大厂的程序员们在组件的概念上又做了一层抽象和封装，比如以业务组件和业务区块为抽象的中后台前端解决方案 Ant Design Pro，并且它还在前端工具库、前端 UI 设计语言等等方案做了统一。

自动化

首先是开发的自动化。

webpack 和 nodejs 在开发的自动化上起了很大的作用。前端项目本地化开发的 server 由 nodejs （常用，也不一定非得是 nodejs ）提供，开发过程中的各种辅助性 plugin 和 loader 都由 webpack 生态提供，上线前的代码打包、代码分割、资源处理也由 webpack 操作，可以说过去几年间很多前端在职业晋升上都吃了引入 webpack 和 nodejs 的红利。

再说 babel，有了 babel 的配合，前端可以写高版本的 JavaScript 方法，配合 webpack loader，自动编译成低版本 JavaScript，前端能力再次得到提升。

其次是部署发布的自动化。

这个应该是很多大厂前端基建团队做的事情，比如持续发布、版本控制、内部 cdn 建设等等。

大前端

这也是个在过去几年炒的很热的词，不过这个词不仅仅是炒作，它也实实在在的扩展了前端的能力以及现有的公司组织架构，比如据我所知有的公司移动端和前端就会划分到同一个团队管理，统称大前端团队。

nodejs

这个在前端工程化部分已经说过一些，这里再次提起是因为在工程化中 nodejs 扮演的角色是提供 nodejs 环境以及部分后端能力，而在大前端团队里是实实在在的存在 nodejs 工程师角色和 nodejs 项目的。比如说在前后端分离的过程中，部分公司（比如阿里淘宝）会发展出一个中间层的东西，这可以理解为是一个大前端团队维护的业务接口聚合层，前端写接口肯定是使用 nodejs 最顺手，而且 nodejs 生态也在蓬勃发展，比如早些年的 TJ 大神一人之力扛起半个 nodejs 生态圈，涌现了 koa 、express 这样的基于中间件的开发库，再到后来阿里巴巴的 egg，再到 Nest.js ，现在基本已经没有裸写 nodejs api 的了。

跨端

先说说手机端

首先，最直接的跨端就是在 APP 壳子里面套 HTML 页面来开发，这种方案也催生了很多 hybrid 解决方案，前端也需要去了解客户端的知识以及 JavaScript Bridge 的设计，同时也减少了 APP 客户端工程师的岗位😂

然后，随着 React 生态蓬勃发展，Facebook 开源了一个跨平台移动应用开发框架——ReactNative，它可以让你以 React 的前端语法来开发移动应用，本质就是虚拟 DOM 映射原生 UI 元素、通过 bridge 调用原生 API，这种思路让前端的触手伸到了移动开发，也促成了大前端团队的建设。Vue 生态也有阿里发起的 Weex 移动开发框架，原理类似。

再后来，Flutter 出现了，它也是一个跨端的开发框架，准确来说它和 JavaScript 生态关系不大，使用 Dart 语言开发 APP，并且有自己的跨平台自绘引擎来保证多端 UI 表现一致，但因为也是一种跨端的解决方案，所以也受到了大量前端工程师的关注和学习。

最后，还是要提一嘴小程序，这个技术方案其实是商业的产物，各个公司都想把内容和生态留在自家的 APP 里，所以从微信小程序开始（微信不是最早，但是发展的最好），阿里、百度、字节跳动等等这些公司都有了自家的小程序。

再说说桌面端

桌面端据我了解使用的比较多的是 Electron，它可以让前端以 JavaScript 来开发出桌面应用，比如字节跳动的飞书桌面端就是使用 Electron 来做的。

总结过去

从过去这些发展的技术可以看出来，前端主要是在做统一化、工程化、生态化的事情，从早些年间的刀耕火种跨越到比较完善的工程化开发，前端的能力范围也得到了扩展，以前不能做的事情现在可以做了。

很多互联网公司的前端高 p 也是在这一波浪潮中晋升，得到了更好的职业发展。

分析现在

首先定义一下我说的“现在”是 2020 年左右。

现在基本上各大公司的前端工程化改造大体完成，各种改造方案、组件库都层出不穷，所以前端又有新玩法了。

Serverless

准确来说，Serverless 并不是前端的技术领域，因为它解决的是让开发者不用关心服务器底层架构和运维工作，形成一种“无服务器”的假象。

那为什么这个技术在前端领域会受到追捧呢？

因为这个技术刚好解决了整个开发链条中前端缺失的能力，即服务端底层和运维能力。各个大公司的前端团队也都在尝试把 Serverless 落地，比如在知乎上就可以看到很多关于 Serverless 的布道。

NoCode 和 LowCode

在我看来，低代码（ LowCode ）和零代码（ NoCode ）产品，是前端对现有能力整合之后，对其他领域的一种扩张和赋能。其实各大公司在某些特定业务场景中早已经有相关的产品落地了，比如广告业务、电商运营的繁多的落地页需求可以使用零代码产品来解决，全程不需要代码参与。

那既然之前有，现在为什么又提起低代码和零代码呢？我觉得原因有两个：

1. 之前解决的只是某些特定业务场景的问题，现在想把这种能力逐渐扩展到更多的业务场景，比如扩展到公司外部，来做 toC 的使用。
2. 之前解决的只是页面级的问题，现在想解决应用级的问题。

总结现在

当然了，现在的讨论的比较多的、正在进行中的技术和解决方案肯定不止我说到的这两种，欢迎大家补充。

目前大公司的前端们也在结合业务在做这方面的事情，如果你所在的团队在做相关的事情，不如加入进去，不管是技术或职业发展，都会有比较好的收获。

展望未来

React Server Component

这个目前还在提案中，未来成熟之后极有可能改变前端的开发方式，前端 React 生态的范围又向服务度端扩展了，一波新的基础建设、技术方案可以考虑了。

Serverless 大规模落地

按照现在社区以及各大公司内部的发展，Serverless 应该会在 2021 有大规模的落地，运维岗位会进一步减少😸

NoCode 和 LowCode 持续发展

低代码这个概念在 2021 年初因为钉钉发布会被再次带火，因为钉钉的使用量以及 toB 端市场有很多内部应用的搭建需求，所以它强调这个概念也不奇怪。

相信有像阿里钉钉这样的企业的推动，低代码和零代码会发展的更好。

不用焦虑

说了这么多，是不是更焦虑了？其实不用。

React 核心成员 Dan Abramov 都大方承认了他并不了解 Flex 、Webpack 等等技术，没试过 Serverless 等等“时髦”技术，很多你会的技术他不会，照很多招聘标准来看他还评不上阿里 P7，但是这并不影响他能成为 React 核心成员，以及他在他自己擅长的领域的造诣。

所以，不用都会，选定一个自己喜欢的、能做出成绩的技术，深入下去吧！

[April5]

目前很心动 esbuild

[zzzzzzggggggg]

@April5 JavaScript builder，比 rollup 还快，值得一试

[jtsai]

Serverless 目前能做什么

[Jirajine]

snowpack 、pnpm 、volta 、orogene

[anguiao]

大佬的不了解是真的不了解吗😂

[liuxey]

@April5 #1 这难道是 "'Node'是有极限的，我不做'Node'了"

[EPr2hh6LADQWqRVH]

前端先老老实实学会面向对象吧

[azh7138m]

飞书的原生版本已经有了，不知道什么时候 GA

[zzzzzzggggggg]

@azh7138m 貌似我当时在的时候还是 Electron

[zzzzzzggggggg]

@avastms 那得先找个对象😂

[mascteen]

denojs

[lihongming]

作为 serverless 深度用户，我想说 serverless 其实干不掉运维，因为对于稳定持续大访问量的应用来说 serverless 太贵了，还是养个运维便宜。而访问量不大的小公司往往也没有运维岗，都是程序员兼任。

serverless 的最佳场景是访问量不稳定的应用，比如很多 saas 每天就那么一两个小时忙碌，大部分时间闲着，此时用 serverless 就很划算。

[betmargt]

前端太太太复杂了。。

[nerocc]

2021 年可以关注一下，围绕着 Web Component 做出来的高性能框架。使用 houdini 的高性能动画效果。wasm 的框架比如 Blazor 。

[murmur]

serverless 落地不是技术问题，是个博弈问题，大厂内部的 serverless 叫高度复用，小公司 serverless 那是把身家都交出去了

不过 serverless 写作业不错，比如毕设要开发一个啥 app

[MakHoCheung]

@azh7138m 真的假的，不跨平台工作量很大的喔

[beginor]

期待三大框架能解决各自的模块化增量发布就好了， 现在每次 build 都要好久 😂

[rodrick]

低代码和无代码的普及还是很难的，现在能普遍应用的场景过于局限了，感觉很多都是一些后台管理系统之类且定制化不是很高的场合

[basstk]

大佬的不了解可能是他不想去了解,而我的不了解,是真的不了解. -_-!

[superBearL]

理想化：组件样式与位置完全拖拽，弱化 CSS，开发人员更专注于 JS 逻辑处理

[corgiyun]

大佬们谦虚的话不要当真，他的不了解可能是相对的。所以...

[zzzzzzggggggg]

@tiglapiles deno 这个没太关注过，能讲讲场景不？

[zzzzzzggggggg]

@superBearL 你说的这个其实我在公司内部正在做，把产品分层考虑，原型+逻辑=产品，如果有好的逻辑描述 DSL，这部分工作完全可以交给外包。。

[zzzzzzggggggg]

@corgiyun 反正面试顶多阿里 p6[狗头][狗头][狗头][狗头]

[zzzzzzggggggg]

@rodrick 解决中后台增删改查场景以及部分流程化的场景还是可以的

[zzzzzzggggggg]

@beginor vue3 貌似拆开了？

[zzzzzzggggggg]

@murmur 所以现在各大厂的前端团队都在削尖脑袋想怎么落地

[zzzzzzggggggg]

@nerocc 好的，我看看

[myCupOfTea]

@superBearL 早就有了 https://www.framer.com/

[zzzzzzggggggg]

@betmargt 还好还好。。这里面的会一部分就是大佬了

[zzzzzzggggggg]

@lihongming 干不掉运维但是减少运维岗位，也算成功了哈哈

[zzzzzzggggggg]

@anguiao 可能是，也可能是谦虚，不过我相信人的精力都是有重点的，要去学的话肯定是能学好

[CQYJ]

现在前端都是向后端靠拢，以后是不是要吃掉后端 全栈？
话说前端难道不应该是关注一下页面呈现和交互吗 以后干脆改个名字直接叫 web 工程师完事了 分什么前后端（手动狗头）

[zzzzzzggggggg]

@CQYJ 其实我觉得最终的形态应该是产品开发工程师。。。。

[chengxiao]

说的好 ，但是每次敲 npm install 都是心惊胆颤～

[geektony]

Rust x WebAssembly

[EPr2hh6LADQWqRVH]

@chengxiao 输入法每次给我补全 npm，你怕吗

[robinlovemaggie]

Dan 哥强在融汇贯通而不是嘴强王者～

[zzzzzzggggggg]

@chengxiao 哈哈，module 太多了吗？

[zzzzzzggggggg]

@geektony Rust 有朋友在做，目前还没看到落地的

[zzzzzzggggggg]

@robinlovemaggie Dan 哥是在某个领域钻的特别深的那种，其他的会不会其实无所谓

[robinlovemaggie]

@zzzzzzggggggg #41 没错，蛋哥去年那个 Just Javascript 就真的很走心～

[bleepbloop]

js 的问题是，很多库用着用着就不维护了，然后又有人重新造轮子

[zzzzzzggggggg]

@bleepbloop 确实，能满足需求的轮子太多了

[zzzzzzggggggg]

@robinlovemaggie Just JavaScript 有地址么？我看看

[zzzzzzggggggg]

@robinlovemaggie 找到了😸

[yaphets666]

@CQYJ 前端分几个方向 搞 js 的 关注性能 框架等等 搞特效的 关注 canvas webGL 等等

[zzzzzzggggggg]

@yaphets666 是的，说的很正确

[MorningStar0]

@avastms 如果是纯前端场景(不包含 node 接口部分)，其实函数式的程序比面向对象，更适合描述 UI 和状态变化。

比如一些低代码平台上，要实现可视化配置的交互事件链

[connection]

期待变化与更多想法

[nanxiaobei]

抵制 TS ！有没有道友！！

[robinlovemaggie]

@zzzzzzggggggg #46 当时是一个 mail list 形式的课程，已经结束了，现在订阅应该收不到邮件了。

[robinlovemaggie]

@nanxiaobei #51 +1，不硬整天就想着把大家往邪路引～

[zzzzzzggggggg]

@nanxiaobei 道友何出此言？

[zzzzzzggggggg]

@robinlovemaggie 收到了，没具体的内容

[zzzzzzggggggg]

@connection 一起加油

[zzzzzzggggggg]

@MorningStar0 这个我做过，先把事件抽象成好几类，然后是组合、逻辑编排

[KuroNekoFan]

@CQYJ 说是这么说，但是纯前端的能力是受限的(至少在浏览器这个上下文里)，受限就表示，有些在页面呈现和交互有改善的点，纯前端做不了。

[KuroNekoFan]

我个人是很希望 bff 能够广泛落地的，但是似乎需要很强的后端和运维基础设施作为前提
比如我 bff 了，页面渲染卡了，算谁的问题？个人认为，什么时候前端开发者在引入 bff 的时候可以不考虑，少考虑这些问题，什么时候 bff 才能广泛落地

[zzzzzzggggggg]

@KuroNekoFan +1

[yngby]

楼主用心了

[zzzzzzggggggg]

@yngby 没事，我后面还会继续写文章的，欢迎一起交流

[gz65555]

bff 其实比较无聊。图形在前端的领域比较有意思，设计师对网页上的效果要求越来越高，WebGL 的使用需求也会越来越多。

[zzzzzzggggggg]

@gz65555 WebGL 确实可以，就是一直没咋研究过

[PlanZ]

React Server Component，仿佛绕了地球一圈，又回到了葡萄牙。
但概念多了不止几倍，东西也越搞越复杂，从这个角度看，其实违背了前后端分离的初衷？

[HALOZ]

要么深，要么广。

[mostkia]

前端无非就是不断造轮子，一层又一层封装。。玩来玩去，解释器还是 JavaScript 。。我就 jquery 一把梭[doge]

[CodeCodeStudy]

前端太多新概念，新花样了

[zzzzzzggggggg]

@PlanZ 概念确实很多很绕。。。但是从前端的角度来看，确实把前端的能力拓展了

[zzzzzzggggggg]

@HALOZ 个人觉得，深比较重要

[zzzzzzggggggg]

@mostkia 换个角度来说，其他语言最后也都是个二进制。。。

[zzzzzzggggggg]

@CodeCodeStudy 唉，找自己感兴趣的做吧，不一定都会，做好一个方向就是大神了

[RickyC]

这些前端技术都适应不了搜索引擎吧?
要想搜索引擎很好地收录, 就得老老实实用后端写吧?

[RickyC]

我不喜欢这么解释"前端工程化"
我希望解释为: 用 Vue, React 等, 并编译执行.
自古以来就有故弄玄虚的人.

[zzzzzzggggggg]

@RickyC 适应搜索引擎的重点不在于是前端写还是后端写，而是能否给搜索引擎抓取到内容和关键词，之前的解决方案是直接服务端渲染为完整的 HTML 来供搜索引擎抓取，以后如果搜索引擎可以对单页应用做比较好的解析，SEO 问题就解决了。

[zzzzzzggggggg]

@RickyC 如果没有 Vue 、React，前端工程化依然是前端工程化，nodejs 在这里面的价值更大一些

[RickyC]

@zzzzzzggggggg 我如果服务端渲染, 为什么不直接用 PHP 来写?
前端工程化的优势不就是分散运算力, 减轻服务器的压力吗?

[zzzzzzggggggg]

@RickyC 直接用 PHP 写那不就成了之前前后端未分离的那一套了么？现在服务端渲染是前端生态的一部分了，框架相关的 vue 生态有 nuxt.js ，react 生态有 next.js ；前端工程化的优势是解决前端从本地开发、前端资源管理、打包、持续集成等等一系列的自动化问题，跟分散运算力关系不大

[RickyC]

@zzzzzzggggggg

要么前后端分离; 要么抛弃现有搜索引擎; 二选一;
对服务端渲染尚不理解.

[RickyC]

@zzzzzzggggggg 如果您说的"解决前端从本地开发、前端资源管理、打包、持续集成等等一系列的自动化问题"指的是前端程序员不会后端语言, 所以用服务端渲染, 我并没有看出其中的价值所在.

[zzzzzzggggggg]

@RickyC 你没太理解我的意思。"解决前端从本地开发、前端资源管理、打包、持续集成等等一系列的自动化问题"解决的是前端工程化开发的问题，前端常常使用 vue 、react 开发的单页应用会存在搜索引擎 SEO 的问题，为了解决这个问题，vue 和 react 分别推出了 nuxt.js 和 next.js 来做服务端渲染，解决 SEO 问题。
不晓得说清楚了吗？

[RickyC]

@zzzzzzggggggg 您很耐心. 但是为什么不能用 PHP 直接写呢?

[RickyC]

@zzzzzzggggggg 那请问 nuxt.js 和 next.js 对用户和搜索引擎是区分的吗? 对搜索引擎使用 SSR, 对用户也使用 SSR 吗?

[zzzzzzggggggg]

@RickyC “为什么不能使用 PHP 直接写呢？”这个问题我一时不知如何回答。。。这个问题很像我们在讨论如何开车从北京去上海最近，然后忽然有人问“为什么不直接坐飞机呢？”
好了正经一点，我想了一下，毕竟这是个前端问题，如果使用 PHP 去写，相当于回到了最早的开发模式，PHP 套模板的开发方式一个是前后端开发界限不清晰，一个是一些前端富应用用后端套模板实现起来很难。
所以总结一下，jsp 、asp 、php 后端套页面——> 前后端分离——> 前端工程化，壮大——> 发现单页应用 SEO 困难——> 前端生态诞生 vue 、react 各自的服务端渲染框架
nuxt.js 和 next.js 渲染对用户和搜索引擎都是 SSR

[thtznet]

假设你前端水平和 Dan Abramov 一样，人家年薪百万美元，你面试被拒，这就是卷。

[zzzzzzggggggg]

@thtznet 哈哈，最高 p7

[RickyC]

@zzzzzzggggggg 有的是前进, 有的是倒退. 我本人非常看好前端工程化; 但是觉得 SSR 是一种倒退.

[zzzzzzggggggg]

@RickyC 算是一种权衡吧，历史总是呈螺旋形前进嘛

[litujin1123]

@zzzzzzggggggg #84， 赞同。用 php 会加大前端的维护成本，学习成本，nuxt.js 等来做就是历史原因

[litujin1123]

@litujin1123 发展历程，说错

[zzzzzzggggggg]

@litujin1123 多谢老兄赞同