如果前端不用考虑性能问题、不用考虑终端兼容性、不用考虑历史遗留问题，甚至不用考虑具体技术实现...
如果我们假设自己有丰富的技术储备，同时不用考虑上面的问题，那么前端究竟能做出什么样有价值的东西？
我们把时间拉到 5 年前...
如果你「那时」还是前端开发的话。上面的问题肯定是你不得不面临的典型问题。甚至是当时前端开发的意义所在。
你会为了精确还原设计稿熬夜加班，从而练就一双像素眼；
你会为了解决几个字节的性能问题研究优化方案；
你也会因为某些技术问题和同事理论，最终到达到与产品谈笑风声的境界；
但是随着时间的推移，前端技术的更新迭代，以及互联网的发展。你会发现这些曾经的问题似乎已经不再是问题，或者说在能预见的未来 可能不再是问题。
页面加载性能可能不再是问题，技术上有了 HTTP2，基建上有了 5G，硬盘也越来越快。
兼容性问题慢慢淡出大家的视角，Chrome 一家独大，微软也不得不向它靠拢。
很多前端开发已经具备了后端（或者说多端）的技术能力，技术储备也可能不是问题。
定义
到底什么是前端开发，前端与后端的界限在哪里？我在三年前对它的定义是：前端为界面、交互展示负责；后端为数据、业务逻辑负责。
不过现在看来似乎已经过时了，我越来越觉得不应该有这样一个清晰的界限把前后端分割开来，尤其是技术层面（除了职能层面的界限有利于协作以外）。这就好比说：如果你不能打破规则，那就必将被规则束缚。
我一直认为程序员应该对新的技术、工具、理念有比平常人更快的适应能力。举个简单的例子，我以前写代码通常使用 tab 缩进，后来大家都建议使用空格，刚开始尝试换成空格肯定是拒绝的，因为让人改变习惯是一件很难的事情。但是当你真正为了改变做出实践的时候，往往就会发现一条新大路。同样还有加不加分号的问题。
现在回过头来再看，前端在整个系统层面担任的角色至少应该是整个视图 View 层面的。视图层面的技术更接近软件系统的上层，更感性。感性的东西就是说一个颜色，我觉得好看，他觉得不好看，完全属于个人情感诉求。所以前端更注重与 UI、交互 以及整个产品层面需要解决的问题。优秀的前端必然要具备敏锐的产品洞察能力。
当然这还只是前端最基础的职责所在。同时前端做为最接近产品的技术角色，技术才是前端真正的硬实力。
瓶颈
我相信从事前端工作稍微长一点（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 这些都是相对独立的点，没有一个东西能把他们连接起来形成一个面，形成一种框架级别的体系。这就是架构的问题。
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 的标准的流程：
1.stage-1：前期设想
2.stage-2：正式提案（装饰器所在的阶段）
3.stage-3：实现候选
4.stage-4：完成测试
5.各个浏览器 JS 引擎实现；TypeScript 实现
在这个问题上我认为其实也很好解决，开个脑洞：如果微软想借助编程语言一统浏览器和客户端是没有什么不可能的。并入 TC39 组织，开发真正属于 TypeScript 的原生引擎，奉天子以令不臣的方式也未尝不可。
近几年 Microsoft 对于开源的投入是肉眼可见的，微软要发力我相信很多东西都会有翻天覆地的变化。
打包工具的瓶颈
Webpack/Babel 就更不用说了，主流中的主流。但是也是问题最严重的一个。Webpack/Babel 的流行恰恰从反面证明了前端的基础设施有多么的烂。现在国外网友老天天叫喊着 Webpack/Babel is eval 也是挺值得深思的。我们引入了一个新工具来解决问题，却又在不经意之间产生了新问题。
前端构建工具问题的本质还是在于 Node.JS 的包管理工具的设计。这一点在 Node.JS 的作者 Ryan Dahl 关于 Deno 演讲《10 Things I Regret About Node.js》中也有过「官方」的承认。我相信任何一个实现过构建工具的人都被 Node gyp 打败过。node-sass, fsevent 的痛不必细说。更不用说万年被黑的 node_modules 了，你根本不知道一个简单的 npm install 命令会导致安装成千上万个 npm 包被安装到你的机器上。
当然每种编程语言对应的包管理工具都要解决依赖问题，而且这是一个普遍的问题，脚本 / 解释型编程语言尤为突出，Python/Ruby/PHP 都有这些类似的问题。或许 Go/Rust 这种把源代码编译打包成单个可执行文件的方式才是好的解决方式。
请继续观看下篇文章：WEB前端开发的未来之路。
