- 《架构师》2019年4月
- InfoQ中文站
- 8160字
- 2020-06-26 06:07:46
2019年大前端技术趋势深度解读
大家好,我是阿里巴巴前端技术专家狼叔,今天想跟你们分享2019年我对前端现状及未来发展趋势的理解。
我其实特别反感很多人说“前端娱乐圈”这种话,诚然,爆发式增长必然会带来焦点,但也不必过度解读,2018年的几件大事儿我都了解,真的不是大家看到的那样的。学会辩证的看问题,用心去体味背后的趋势,我想这比所谓的“正直”更有价值,我更希望大家能够坚持学习,保持思辨和平和。
大前端
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.0, Polymer 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的人已经不多了。框架一旦稳定,就会有大量培训跟进,导致规模化开发。这是把双刃剑,能满足企业开发和招人的问题,但也给创新探索领域上了枷锁。
应用层封装进入爆发期
框架和工程化基本探索稳定后,大家就开始思考如何更好的用,更简单的用。目前,各家大厂都在前端技术栈思考如何选型和降低成本,统一技术栈。
举个例子Umi, Umi就是一套零配置(约定高于配制),按最佳实践进行开发的,开箱即用的前端框架:React全家桶 + dva + jest + antd (mobile)+ less + eslint。如下图所示:
从上图中可以看出,Umi已经思考的相对全面,从技术选型、构建到多端输出、性能优化、发布等方面进行了拆分,使得Umi的边界更为清晰,是前端最佳实践,目前大多数前端组都是类似的实现方式。说白了,Umi和create-react-app(cra)类似,就是现有技术栈的组合,封装细节,让开发者用起来更简单,只写业务代码就可以了。
·零配置就是默认选型都给你做好了。
·开箱即用就是技术栈都固化了。
·约定大于配置,开发模式也固化好了。
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-app(cra)项目里使用的是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这样的轻量级跨平台框架,基于Chromium(Chrome开源版本)+ 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真的能够替人写代码,能应变的人自然也是不怕的。
关于大前端的现状和未来我就分享到这里,希望能对你有所帮助。