我置信从事前端任务稍微长一点（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 框架）

然后 TJ 大神也回复了：

大意如下：

只要菜鸟玩家才能写出洁净、繁复、高功用（黑 Ruby 功用）、见名知意的 SQL，而不是去写一个有15层的笼统。

两者的推特对话挺有意思，大家文娱一下。

TypeScript 言语的瓶颈

TypeScript 也主流，但是继续关注 TS 到如今，我发现 TS 也遇到了瓶颈，这个瓶颈不只来自于 TS 的设计目的与理念，更多的还是社区及 TC39。TS 的设计初衷是 JavaScript 的超集，由于本身要编译成 JS，这一点本质下限制了 TypeScript 的方向，设计者关于添加一个新特性会十分慎重，一者怕与 TC39 ES proposal 抵触，二者要考编译到不同版本 JavaScript 的兼容性成绩。以致于如今 TS 新的言语特性只会跟进 TC 39 发布的最新 ES proposal。但是我团体关于 TC 39 的效率及未来持疑心态度，decorator 的提案不断还处于 Stage 2 的阶段，像这种其它言语都成为标配好几年的事情，如今 JavaScript 社区还在草案（stage-2）阶段。

普及下 ECMA 的标准的流程：

stage-1：前期想象

stage-2：正式提案（装饰器所在的阶段）

stage-3：完成候选

Stage-4：完成测试

各个阅读器 JS 引擎完成；TypeScript 完成

在这个成绩上我以为其实也很益处置，开个脑洞：假设微软想借助编程言语一统阅读器和客户端是没有什么不能够的。并入 TC39 组织，开发真正属于 TypeScript 的原生引擎，奉天子以令不臣的方式也未尝不可。

近几年 Microsoft 关于开源的投入是肉眼可见的，微软要发力我置信很多东西都会有天翻地覆的变化。

打包工具的瓶颈 (责任编辑：admin)