大前端
2018 年的事儿特别多从 React v16 普及到 jQuery 被 GitHub 下掉完成阶段性历史使命在唏嘘之外版本帝 AngularJS 又发布了 v6 和 v7 两个版本。这些其实都不算啥大新闻反观三大框架写法越来越像越来越贴近 WebComponents 标准而周边应用层面的封装已经开始指数级增长。小程序是今年最火的技术接连出现快应用也想分一杯羹。PWA 进入稳定期尤其是 PWA 桌面版可以让我们更好的看清楚 PC 桌面版开发的全貌。移动端还是以强运营为主各大公司都开始不再 all in 移动开始重视多端并进到了开始拼细节的阶段了。TypeScript 全面开花GraphQL 蠢蠢欲动WebAssembly 更是打开了浏览器上多语言的大门。所有的这一切都在暗示浏览器即操作系统你能想象到未来前端的样子么下面跟着我一一进行解读吧。
三大框架标准化
有朋友吐槽“Vue 的特点就是上手快初期相当好用但如果接手一个别人写的 Vue 项目再和 React 对比一下你会感谢 React 的”。但当 Vue 3.0 发布之后估计他就不会这样说了。因为 Vue 3 的 Class API 和 React 的写法几乎是一模一样的这个改动不是 Proxy 和 TypeScript而是支持原生 Class 的写法。你用 Class 来写那代码和 React 写法几乎是一模一样的
import Vue from 'vue'
class App extends Vue.Component {
count = 0
up() {
this.count++
}
down() {
this.count--
}
render() {
return (
<div>
<h1>{this.count}</h1>
<button onClick={() => this.up()}>+</button>
<button onClick={() => this.down()}>-</button>
</div>
)
}
}
Vue.render(<App />, document.body as HTMLElement)
从上面的讨论可以看出前端三大框架已经趋于平稳化、标准化在我看来未来是 WebComponents 的。
WebComponents 是规范最早最知名的一个是 Google 主推的 JavaScript 库 Polymer它可帮助我们创建自定义的可重用 HTML 元素并使用它们来构建高性能、可维护的 App。在 I/O 大会上Google 推出了 Polymer 3.0Polymer 3.0 致力于将 Web 组件的生态系统从 HUML Imports 转移到 ES Modules包管理系统将支持 npm这使你更容易将基于 Polymer 的 Web 组件和你喜欢的工具、框架协同使用。
<script src="node_modules/@webcomponents/webcomponents-loader.js"></script>
<script type="module">
import {PolymerElement, html} from '@polymer/polymer';
class MyElement extends PolymerElement {
static get properties() { return { mood: String }}
static get template() {
return html`
<style> .mood { color: green; } </style>
Web Components are <span class="mood">[[mood]]</span>!
`;
}
}
customElements.define('my-element', MyElement);
</script>
<my-element mood="happy"></my-element>
另外还有 2 个项目具有一定的参考价值
1.Rax 也提供了一个名为 atag 的 UI WebComponents 库。
2.LitElement 是一个简单的轻量级的快速创建 WebComponents 的基类可以理解成是 Polymer 最小的实现版本。
LitElement 主要的特性包括 WebComponent 生命周期模型支持和单向的数据绑定模型。它遵守 WebComponents 标准使用 lit-html 模块这个快速的 HTML 渲染引擎定义和渲染 HTML 模板。最重要的是它对浏览器兼容性非常好对主流浏览器都能有非常好的支持。由于 LitHtml 基于 tagged template结合 ES6 中的 template使得它无需预编译、预处理就能获得浏览器原生支持并且扩展能力更强性能更好。
import { LitElement, html } from '@polymer/lit-element';
// Create your custom component
class CustomGreeting extends LitElement {
// Declare properties
static get properties() {
return {
name: { type: String }
};
}
// Initialize properties
constructor() {
super();
this.name = 'World';
}
// Define a template
render() {
return html`<p>Hello, ${this.name}!</p>`;
}
}
// Register the element with the browser
customElements.define('custom-greeting', CustomGreeting);
是不是看着更眼熟了
《三国演义》里有这样一句“话说天下大势分久必合合久必分。周末七国分争并入于秦。及秦灭之后楚、汉分争又并入于汉。汉朝自高祖斩白蛇而起义一统天下后来光武中兴传至献帝遂分为三国。”
前端从 2014 年到 2017 年是混战期得益于 Node.js 的辅助加成外加各种前端优秀的创意和实践使得 React/Vue/Angular 三足鼎立。无论 React 发布 v16增加 Fiber 和 Hooks还是 Vue 3.0 发布其实最终都是朝着 W3C WebComponents 标准走。一言以蔽之Follow 标准是趋势如果能够引领标准那将是框架的无上荣耀。
我们可以参考一下技术成熟度曲线Hype Cycle -Wikipedia这个曲线把技术发展分成五个步骤
【科技诞生的促动期】->【过高期望的峰值】-> 【泡沫化的底谷期】 -> 【稳步爬升的光明期】 -> 【实质生产的高原期】。
从前端现在的热度来看应该是处于从第三阶段【泡沫化的底谷期】到第四阶段【稳步爬升的光明期】的爬坡过程创新不会那么多更多的是偏于应用层的内容。
对于当下的前端发展情况我其实是有隐忧的。当年 Java 世界曾经搞各种 GUI创造了 MVC 模式结果没火没想到到了 Web 开发领域MVC 成了基本约定。之后 Model 1 和 Model 2 等企业开发模型渐渐成熟出现了 Struts、Spring、Hibernate 三大框架。在之后很长的一段时间里Java 程序员都是言必称“SSH”。再之后 Spring 一家独大一统江湖恐怕今天还记得 EJB 的人已经不多了。框架一旦稳定就会有大量培训跟进导致规模化开发。这是把双刃剑能满足企业开发和招人的问题但也给创新探索领域上了枷锁。
应用层封装进入爆发期
框架和工程化基本探索稳定后大家就开始思考如何更好的用更简单的用。目前各家大厂都在前端技术栈思考如何选型和降低成本统一技术栈。
举个例子 UmiUmi 就是一套零配置约定高于配制按最佳实践进行开发的开箱即用的前端框架: React 全家桶 + dva + jest + antd (mobile) + less + eslint。如下图所示
从上图中可以看出Umi 已经思考的相对全面从技术选型、构建到多端输出、性能优化、发布等方面进行了拆分使得 Umi 的边界更为清晰是前端最佳实践目前大多数前端组都是类似的实现方式。说白了Umi 和 create-react-appcra类似就是现有技术栈的组合封装细节让开发者用起来更简单只写业务代码就可以了。
-
零配置就是默认选型都给你做好了。
-
开箱即用就是技术栈都固化了。
-
约定大于配置开发模式也固化好了。
Umi 的核心是 af-webpack 模块它封装了 Webpack 和各种插件把 webpack-dev-server 等 Node.js 模块直接打包进去同时对配置做了更好的处理以及插件化。af-webpack 核心是 webpack-chain 模块通过链式写法来修改 Webpack 配置使得 af-webpack 极为灵活。其实以 React 全家桶为例开发者最大的负担就是 Webpack 工程化构建。关于 Webpack 的封装实践有很多比如知名的还有 YKit、EasyWebpack 等。
-
YKit 是去哪儿开源的 Webpack内置 Connect 作为 Web server结合 dev 和 hot 中间件对于多项目构建提效明显对版本文件发布有不错的实践。
-
EasyWebpack 也是插件化但对解决方案、boilerplate 等做了非常多的集成比如 Egg 的 SSR 是有深入思考的尽管不赞同这种做法。
另外在 create-react-appcra项目里使用的是 react-scripts 作为启动脚本它和 egg-scripts 类似也是通过约定隐藏具体实现细节让开发者不需要关注构建。在未来类似的封装还会有更多的封装并且更偏于应用层面。
PWA 进入稳定期
PWA 和 native app移动应用的核心区别在于以下几点
1. 安装PWA 是一个不需要下载安装即可使用的应用。
2. 缓存使用native app 主要是对 sqlite 缓存以及文件读写操作而 PWA 对缓存数据库操作支持的非常好足以应对各种场景。
3. 基本能力补齐比如推送。
现在 PWA 已经支持的很好了唯一麻烦的是缓存策略和发版比较麻烦应用轻量化的趋势已经很明朗了。下面讲一下 PWA 的一些关键点。
1. 通用本地存储的解决方案 Workbox
Workbox 是 GoogleChrome 团队推出的一套 Web App 静态资源和请求结果本地存储的解决方案该解决方案包含一些 JS 库和构建工具Workbox 背后则是 Service Worker 和 Cache API 等技术和标准在驱动。在 Workbox 之前GoogleChrome 团队较早时间推出过 sw-precache 和 sw-toolbox 库但骂声很多直到 Workbox 才真正诞生了能方便统一的处理离线能力的更完美的方案。
Workbox 现在已经发布到了 3.0 版本不管你的站点是用何种方式构建的它都可以为你的站点提供离线访问能力几乎不用考虑太多的具体实现只用做一些配置就可以。就算你不考虑离线能力它也能让你的站点访问速度更快。
比如星巴克的 PWA 应用对缓存的应用高达 41.3mb。这是浏览器端非常大的突破尽管没啥新技术。
2.PWA 桌面版
纵观 PC 桌面端的发展过程早期 Delphi/VB/VF/VC 等构建起的 c/s 时代即使到今天依然有很大的量。最近两年随着 Atom/VSCode 的火爆带动了 node webkit 相关模块的爆发比如 NW.js 和 Electron 等。通过 Web 技术来构建 pc client确实是省时省力用户体验也非常好比如钉钉客户端、石墨文档客户端等最主要的是可以统一技术栈比如某些算法用 JS 写一次之后可以到前端、node、pc client 等多处复用。当然更好的是使用 Web 技术进行开发不需要加壳打包PWA 桌面版就是这样的技术。
接下来就具体聊一下桌面端的 3 个发展阶段。
第一阶段原生开发 Native
早年的 VB/VF/VC/Delphi 等原生开发方式到后来出现 QT 类的跨平台软件但依然可以理解成是原生开发。
第二阶段混搭开发 Hybrid
谷歌于 2008 年 9 月 2 日首次发布了 Chrome 浏览器Node.js 是 Ryan Dahl 于 2009 年发布的他把 V8 引擎Chrome 核心 JavaScript 引擎搬到了后端使用 js 编写服务器程序变为现实。随后 npm 发展极为迅猛跨平台技术也突飞猛进出现了 NW.js 这样的轻量级跨平台框架基于 ChromiumChrome 开源版本 + Node.js使得 PC 桌面端能够通过 Web 开发技术开发最终打包编译成各个平台支持的应用格式给 PC 桌面开发带来了太多的可能性。
而 Atom 是 GitHub 在 2014 年发布的一款基于 Web 技术构建的文本编辑器其中 atom-shell也就是后来的 Electron是和 NW.js 类似的技术。它允许使用 Node.js作为后端和 Chromium作为前端来完成桌面 GUI 应用程序的开发。Chromium 提供了渲染页面和响应用户交互的能力而 Node.js 提供了访问本地文件系统和网络的能力也可以使用 NPM 上的几十万个第三方包。在此基础之上Electron 还提供了 Mac、Windows、Linux 三个平台上的一些原生 API例如全局快捷键、文件选择框、托盘图标和通知、剪贴板、菜单栏等。
Erich Gamma 老爷子设计的 Monaco/VS Code同样基于 Electron但性能比 Atom 强多了。VS Code 会先启动一个后台进程也就是 Electron 的主进程它负责编辑器的生命周期管理、进程间通讯、UI 插件管理、升级和配置管理等。后台进程会启动一个或多个渲染进程用于展示编辑器窗口它负责编辑器的整个 UI 部分包括组件、主题、布局管理等等。每个编辑器窗口都会启动一个 Node.JS 子进程作为插件的宿主进程在独立进程里跑插件逻辑然后通过事件或者回调的方式通知 Renderer 结果避免了 Renderer 的渲染被插件中 JS 逻辑阻塞。
演进过程chrome > Node.js > nw.js > atom(electron) > vs code
在第二阶段里我们可以看到 PC 桌面端以 Web 开发技术作为核心以浏览器内核作为跨平台核心最终将 Web 开发的代码和浏览器内核打包。这样做的好处是前端开发相对简单相对于 C++ 等语言更为方便另外从成本上考虑也是极为划算的。
如今很多应用都开始基于 Electron 构建比如微信小程序 ide、微信 pc 版本等另外非常令人激动的是2018 年 10 月 18 日迅雷论坛发文称新版从迅雷 X 10.1 版本开始采用 Electron 软件框架完全重写了迅雷主界面。使用新框架的迅雷 X 可以完美支持 2K、4K 等高清显示屏界面中的文字渲染也更加清晰锐利。从技术层面来说新框架的界面绘制、事件处理等方面比老框架更加灵活高效因此界面的流畅度也显著优于老框架的迅雷。
第三阶段PWA 桌面版
王国维在《人间词话》中提出“隔与不隔”这一文学命题这个问题在开发领域也是存在的。明明是 Web 开发的为什么还要打包加壳呢除了体积非常大以外使用安装也极为麻烦。
Spotify 的 PWA 桌面版应用体验是非常好的在 mac 上丝般顺滑。
2018 年 Google IO 大会上微软宣布 win10 全力拥抱 PWA通过爬虫爬取 PWA 页面并将其转换为 Appx继而在其应用商店里提供应用体验和原生 Native 应用非常相近对此我非常看好。
浏览器有着超强的缓存能力外加 PWA 其他功能使得浏览器上的 PWA 应用能够取得媲美 Native 应用的性能。在浏览器里可以直接打开无需加壳很明显这是极为方便的。
PWA 必然会改变前端与移动端之间的格局再加之 AOT(ahead-of-time) 与 WebAssembly 为 JS 带来的性能上的突破JavaScript 将撼动所有领域从移动端PWA到桌面应用、物联网、VR、AR、游戏乃至人工智能等等。
Google 接下来会大力推进 PWA 的桌面版再加上 win10 和 Chrome 加持Web 应用无需加壳就能达到近乎原生的体验前端的领域再一次被拓宽未来真的可以大胆的想想。
很多人问 PWA 在国内为什么感觉不火原因很简单PWA 在弱网环境下表现极好但中国的网络是全球最好的所以 PWA 其实没有给我们带来那么大的收益。不过当做一个补位方案也挺好的毕竟 2G/3G 还有点量另外在服务器渲染 SSR 上PWA 也能够起到很好的效果。
小程序火爆
如果说和 PWA 比较像的大概就是小程序了小程序也可以说是今年最火的技术。
微信小程序的下一步计划支持 NPM、小程序云、可视化编程、支持分包等听起来很美好但坑依然不少。小程序原生提供的 DSL 不够好用所以就有了上层开发框架或者脚手架来优化开发效率目前比较主流的有 3 个
今年还冒出了微信小程序之外的头条小程序、支付宝小程序、百度智能小程序等未来还会有很多。同时手机厂商大概是看到了小程序对其应用商店的威胁小米、华为、OPPO、vivo 等九大国内手机厂商联手成立了“快应用联盟”基于 react-native 技术栈整体也很不错尤其是天猫调用菜鸟裹裹的快应用安卓下有非常好的体验。相较而言微信是基于 Webview 的而快应用使用的是原生渲染方案其他家也大抵如此。
其实 5G 时代很快就到了大家可以畅想一下在网速、内存和 CPU 更高的情况下5G 每秒最高下载速度高达 1.4G秒下 PWA 或小程序应用到底是离线还是在线犹未可知吧。
前端能讲的东西实在太多了但受限于篇幅本文只能先简单跟你分享 React/Vue/Angular 三大框架标准化、应用层封装进入爆发期、PWA 进入稳定期、小程序火爆等方面的内容。下一篇文章中我将继续跟你聊聊移动端局面、多端拉齐的必然性等内容以及 2019 年不可忽视的 TypeScript 和 WebAssembly 这两大技术欢迎继续关注也欢迎留言与我多多交流。
多端拉齐并重用户体验
在 AI 时代没有“端”的支持可以么明显是不可以的。首先感谢苹果将用户体验提升到了前无古人的位置。移动互联网兴起后PC Web 日渐没落。我个人非常欣赏玉伯在当年无线 ALL IN 战略中他还是选择留下来继续做 PC Web 的前端。不过虽然很多公司的重点转向无线但 PC 业务也一直没停这是很多公司的现状也是客观事实。那么PC 端这样的“老古董”的出路到底在哪里呢
1. 我们可以利用 PC/H5 快速发版本的优势快速验证 AI 算法继而为移动端提供更好的模型和数据上的支撑。
2. 多端对齐打好组合拳。既然不能在移动端有更大的突破大家只能在细节上血拼。
大家的战场已经不是点了已经升级到打组合策略的阶段了。未来一定是多端拉齐并重用户体验的。
今天的大前端除了 Web 外还包括各种端比如移动端、OTT甚至是一些新的物联网设备。我们有理由相信 Chrome OS 当年的远见“给我一个浏览器我就能给你一个世界。”如果说的苟且一点“给我一个 Webview我就能给你一个世界。”
TypeScript
我之前就非常关注 TypeScript但迟迟未下定决心在团队内落地。今年 1 月份北京 Node Party 上组了个局和几位嘉宾一起聊了一下确认提效非常明显落地难度也不大大家一致认为 2019 年 TypeScript 将有非常大的增长。本身前端团队变大规模化编程也必然依赖类型系统和面向对象的从这点上看TypeScript 也是完胜的。
这里再简单介绍一下 TypeScript它是有类型定义的 JavaScript 的超集包括 ES5、ES5+ 和其他一些诸如反射、泛型、类型定义、命名空间等特征的集合为了大规模 JavaScript 应用开发而生。复杂软件需要用复杂的设计面向对象就是一种很好的设计方式使用 TypeScript 的一大好处就是 TypeScript 提供了业界认可的类 ES5+ 也支持、泛型、封装、接口面向对象设计能力以提升 JavaScript 的面向对象设计能力。市面上的框架也对 TypeScript 提供了非常好的支持。
React 对.tsx 支持非常好比如我在 Midway controller 里支持 tsx 写法这是非常大胆的对于后面 react ssr 来说是一个极大便利
Vue 从 v2.5.0 之后对 ts 支持就非常好
Node.js Web 框架尤其是 Egg.js 对 ts 支持非常好当然还有更高级更专注的的 Midway 框架Midway 基于 Egg 生态同时提供 IoC 等高级玩法
在使用 Webpack 编译前端应用式通过 TypeScript-loader 可以很轻松地将 TypeScript 引入到 Webpack 中。有了 TypeScript-loader就可以一边使用 TypeScript 编写新代码一边零碎地更新老代码。毕竟 ts 是 js 超集你有空就改非强制特别包容。
WebAssembly
WebAssembly 是一种新的字节码格式目前主流浏览器都已经支持 WebAssembly。 和 JS 需要解释执行不同的是WebAssembly 字节码和底层机器码很相似可以快速装载运行因此性能相对于 JS 解释执行而言有了极大的提升。 也就是说 WebAssembly 并不是一门编程语言而是一份字节码标准需要用高级编程语言编译出字节码放到 WebAssembly 虚拟机中才能运行 浏览器厂商需要做的就是根据 WebAssembly 规范实现虚拟机。这很像 Java 早年的 Applet能够让其他语言运行在浏览器里。Applet 是一种 Java 程序它可以运行在支持 Java 的 Web 浏览器内。因为它有完整的 Java API 支持所以 Applet 是一个全功能的 Java 应用程序。
有了 WebAssembly在浏览器上可以跑任何语言。从 Coffee 到 TypeScript到 Babel这些都是需要转译为 js 才能被执行的而 WebAssembly 是在浏览器里嵌入 vm直接执行不需要转译执行效率自然高得多。
举个例子AutoCAD 软件是由美国欧特克有限公司Autodesk出品的一款自动计算机辅助设计软件可以用于绘制二维制图和基本三维设计。使用它时无需懂得编程即可自动制图因此它在全球被广泛应用于土木建筑、装饰装潢、工业制图、工程制图、电子工业、服装加工等诸多领域。
AutoCAD 是由大量 C++ 代码编写的软件经历了非常多的技术变革从桌面到移动端再到 web。之前InfoQ 上有一个演讲题目是《AutoCAD & WebAssembly: Moving a 30 Year Code Base to the Web》即通过 WebAssembly让很多年代久远的 C++ 代码在 Web 上可以运行并且保证了执行效率。
本来我以为 WebAssembly 离我们很远但在 2018 年 Google I/O 大会亲眼见到 AutoCad Web 应用后非常震撼效果如下图所示。
能够让如此庞大的项目跑在 Web 端真的是非常了不起。通过 WebAssembly 技术既能复用之前的 C++ 代码又能完成 Web 化这也许就是所谓的两全其美吧。
之前全民直播的前端研发经理赵洋曾分享了 WebAssembly 在全民直播里对直播编解码方面的应用效果也非常不错。
另外许式伟在 ECUG Con 2018 上也分享了一个 Topic主题是《再谈 Go 语言在前端的应用前景》Go 的发展也遇到了瓶颈专注后端开发是没办法让 Go 排到第一的目前的一个方向是借助 GopherJS将 Go 代码编译为 JS。这种实践是没问题的和 Kotlin 类似对于绝大部分 Go 用户也是非常好的。但问题在于真正的前端不太可能换语言目前连 Babel、ts 这种都折腾的心累更何况切换到 Go。“求别更新了老子学不动了”这是大部分前端工程师的心声。
从 WebAssembly 的现状来看对于复杂计算耗时的部分采用其他语言实现确实是比较好的一种方式。从趋势上看WebAssembly 让所有语言都能跑在浏览器上浏览器上有了 vm浏览器不就是操作系统了吗
Chrome 的核心 JavaScript 引擎 V8 目前已包含了 Liftoff 这一新款 WebAssembly baseline 编译器。Liftoff 简单快速的代码生成器极大地提升了 WebAssembly 应用的启动速度。不过在桌面系统上V8 依然会通过让 TurboFan 在后台重新编译代码的方式最终让代码运行性能达到峰值。
目前V8 v6.9 (Chrome 69) 中的 Liftoff 已经设置为默认工作状态也可以显式地通过 --liftoff/–no-liftoff 或者 chrome://flags/#enable-webassembly-baseline 开关来控制。另外Node.js v11 采用的 v8 引擎的 v7 版本对 WebAssembly 支持更好虽然这没啥意义但练手还是蛮好的。
移动端
Flutter 是 Google 推出的帮助开发者在 Android 和 iOS 两个平台同时开发高质量原生应用的全新移动 UI 框架和 React-native/Weex 一样支持热更新。Flutter 使用 Google 自己家的 Dart 语言编写刚好今年 Dart 2 也正式发布不知道二者之间是否有关联。目前 Dart 主攻 Flutter 和 Web 两块同时提供了 pub 包管理器俨然是一门全新的语言学习成本有些高。反观 TypeScript 就非常容易被接受基于 npm 生态兼容 ES 语法因此2019 年对 Dart 我还是会持观望态度。
除了不喜欢 Dart 外Flutter 的其他方面都很好在移动端现在强运营的背景下支持热更新是必备能力。
关于 Weex一边骂一边用很无奈的一种状态。Weex 本身是好东西捐给了 Apache目前在孵化中会有一个不错的未来。但社区维护的非常差问题 issue 不及时文档不更新。如果公司没有架构组还是比较难搞定的。
不过也有很多不错的案例比如 2018 年优酷双十一活动就是使用 Weex 开发的效果非常不错。通过自建的可视化活动搭建平台能够非常高效的完成开发结合 App 内的缓存整体效果比 H5 好的多。
我对 Weex 的看法是以前 Weex 只是解决 H5 渲染效率的问题但如今强运营的背景使得 Weex 承载了非常多的内容比如动画、游戏甚至是图形图像处理等。可以看到未来 Weex 还会战略性的增加。
总结
总结一下2018 年大前端的现象
前端三大框架已趋于平稳标准化向 Web Components 看齐。
应用层面开始进入过渡封装周边的阶段很多细节都会埋在框架里。
PWA 平稳发展兼容 4/5 浏览器workbox 3 进一步简化开发另外 PWA 桌面版已经开始兴起未来会更多。
多端受到重视不再只是 all in mobile。
WebAssembly 让更多语言可以运行在浏览器上AutoCAD 的 web 版是非常好的例子。
强运营背景下移动端以前端开发为主已成定局。Flutter 局势暂不好说还在观望中主要是不喜欢 Dart。
TypeScript 落地很好包容性更好React 对.tsx 支持非常好Vue 从 v2.5.0 之后对 ts 支持就非常好Node.js尤其是 Egg.js、midway对 ts 支持也非常好。
5G 时代快来了互联网的长期在线情况有可能会被打破。本地设备即客户端可以大胆的想想。对前端来说本地 web 服务辅助日常开发类似于 je 这样的模块会越来越多。
终上所述未来浏览器会越来越重要Web Os 的概念正在慢慢落地。另外三大框架趋于稳定写法上也越来越像学习成本是降低的。但周边应用层面的封装还会是爆发式增长更多复杂的细节会被包装到应用框架里可能还有很多不一样的开发方式需要大家熟悉。
对于开发者而言唯一不变的就是学习能力。掌握了学习能力就能够应对这些趋势变化无论是在三大框架混战时代还是后面周边封装时代都能很开心的“折腾”。哪怕有一天 AI 真的能够替人写代码能应变的人自然也是不怕的。
关于大前端的现状和未来我就分享到这里希望能对你有所帮助。