前端开发的瓶颈与未来之路

前端开发的瓶颈到底在哪里，前端技术是否已经走到一个十字路口，全栈化的系统架构是否能改变目前的窘境？本文将根据作者自身的开发经历谈谈当下前端开发中遇到的一些问题和想法。

引子

近两年我一直在思考的一个问题：

如果前端不用考虑性能问题、不用考虑终端兼容性、不用考虑历史遗留问题，甚至不用考虑具体技术实现...

如果我们假设自己有丰富的技术储备，同时不用考虑上面的问题，那么前端究竟 能 做出什么样有价值的东西？

我们把时间拉到 5 年前...

如果你「那时」还是前端开发的话。上面的问题肯定是你不得不面临的典型问题。甚至是当时前端开发的意义所在。

但是随着时间的推移，前端技术的更新迭代，以及互联网的发展。你会发现这些曾经的问题似乎已经不再是问题，或者说在能预见的未来 可能 不再是问题。

页面加载性能可能不再是问题，技术上有了 HTTP2，基建上有了 5G，硬盘也越来越快。

兼容性问题慢慢淡出大家的视角，Chrome 一家独大，微软也不得不向它靠拢。

很多前端开发已经具备了后端（或者说多端）的技术能力，技术储备也可能不是问题，当然前提是你能招到人。

定义

到底什么是前端开发，前端与后端的界限在哪里？我在三年前对它的定义是：

前端为界面、交互展示负责；

后端为数据、业务逻辑负责。

不过现在看来似乎已经过时了，我越来越觉得不应该有这样一个清晰的界限把前后端分割开来，尤其是技术层面（除了职能层面的界限有利于协作以外）。这就好比说：如果你不能打破规则，那就必将被规则束缚。

我一直认为程序员应该对新的技术、工具、理念有比平常人更快的适应能力。举个简单的例子，我以前写代码通常使用 tab 缩进，后来大家都建议使用空格，刚开始尝试换成空格肯定是拒绝的，因为让人改变习惯是一件很难的事情。但是当你真正为了改变做出实践的时候，往往就会发现一条新大路。同样还有加不加分号的问题。

现在回过头来再看，前端在整个系统层面担任的角色至少应该是整个视图 View 层面的。视图层面的技术更接近软件系统的上层，更感性。感性的东西就是说一个颜色，我觉得好看，他觉得不好看，完全属于个人情感诉求。所以前端更注重与 UI、交互 以及整个产品层面需要解决的问题。优秀的前端必然要具备敏锐的产品洞察能力。

当然这还只是前端最基础的职责所在。同时前端做为最接近产品的技术角色，技术才是前端真正的硬实力。

大约在去年一年的时间，我的岗位从前端转向了后端 Java 程序员的角色。虽然只做了一年的 Java 程序员，但是对我自身的技术提升而言是最多的一年。大家可能普遍的认为后端转前端比较容易，前端转后端会有门槛，实际上根据我自己的体验来讲并非如此。

Java 这门语言是商业化、成熟度特别高的语言。无论是语言本身，还是周边框架、工具都有一套非常成熟且层次分明的系统化抽象。如果你有两、三年的编程经验，突然让你上转写 Java 是非常容易的一件事情，尤其是写 Java web。Spring 框架已经为程序员屏蔽了很多复杂问题，而且已经事实上成为了各大互联网公司的主流框架选型。

我特意按我自己的学习线路绘制了一张 Java 版的程序员学习线路，仅供参考：

我们可以清楚的看出来 Java 构建的整个体系最大的特点：它是渐进式的，一步一步地给开发者建立正向的引导。

当我处在在 应用层 阶段的时候，我需要关心的只是一些概念，方法，具备基础了以后就可以借助 Spring 框架入门，入门后就可以研究源码，你会发现 Spring 的本质核心类 DispatchServlet，从此 Servlet 就出现在了你的视野。我以前上学时理解不了 java 中 Servlet 的概念，后来参加了工作又学些了 Python，再次看到 Java 中的 Servlet 的时候瞬间就明白了它就是 Python 中的 uwsgi，就是一种接口，将编程语言和服务器网关链接起来的一种规范。

然后你就可以顺利进入下一环节，服务器 / 通信。这里你会发现整个网络编程的核心 Socket，同样以前上学的时候没理解 Socket 的概念，继续学习后你就会明白 Socket 其实就是操作系统提供给编程语言的一种能力，有了它就可以建立服务器与客户端之间的通信。在这一环节中你会学习到网络层 TCP/IP 协议，明白了 TCP/UDP 的区别，while (true) { socket.listen() }建立 Socket 监听会有性能问题，此时你便进入下一个抽象层次，操作系统和计算机原理。

为了解决「while true」监听连接的性能问题，你会去学习多线程技术，了解并发的概念。你可能总会听到别人讨论并发和并行的区别。继续学习后，慢慢的你就会明白：并发多用来解决网络 IO（硬盘）的效率问题，而并行则是为了更好的利用多 / 核处理器（CPU）的问题。这时你会发现这个阶段涉及到了很多的计算机硬件知识。内存分配、CPU 计算、IO 复用等等。

像 Spring 这种 框架 才能真正意义上被称做 框架，因为它不仅仅解决了软件开发的问题，更重要的是 AOP/IoC 这类概念可以完全改变编程的一些理念。使用 Spring 开发 web 应用，联合 Java 构建出来的生态，整个开发流程就像呼吸一样自然。

Java 构建出来的软件开发体系就像是把程序员放进了一个一个的层次分明的小柜子里面，进去了以后你根本不需要关注外界是怎么样的，做好自己那部分工作就可以了。如果你对外界有兴趣可以一点点的顺藤摸瓜，跳出你原来的小柜子。即保证精力专注的同时又建立起一套有秩序的提升曲线。这一点是别的语言体系没有的。

实际上我在转 Java 之前对 Java 有着不小的误解，甚至转 Java 本身也不是我自己的想法。但当你真正转型成 Java 程序员后。看懂了数以百万行记的代码仓库、维护过每秒好几十万的 QPS 项目、见识过百行的 SQL 的时候，你才会对 Java 和软件开发产生一种敬畏之心，才会对技术才有了更深层次的理解。

这时候再回过头来看前端，看 JavaScript，才会发现它们之间的区别与特点。很多之前争论的东西也就有了结论。

瓶颈

我相信从事前端工作稍微长一点（5 年以上）的人近两年都会有一种感觉：前端似乎没什么东西可以玩出花样了。这是因为很多东西都已经成为了前端事实上的主流，以前前端没有的基建慢慢的被完善。语言、框架、可视化、跨端、游戏、工具 / 自动化 / 工程化 这些领域都在发展。

语言方面 TypeScript 必然是主流，无论你愿意与否，你都将不得不使用它来写前端。框架方面 React 已经是事实上的主流了，没必要再做选择题。打包工具 Webpack 也是一家独大，虽然被很多人诟病，但是社区生态起来了，想改变就很难。跨端应用 Electron 也不用想了，VSCode 能做好你做不好那就不是选型的问题了。2D 游戏 / 绘图方面 PixiJS 6 已经在设计中了，3D 我个人认为就先别玩了。

这些看似成熟的体系实际上还是有很多可以挖掘的东西。如果你不深入研究，或许会认为过两年这些技术就稳定了前端就可以做到大一统的状态。这个想法可能就过于天真了，我举例解释下它们各自的瓶颈：

前 / 客户端框架的瓶颈

React（并不特指 React）虽然现在看起来是主流，但是它本身有很多问题是没解决的，甚至可以说是无解的。React 的本质只是一个 UI Library，并不是框架 Framework。框架要解决的问题是系统层面的不是某个抽象层面的。用 React 写过几个项目以后你就会认识到用 React 去写大型项目是非常麻烦的事情，React 本身并不解决 SPA 应用中数据流的问题，甚至没解决状态管理的问题（或者说状态管理本来就是个伪命题？）。一个很简单的父子组件之间状态共享的问题一直没有成熟的解决方案，hooks 这种方案更像是拆了东墙补西墙。

而且现在 React 社区弥漫着一种崇尚函数式编程的邪气，hooks 更像是一块遮羞布。多数人用 hooks 的原因仅仅是不想使用 Class，因为 Class 很臃肿，function 更简单。当然这个逻辑是没问题的。函数确实简单，但是如果你把一个函数里面写上几百行的代码，各种 hooks 用到飞起的时候，你才会回过头来反思如何组织代码。如果 Class 能以一种更好 / 更易于理解的方式去抽象那为什么不用呢？

后 / 服务端框架的瓶颈

前端框架如此，基于 Node.JS 的后端框架也好不到哪儿去，难道你真的想用 Express/Koa.js 去写大型的后端应用？这种量级的框架连 web 开发最简单的三层模型（ 模型、视图、控制器）支持都不完整。当然你可能会说小型框架本来就只关注某一方面嘛，视图和模型层的东西可以用其它三方库解决。是的，确实可以这样，不过你不觉得 Node.JS 的第三方库有点太多了吗。正如 NestJS 在文档中提到的一个问题一样「很多 JavaScript 类库都没有高效地解决一个问题 架构。」React/Vue/Express/Koa 这些都是相对独立的点，没有一个东西能把他们连接起来形成一个面，形成一种框架级别的体系。这就是架构的问题。

这里多说一点，结合上面 Java 构建出来的生态，对比 Node.JS 的话。我借用自己打过的比喻：如果你低头看到的是 Node.JS，那么你抬头未必能看见 Java。假如你从事前端开发 2，3 年遇到瓶颈，想转学 Node.JS，你会学习 Exporess/Koa 这类框架，但是很快你就会发现一个严重的问题：没办法深入下去了。因为当你用 Express 写完一个页面后就面临着各种技术上的盲点，会让你无所适从。

我也尝试绘制一张我对 JavaScript/Node.JS 或者说大前端体系理解的一张图:

JavaScript 体系看似前后端通吃，客户端、 服务端甚至桌面端皆有。但是最大的问题在于：没有一个东西能给他们建立起关系并发展成为一种体系。

插播一条娱乐看点，前两天写 Ruby on rails 框架的作者 DHH 发推并配图：

大意如下：

现在的年轻人在 web 开发的时候是这样的嘛？底层逻辑、纯手写连接池 + 纯手工 SQL、配置文件都放在了一起。天哪！（截图中使用的式 TJ 大神写的 Express 框架）