精读《前端将来展望》

1. 引言

前端展望的文章愈来愈很差写了，随着前端发展的深刻，须要拥有很是宽广的视野与格局才能看清前端的将来。

笔者根据自身经验，结合下面几篇文章发表一些总结与感悟：

• A Look at JavaScript’s Future
• 前端开发 20 年变迁史
• 前端开发编程语言的过去、如今和将来
• 绕过技术纷争，哪些技术决定前端开发者的将来？
• 将来前端的机会在哪里？

读完这几篇文章能够发现，即使是最资深的前端从业者，每一个人看前端将来也有不一样的侧重点。这倒不是由于视野的局限，而是如今前端领域太多了，专精其中某几个领域就足够了，适量比全面更好。

同时前端底层也在逐渐封闭，虽然目击了前端几十年变迁的开发者仍会对一些底层知识津津乐道，但通往底层的大门已经一扇扇逐渐关闭了，将更多的开发者挤到上层区域建设，因此仅学会近几年的前端知识依然能找到不错的工做。

然而上层建设是不封顶的，有人看到了山，有人看到了星球，不一样业务环境，不一样视野的人看到的东西都不一样。

有意思是的国内和国外看到前端将来的视角也不一样：国内看到的是追求更多的参与感、影响力，国外看到的是对新特性的持续跟进。

2. 精读

前端能够从多个角度理解，好比规范、框架、语言、社区、场景以及整条研发链路。

看待前端将来的角度随着视野不一样也会有变化，好比 Serverless 是将来，务实的思考是：前端在 Serverless 研发链路中仅处于使用方，并不会由于用了 Serverless 而提高了技术含量。更高格局的思考是：怎么推进 Serverless 的建设，不把本身局限在前端。

因此当咱们读到不一样的人对前端理解的时候，有人站在一线前端研发的角度，有人站在全栈的角度，也有人站在业务负责人的角度。其实国内前端发展也到了这个阶段，老一辈的前端开拓者们已经进入不一样的业务领域，承担着更多不一样的职能分工，甚至是整个大业务线的领导者，这说明两点：

1. 前辈已经用行动指出了前端突破天花板的各类方向。
2. 同是前端将来展望，不一样的文章侧重的格局不一样，两个标题相同的文章内容可能截然不同。

笔者顺着这些文章分析角度，发表一些本身的见解。

框架

在前端早期，也就是 1990 年浏览器诞生的时候，JS 没有良好的设计，浏览器也没有全面的实现，框架还没出来，浏览器之间就打起来了。

这也给前端发展定了一个基调：凭实力说话。

后面诞生的 Prototype、jquery 都是为了解决时代问题而诞生的，因此有种时代造就前端框架的感受。

但到了最近几年，React、Angular、Vue 大有前端框架引领新时代的势头，前端要作的再也不是填坑，而是模式创新。国内出现的小程序浪潮是个意料以外的现象，虽然群雄割据为开发者适配带来了必定成本，但本质上是中国在前端底层领域争取话语权的行为，而之因此各大公司不约而同的推出本身的小程序，则是商业、经济发展到了这个阶段的天然产物。

在原生开发领域，像 RN、Flutter 也是比较靠谱的移动端开发框架，RN 就长在 React 上，而 Flutter 的声明式 UI 也借鉴了前端框架的思路。每一个框架都想往其余框架的领域渗透，因此标准老是很相近，各自的特点并无宣传的那么明显，这个阶段只选用一种框架是明智的选择，将来这些框架之间会有更多使用场景争夺，但更多的是融合，推进新的开发方式提升生产力。

在数据驱动 UI 的方式上，具备表明性的是 React 的 Immutable 模式与 Vue 的 MVVM 观察者模式，前者模式虽然新颖，可是符合 JS 语言天然运行机制，Vue 的 MVVM 模式也至关好，特别是 Vue3.0 的 API 巧妙的解决了 React Hooks 没法解决的难题。若是 Vue 继续保持蓬勃的发展势头，将来前端 MVVM 模式甚至可能标准化，那么 Vue 是做为标准化的事实规范，仍是和 JQuery 同样的命运，还需观察。

语言

JS 语言自己有满多缺陷的，但经过 babel 前端工程师能够提早享受到大部分新特性，这在很大程度上抵消了早期语言设计带来的问题。

横向对比来看，咱们还能够把编程语言分为：前端语言、后端语言、能编译到 JS 的语言。

之因此有 “能编译到 JS 的语言” 这一类，是由于 JS Runtime 几乎是前端跨平台的通用标准，能编译到 JS 就表明了可跨平台，然而如今 “能编译到 JS 的语言” 除了紧贴 JS 作类型加强的 TS 外，其余并无火起来，有工具链生态不匹配的缘由，也有各大公司之间利益争夺的缘由。

后端语言愈来愈贴场景化，好比 Go 主打轻量级高并发方案，Python 以其易用性占领了大部分大数据、人工智能的运算场景。

与此对应的是前端语言的同质化，前端语言绑定在前端框架的趋势愈来愈明显，好比 IOS 平台只能用 OC 和 Swift，安卓只能用 JAVA 和 Kotlin，Flutter 只支持 Dart，与其说这些语言更适合这些平台特性，不如说背后是谷歌、苹果、微软等巨头对平台生态掌控权的争夺。Web 与移动端要解决的问题是相似的：如何高效管理 UI 状态，如今大部分都采用数据驱动的思路，经过 JSX 或 Template 的方式描述出 UI DSL（更多可参考 前端开发编程语言的过去、如今和将来 UI DSL 一节）、以及性能提高：渲染和计算分离（这里又分为并发与调度两种实现思路，目的和效果是相似的）。

因此编程语言的将来也没什么悬念，前端领域若是有的选就用 JS，没得选只能依附所在平台绑定的语言，而前端语言最近正在完成一轮升级大迁徙：JS -> TS，JAVA -> Kotlin，OC -> Swift，前端语言的特性、易用性正在逐步趋同。须要说明的是，若是仅了解这些语言的语法，对编程能力是毫无帮助的，了解平台特性，解决业务问题，提供更好的交互体验才是前端应该不断追求的目标，随着前端、Native 开发者之间的流动，前端领域语言层面差别会会来越小，你们越关注上层，越倾向抹平语言差别，甚至可能 All in JS，这不是由于 JS 有多大野心，而是由于在解决的问题趋同、业务优先的大背景下，你们都须要减小语言不通带来的障碍，最好的办法就是统一语言，从人类语言的演变就能够发现，要解决的问题趋同（人类交流）、与国家绑定的小众语言一直都有生存空间、语法大同小异，但不一样语言都有必定本身的特点（好比法语表意更精确）、跨语言学习成本高，因此当国际化协做频繁时，必定会催生一套官方语言（英语），而使用基数大的语言可能会发展为通用国际语言（中文）。

将编程语言的割裂、统一比做人类语言来看，就能理解现状，和将来发展趋势了。

可视化

前面也说过，前端的底层在逐渐封闭，而可视化就是前端的上层。

因此笔者不多提到工程化，缘由就是将来前端开发者接触工程化的机会愈来愈少，工程化机制也愈来愈完善，前端会逐渐回归到本身的本质 - 人机交互，而交互的重要媒介就是图形，不管组件库仍是智能化设计稿 To Code 都为了解放简单、模式化的交互工做，专业前端将更多汇集到图形化领域。

图形和数据是分不开的，因此图形化还要考虑性能问题与数据转换。

可视化是对性能要求最高的，所以像 web worker、GPU 加速都是常见处理手段，WASM 技术也会用到可视化中。具体到某个图表或大屏的性能优化，还会涉及数据抽样算法，分层渲染等，仅仅性能优化领域就有很多探索的空间。性能问题通常还伴随着数据量大，因此数据序列化方案也要一并考虑。

可视化图形学是很是学术的领域，从图形语法到交互语法，从一图一作的简单场景，到可视化分析场景的灵活拓展能力，再到探索式分析的图形语法完备性要求，可视化库想要一层层支持不一样业务场景的需求，要有一个清晰的分层设计。

仅可视化的图形学领域，就足够将全部时间投入了，将来作可视化的前端会愈来愈专业，提供的工具库接口也愈来愈有一套最佳实践沉淀，对普通前端愈来愈友好。

BI 可视化分析就是前端深造的一个方向，跟随 BI 发展阶段，对前端的要求也在不断变化：工程化、组件化、搭建技术、渲染引擎、可视化、探索式、智能化，跟上产品对技术能力的要求，实际上是至关有挑战性的。

编辑器

编辑器方向主要有 IDE（Web IDE）、富文本编辑器。

IDE 方向 国产作的比较好的是 HBuilder，国际上作的比较好的是 VSCode，因为微软还同时推出了 Web 版 MonacoEditor，让 Web IDE 开发的门槛大大下降。

做为使用者，如今和将来的主流可能都是微软系，毕竟微软在操做系统、IDE 方面人才储备和经验积累不少。但随着云服务的变迁，引导着开发方式升级，IDE 游戏规则可能迎来重大改变 - 云化。云化使得做为开发者拥有更多竞争的机会，由于云上 IDE 市场如今仍是蓝海，如今不少创业公司和大公司内部都在走这个方向，这标志着中国计算机技术往更底层的技术发展，将来会有更多的话语权。

从发展阶段来讲，前端也发展到了 Web IDE 这个时代。对大公司来讲，内部有许许多多割裂的工程化孤岛，不只消耗大量优秀的前端同窗去维护，也形成内部物料体系、工程体系难以打通，阻碍了内部技术流通，而云 IDE 天生的中心化环境管理能够解决这个问题，同时还能带来抹平计算机环境差别、统一编译环境、源码不落盘、甚至实现自动的多人协做也成为了可能，而云 IDE 由于在云上，也不止于 IDE，还能够很方便的集成流程，将研发全链路打通，所以在阿里内部也成为了今年四大方向之一。

因此今年能够明显看到的是，前端又在逐步替代低水平重复的 UI 设计，从设计稿生成代码，到研发链路上云，这种顶层设计正在进一步收窄前端底层建设，因此将来会有更多专业前端涌入可视化领域。

富文本编辑器方向 是一个重要且小众的领域，老牌作的较好的是 UEditor 系列，如今论体验和周边功能完善度，作得最好的是语雀编辑器。开源也有不少优秀的实现，好比 Quill、DraftJS、Slate 等等，但如今富文本编辑器核心能力是功能完备性（是否支持视频、脑图、嵌入）、性能、服务化功能打通了多少（是否支持在线解析 pdf、ppt 等文件）、交互天然程度（拷贝内容的智能识别）等等。若是将眼光放到全球，那国外有大量优秀富文本编辑器案例，好比 Google Docs、Word Online、iCloud Pages 等等。

最好用的富文本编辑器每每不开源，由于投入的技术研发成本是巨大的，自己这项技术就是一个产品，卖点就是源码。

富文本编辑器功能强度能够分为三个级别：L0～L2：

• L0：利用浏览器自带的输入框，主要指 contenteditable 实现。
• L1：在 L0 的基础上经过 DOM API 自主实现增删改的功能，自定义能力很是强。
• L2：从输入框、光标开始自主研发，彻底不依赖浏览器特性，若是研发团队能力强，能够实现任何功能，典型产品好比 Google Docs。

不管国内外都鲜有进入 L2 强度的产品，除了超级大公司或者主打编辑器的创业公司。

因此编辑器方向中，不管 IDE 方向，仍是富文本编辑器方向，都值得深刻探索，其中 IDE 方向更偏工程化一些，考验体系化思惟，编辑器方向更偏经验与技术，考验基本功和架构设计能力。

智能化

笔者认为智能化离前端这个工种是比较远的，智能化最终服务先后端，给先后端开发效率带来一个质的提高，而在此以前，做为前端从业者无非有两种选择：加入智能化开拓者队伍，或者准备好放弃可能被智能化替代的工做内容，积极投身于智能化解放开发者双手后，更具备挑战性的工做。这种挑战性的工做刚好包括了上面分析过的四个点：语言、框架、可视化、编辑器。

类比商业智能化，商业智能化包括网络协同和数据智能，也就是大量的网络协同产生海量数据，经过数据智能算法促进更好的算法模型、更高效的网络协同，造成一个反馈闭环。前端智能化也是相似，无论是自动切图、生成图片、页面，或者自动生成代码，都须要算法和前端工程师之间造成协同关系，并完成一个高效的反馈闭环，算法将是前端工程师手中的开发利器，且越规模化的使用功效越大。

另外一种智能化方向是探索 BI 与可视化结合的智能化，经过功能完备的底层图表库，与后端通用 Cube 计算模型，造成一种探索式分析型 BI 产品，Tableau 就是典型的案例，在这个智能化场景中，须要对数据、产品、可视化全面理解的综合性人才，是前端职业生涯另外一个突破点。

3. 总结

本文列举的五点显然不能表明前端的全貌，还遗漏了太多方面，好比工程化、组件化、Serverless 等，但 语言、框架、可视化、编辑器、智能化 这五个点是笔者认为前端，特别是国内前端值得持续发力，能够作深的点，成为任何一个领域的专家都足以突破前端工程师成长的天花板。

最后，前端是最贴近业务的技术之一，业务的将来决定了前端的将来，创造的业务价值决定了前端的价值，从如今开始锻炼本身的商业化思考能力与产品意识，看得懂业务，才能看到将来。

讨论地址是：精读《前端将来展望》 · Issue #178 · dt-fe/weekly

若是你想参与讨论，请 点击这里，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。

关注 前端精读微信公众号

版权声明：自由转载-非商用-非衍生-保持署名（创意共享 3.0 许可证）