一位前辈对 Web 前端职业的评价
career

一位前辈对 Web 前端职业的评价

转载自 现在还建议学前端吗? - 知乎 今天是2023年2月20日,来AT其中之一的大厂已经干了6年前端了。没怎么正经回答过知乎问题,这个问题准备认认真真的回答下,给后人避坑,先匿名了说的多了肯定有...

花野猫

花野猫

更新于 2023-08-20

12503

转载自 现在还建议学前端吗? - 知乎

今天是2023年2月20日,来AT其中之一的大厂已经干了6年前端了。没怎么正经回答过知乎问题,这个问题准备认认真真的回答下,给后人避坑,先匿名了说的多了肯定有人认得出来我。 先上结论不建议。我将从以下几个方面来论述下为什么不建议。

地位低

没错,前端在整个需求研发链中的地位是最低的。 通常来说一个需求的从立项到上线的流程大概是这样的(细节省略,只说个大概)

  1. 产品侧提出需求
  2. 交互视觉设计交互和视觉稿
  3. 前后端参与开发
  4. 开发完成后交付测试
  5. 测试完成业务方进行验收,验收通过上线

在整个流程中,前端是既向前,也向后。 前端面对产品视觉交互来说,就是个乙方。要去完成各种交互设计和视觉设计,这其中如果实现难度大复杂的话,也只有认了加班加点去搞,没什么话语权的,就是技术大佬出面也只能降降级或者拉长工时。想要设计产品,更改交互和视觉那是不可能的,因为前端的一个重要的工作内容就是去完成需求。所以向前来说就是个乙方没什么地位。 向后就是面相后端,也是个乙方。简单来说前端要把后端抽象的数据和信息具象化,后端设计数据结构不会管你页面怎么设计的,他们会考虑数据的聚合性关联性等等,方便对数据进行增删查改。后端吐出什么样的数据结构前端也只有认命,如果你觉的返回的数据结构不合理,想要后端去改。那基本不可能了,就是你的前端大佬出面也解决不了,后端的架构设计不可能因为你一个小前端觉得数据操作起来难受就去更改,不好处理的话,就自己想办法,堆屎山代码去处理吧。 面向测试还是个乙方,测试由于要对产品质量负责,对线上bug负责,在日常研发中话语权是很重的。做前端面对各种各样的机型浏览器环境,是很难把一些bug从根上处理干净,例如低端机型的js动画卡顿,基本无解。如果碰到个上纲上线的测试,那基本上天天就难受吧,测试不下班你也走不了,测试下班前提的bug,你也要加班加点的修完才能下班。不然第二天测试为了不担风险,会直接向上汇报,到时候会更难受。 综上看是不是前端地位很低?面向什么群体都是乙方,只有加班的份。

易背锅

除非整个系统挂了,其他一些线上问题,只要想让前端背个锅,都能让你背。举个例子,曾经做过一个功能页,展示用户优惠的价格,因为这个是关键信息。不能做字段防御,例如后端未下发就不展示这个dom,这样的话跟总价计算不准。但是有一天后端就是出问题了, 未下发字段,前端显示的是节省了undefined元,导致用户投诉。 所以问题来了,前端有问题吗? 可以让你有,理由就是页面鲁棒性不够,这个字段缺失的情况下,前端可以根据总价和结算价格计算出来,完全可以避免掉这个问题,承担部分责任。 因为前端直面用户,所以后端出的任何问题,哪怕是交互设计不合理的问题,只要别人愿意,都能让你背一部分锅。除非你巧舌如簧舌战群儒,但是天天扯皮撕逼是不是也很累?

晋升难

前端晋升面试有个经典问题,面试官会问,你说你做的这些功能,我找别人做不是一样也能做出来码?你做的这些和外包有什么区别呢?如果你bulabula回答了一堆例如性能还原度鲁棒性强等等之后,还是可以问,如果找别人做,没你说的这些,但是功能上不一样可以用吗?所以你说的这些价值上如何能体现出来。 这就是前端晋升的一个大问题,只是日常做需求,把代码写的精益求精,性能很快鲁棒性强并没有什么用,只是做需求,没法衡量价值。想要晋升就要会搞事情,搞事情就是造轮子,搞个新的工具库、脚手架、npm包、新的组件库、新的规范,引入新的框架等等,总之如果不搞事情,只是本本分分做业务基本不会晋升了。 而日常工作中排需求时长不会因为你要搞事情,就给你多几天开发时间,想搞事情就只有加班和周末。 而后端就不一样了,他们在日常研发中对代码的重构抽象就可以作为晋升的理由,而且说出来十分的好看,例如优化了表的设计减少了数据冗余度,降低数据调用层级等等,这些做好统计都能直观的反映出来节约了多少成本。 想想一下前后端都提名了一个人,只能晋升一个。后端说他在日常研发中重构抽象代码,为公司节省了xxxx元的成本。而前端说我在日常研发中也重构抽象了代码,让页面打开快了200毫秒。你是老板你会提谁?

可替代性强

大部分前端没有一个是不可替代,前端做的大部分工作就是把后端的接口数据和视觉界面连接起来,变成可交互的。所以就这个事情来说10年的前端能做,刚毕业的新人一样能做,无非就是做的快慢好坏而已。新人做的慢?没关系加班搞一搞一样能和10年的前端一样一周做完,无非就是新人加班多而已。新人做的bug多?没关系多加班修bug就好了,加班多还显的团队氛围好,有活力。等修完bug最终上线,老板和用户能看的出来这个页面是新人做的还是10年老前端做的吗?所以只要互联网不强制8小时的话,哪怕你经验再丰富,与新人相比没有任何的优势。 做些技术难度大的会被不可替代吗?一样的。我曾经遇到过一个很厉害的同事,一个用canvas做的大数据下的场景选择组件,用了大量的线性代数做矩阵计算,后来这个同事走了,没人能维护的了,那么猜猜后来怎么样了?用这个组件的页面先不做大的迭代维护了,然后又找人另起炉灶做了个新的,后来的人数学不行,玩不转线性代数,全拿三角函数替代计算,做完后总体来看跟老的比差多了,数据量一大就会卡。但是没关系,有些局部功能比老的好就行了,比如支持了高清绘图和可缩放功能,这个做完之后虽然与之前的比更烂了,但是这个项目让三个人获得了晋升。 所以如果你觉的深耕前端技术增强自己的不可替代性的话,建议你别走这条路了。后面的人面对维护不了的东西,更愿意重起炉灶,做完了还能弄个晋升的理由。不要觉得某个功能只有你能做别人做不了,什么样的前端功能都能做的出来,只要市面上有,打开开发者模式研究研究就知道个大概了,再不行就全用图片一帧帧的糊出来,就是体验不好,但是功能一样用。 国内没有哪家公司是靠前端技术壁垒占有市场的,你要是能开个淘宝宝京东东,价格都是他们的一半,哪怕页面没有css,体验糟糕至极,用户照样会去在你上面下单。

局限性大

有空继续更 ----------------看到评论不少同行都说真实,中午不休息了继续更--------------- 我入行前端那会正是前端最热的那几年,node 出道不久,有不少文章在讨论 node 和 java 比性能是不是更好。react 横空出世,virtual dom 的出现让人们觉得 js 下一步就可以统一客户端。曾经有句很流行的话,能用 js 写的都可以用 js 去写。那会的钉钉 pc 端用的是 electron,拼多多的 app 就是个套壳 h5。若干年过去了,现在什么样有心人都能看到,我也不用多写了。 抛去前端自身领域,前端有两个个方向可以拓展,一个是纵向的,向后往服务端方向发展。另一个是横向的向客户端(泛指android和ios)方向发展。 先说纵向的,很多人入坑都有着我先学前端,再往后端涉入最后成为全栈。就我身边来看能深入到后边的,最深也就是靠后端帮忙搭了个 node 中间层,然后前端给后端们写他们不想写的增删查改业务逻辑,甚至就是只能写无状态的函数逻辑,当然规范约定这些还是后端来定,理由很简单,你是前端对这方面不专业。想再往后去涉及数据库设计,高并发高可用基本不可能。 那么前端出身转成后端写 java 可行吗?如果有这个想法那就一开始入坑 java 不就好了。实际上如果入坑前端转后端,要比一开始转后端更难。入坑前端后,大部分时间你处理的问题大多都是琐碎而没有意义的。例如这个样式怎么样安卓下就跪了?这句 setstate 怎么没生效页面没更新?我重新装了依赖了怎么没生效?项目怎么突然跑不起来了?解决这些问题只会让你更加理解浏览器原理,框架原理,兼容性等等,这些都是应用层面的,并不会提升你对计算机底层诸如操作系统、计算机网络、数据库原理等相关方面的理解。所以很多三五年的前端,根本不明白请求了接口之后,后端那边都发生了什么,只知道他们更新数据库的数据之后,返回了个新的数据给你去处理。其实远远没这么简单,他们有负载均衡,有缓存池,有网关校验,权限处理,安全校验等等,后端去处理这些问题会进一步加深对计算机底层的理解,这些都会渐渐地成为一个人的技术壁垒,并且永不过时。 每个人的一天都是24小时,当你的大部分时间都在处理这些琐碎问题,无助于你去向后拓展的时候,就会随着时间的增长而积重难返,更难向后拓展。 再说下横向的,往客户端方向发展。就我跟客户端的合作经验来看,客户端的学写前端很容易,但是反过来就很难。客户端学习前端的困难点就是css,而css这种解释性语言的学习成本有多高,对于客户端也写样式的人来说,并没有高到成壁垒的程度。客户端的一看到react和vue的生命周期,就会立马拍大腿,这玩意我熟,客户端开发就是这么设计的。 而前端向客户端拓展却不容易,很简单的一点就是前端日常的积累对理解操作系统几乎没有任何帮助,cpu调度,内存管理,垃圾回收、进程、线程、协程。我敢拍着胸脯保证,前端对操作系统这些一点都不懂,根本不影响日常工作,但是如果不懂这些能做客户端开发吗?所以客户端的人去开发前端是降维,前端去开发客户端就是爬坡。 所以综合来看,后端和客户端吃前端的肉,要比前端吃客户端后端的肉容易的多,真要是裁员逼到份上,最危险的是谁不言而喻。 所以前端还能往哪拓展,只有向内拓展了,俗称内卷。继续造轮子,不停地造轮子,所以看看前端生态一片"生机勃勃",css的预编译,MVVM、构建工具,servless、BFF、微前端,哪一个概念下面不是一堆轮子。拍着良心说,如果这些概念下面只有一个框架,哪怕是没有。我们的现代APP就开发不出来了吗?显然不是的,淘宝PC站这么复杂,不也是kissy堆出来的,到了去年才更新了一波,这7 8年都用kissy不怎么维护不照样能让你浏览下单购物。前端去花时间钻研这些,并不会提升你对计算机底层的理解,对这些应用层的投入最后会随着未来新概念新框架的产生,变成时代里废弃的尘埃。

业务上的看似重要

很多人说前端对业务研发很重要,但实际情况是前端只是看似重要。前端其实主要面向两个群体C端和B端。 先说C端,C端最在乎用户体验。前端在C端业务中扮演的就是投石问路的角色。我就是做了很多年C端,一个很常见的场景就是外部市场变化,有个新概念兴起,比如在线教育、社区团购、剧本杀等等,这个时候前端开发周期要比客户端短多了,所以就拉个项目找几个前端,疯狂加班赶紧上线,然后看看效果。 如果效果不错,下一步呢?就是客户端化,把交互体验变得更加完善,因为前端已经上线了,客户端不用疯狂加班,按时做完就好。上线后h5引流到客户端,渐渐地这个业务客户端就会变得很重要,那前端呢?只能说谢谢你曾经的加班和努力。 如果效果不好的话,那只能说很倒霉了,不光没有功劳,也没有苦劳。年终述职你如果揪着一个失败的项目大谈加班辛苦做了很多,无异于再打老板的脸,跟他说你的决策很失败。 所以看到没有,前端就是敢死队。打开你的手机翻几页看看你的app,哪一个承载主体不是原生native开发的,没有一个是套壳h5实现。如果有,那只能说明这个业务还在发展期,或者不重要。 也有说PC业务前端不是很重要,如果你有心的话就会发现,几乎市面上所有大型网站是不是好几年都没更新了,app好久没更新,更新一次操作路径就变了,但是你输入网址打开的页面,万年不动。所以不怎么更新的东西重要吗? 接下来是B端业务,实事求是的讲更不是很重要。B端用户不像C端这么在乎用户体验,所以基本都是用h5承载,B端用户不会在意页面打开的快不快,流不流畅,只要不是太过分,能用就行。这样的话还需要前端吗,只能说可以需要,也可以不需要,养个前端团队给你上antd,界面好看,交互体验更好。但是B端用户在意这些吗?他们只在意功能有就行,别的其实都是锦上添花可有可无。大环境好养个前端团队维护维护中后台业务,环境不好直接裁掉,业务照样用。java不会写react,没关系,到新路径全是jsp写的,丑点一样用,老的维护不动不会改,那就拿jsp一点点的替换掉。所以说B端业务,前端就是可有可无的存在,后端一样能做,只是很多后端不想做这些。说的直白点他们觉得做这些太low,但是他们不会这么跟前端讲的,这番话只能说懂得都懂,不懂的会为前端做很多辩解。

最后

有句话曾经不是很敢说,现在让我说我是很有自信的,那就是”传统前端在大厂已经死了,在非大厂正在死亡的路上“。 首先定义下什么是传统前端,就是写个页面,调个接口,把数据塞到页面里,然后绑几个事件完成交互。这些就是培训班最爱教的,也只能教的。如果你只能做这些,那在大厂里面年年绩效就是垫底,没几年就会当做”人才“输出到社会上。 然而讽刺的是前端90%的工作不就是做这些吗? 还有10%的前端,也就是非传统前端,他们的生命周期要长一点,但也是路途坎坷。那么非传统前端是干什么的呢?就是不做传统前端做的事,也不做后端和客户端主要的事,在夹缝中生存的前端。 他们写框架、写脚手架、写工具库、写内部应用平台、拓展node生态等等,本质上讲就是在为传统前端服务,但是唇亡齿寒。而且非传统前端也就大厂养得起,如果长期不做业务就会畸形,想想一个前端精通node和编译原理,能够手写ATS编译器,但是vue和react整的不是很明白,你会怎么看? 还有一类前端不去做页面开发了,他们去开发游戏、地图、流媒体,数据可视化。这类前端前景如何我了解不多,欢迎有人提供信息。不过据我了解做这些开发的技术栈应用场景应该是更窄,而且他们做这些也会面临客户端更有利的竞争。

何去何从

以下一些无脑随想,可略过。 现在学前端就是49年入国,如果入坑时间不长,抓紧转还来得及,如果像我一样积重难返了,我也不知道怎么办,只能自求多福了。并不是怕后来的人抢饭碗,只是真的看不到前途 我们内部有个工具平台,把视觉稿丢进去就会给你自动生成html和css,但是用的人不多,因为生成classname都是规则化生成的,没有任何的语义化,不好维护。 深度用过Copilot和chatGPT后,我觉得传统前端可能会被第一个取代。 目前我们的软件设计里面的底层理念都是面向人的,帮助人更好的理解开发和维护,如果是面向AI设计呢? 传统前端的开发范式实在是太简单了,结构化也很强,静态页面、请求接口、处理数据、映射dom、交互事件绑定,做完这几步,一个页面就差不多开发完了,这些交给AI岂不是更好? ------------------继续更新(以下是看了评论之后的一些随想,与主题无关)-----------

前端VS客户端(代指Android和IOS)

早几年reactnative和weex出来的时候,客户端圈风声鹤唳,市场上散布的声音都是安卓和ios没有前途了,尽早转行,市场上ios和Android的开发的需求量会逐步减少,前端取代native指日可待。15年诞生的reactnative到现在已经快 8年了,现在1.0的版本还没有发布,而weex呢?前几年已经死掉了,诞生它的地方已经没人用了。flutter 的出现无疑又为前端取代客户端这个可笑的想法打了一个狠狠的耳光,原因也很简单,不会开发客户端,就用不好 flutter。 如果说上面一系列的变化让天平重新在前端和客户端之间平衡的话,那么国内小程序生态的风生水起让天平渐渐地向native倾斜。 现在客户端没有市场的声音已经很小了,这么多年过去大家也都明白了。前端取代客户端就是雷声大雨点小,前端能做的功能,客户端一样能做还做的更好,但是反过来客户端能做的,前端不一定能做,甚至是一些很基础的功能。放眼当下的环境,在成熟的业务里,native 就是无可替代的,前端就是个补充的存在。甚至有些成熟的场景会主动下掉相应的前端页面,例如闲鱼下掉了 h5 首页(原因不展开了,有兴趣的自己调研原因),大麦想买周杰伦,对不起只能用 native 去买,h5 不让 只聚焦在端侧曾经前端与客户端相比有三个很大的优势

  1. 热更新能力,出了问题有什么新功能不用发版全量更新,没有版本历史包袱
  2. 一码多端能力,只要有 webview 一套代码哪里都能运行,体验一致
  3. 开发周期短上手快,一个功能客户端至少要两个人Android一个ios一个,前端只要一个就够了,要是人不够,带个经验不多的新人加加班一样能搞定。

所以有心的人应该能发现,早期的 app 形态里除了首屏几个是 native 页面,其他二级页面都是打开个 webview 展示 h5。但是现在再看,大部分成熟业务 app 的主要链路功能都是用 native 承载,除了一些营销和无关紧要的功能用 h5 去承载。 这些年客户端的发展一直在补短板,动态下发组件的能力弥补了热更新的不足,几十 M 的 app 安装包装完后变成几百 M 原因就在这里。而小程序的出现让客户端去做一码多端成了可能。几个大厂里域内的 app 都接入统一的小程序 sdk,一套代码多个 App 之间都能运行体验一致,而且 native 还能对 app 做改造,为小程序提供更多的定制化 api,近一步将体验向 native 对齐。而小程序那套类 vue 语法的开发模式,对做 native 的人来说,有前端做客户端难吗? 我们的客户端团队就是靠小程序晋升了一波人,还把曾经前端嵌在里面的业务都抢走了,他们扩充了团队规模,而我们做了优化,杭州团队被干掉了,这就是现实。 回过头来看上面的三个优势,只剩下最后一个很明显了,也很悲哀,前端开发快上手容易,不怕人员更迭,新人多加班就能顶上。 回过头来看,客户端相比于前端有什么优势,不是 3 条能写完的。 前端在端侧有多大能力和性能,取决于运行的浏览器有多大能力,能获得多少性能。而客户端能有多大的能力和性能取决于用户手里的终端。 所以这么多年过去了,在端侧开发上,客户端的不可替代性在渐渐增强,而前端的优势在一点点的消耗殆尽。

哪里真的需要前端

看着评论这这两天我也在思考,哪些场景真的需要前端,让后端和客户端去学习这方面的成本非常高,几乎不可能。

  1. 大厂的中后台node业务,不可替代因为积累太重更换成本太高。
  2. 企业级的sass服务,企业级服务基本都是基于web的,而且功能相对复杂,没有几年的前端开发经验的确是做不好
  3. 基于web的重交互场景和业务,例如webgl,地图,游戏,数据可视化等等
  4. 基于web的工业化软件,例如Web版excel、photoshop等等

暂时想不到更多了,欢迎补充,不过上面这些场景可承载的前端真的真的是太少了 -----------------2022.2.22---------------

如果能重返20岁

我们每个财年结束述职汇报的时候,老板最喜欢问的问题就是,假如现在的你回到一年前,你会做什么不会做什么,哪些方面可以做的更好。 看到评论里有人在问该选择什么。这两天我也在想假如现在的我回到学生时代,我还会选择前端吗?假如我现在能重返20岁,我要如何选择? 我在学校那几年,前端毫不客气的说,几乎就是最热的,市场上几乎每一家互联网公司,不管大的小的,几乎都在歇斯底里的呐喊着我们非常需要前端。 当时B/S架构蓬勃发展,市面上几乎所有的老的C/S架构的软件都要B/S化,就像智能手机替换功能机一样。互联网公司在攻城掠地,每一片还没有被互联网化的业务都是蓝海。老板们看到前端做一个页面就能在PC、Android、IOS同时使用时兴奋不已,了解前端还能做后端时更加不能自拔,仿佛看了克敌制胜抢占市场的法宝。所有的技术资源招聘指标都在倾力的往前端倾斜,所有能用js的都去用js,一个scrum team可以没有安卓和ios,但一定不能没有前端。 当时的校招算法岗问得难,招的少,薪资还和前端没什么区别。JAVA和客户端也是类似,校招的笔试就像是计算机各门学科4年来期末考试题的大汇总,而薪资也跟前端差不多。只有前端象征性的几道计算机门类的题,剩下的全是html、js、css。 春招秋招,只有前端能拿满BAT三家的offer。我现在还清楚的记得有一个连清除浮动都搞不明白为什么的下一级的同学,他的实习offer竟然是网易,我只有深深的不可思议。。。想到过去就会感慨,倘若当时不继续读书早工作几年,会不会比现在更好?就像一位长者说的“一个人的命运,当然要靠自我奋斗,但是也要考虑到历史的行程” 潮水褪去,才知道谁在裸泳,经典永不过时。 如果能重返20岁,我会优先尝试算法方向,是的算法很难,不是每个人都能走上算法这条路,而且算法的校招到现在也是很不容易,但是优先深入算法,就如同先让自己负重前行。倘若发现不适合,那就丢掉负重,未来的路走起来会更加的步履轻盈,健步如飞。 其次就是后端和客户端方向。前端是在 B/S时代诞生的,现在越来越觉得前端可能就是时代的产物。回想到过去的 C/S时代,客户端需要专门分类出一个前端客户端来只开发用户界面和交互吗?后端和客户端都更加贴近计算机几个重要的组成部分。陷入的越深、对计算机网络、操作系统、数据库原理、数据结构就掌握的就越深,这些都是计算机的根基。 未来会怎样,没人知道,但是有些东西永远都不会变。

关于匿名

我们这个业务有几年不招校招生了,去年破天荒的招进来几个,其实也就是我曾经入坑时的招聘量。然而还不到一年,有一个新来的同学从他向我问的问题关心的事情,我能感觉到他的迷茫。这要是放到以前难以想象。 我说这些只敢匿名去说,如果有一天感觉快要被人揪出来了,我会立马清空的。这些内容不光是砸别人的饭碗,也是砸自己的饭碗,尤其是那些曾经靠着过去前端热爬上去,制定规则,跑马圈地坐收渔翁之利的人。 看着刚毕业那些新人们稚嫩的面孔,小心翼翼探索求知的语气,对未来无限遐想的畅想,说实话真的于心不忍。 年轻,就应该选择那些能看的更远,可能性更多,可以做大蛋糕的机会。而不是在前人挖的坑里,给人当牛马,用自己的青春和热血燃烧自己,温暖那些本该在寒风中逐渐枯萎的既得利益者。

跨端是谁的救赎

挖个坑有空再填吧 -----------------2023.3.24 地铁上填填坑吧----------- 跨端方向,更适合客户端去聊,我只能从前端的视角出发,基于前端的立场去谈一下我对跨端的看法,有什么不准、不对、不全的地方欢迎指正,不能坑了后人。 如果说图灵是计算机的祖师爷,每个靠计算机赏口饭吃的人,都该路过他的像前拜一拜的话。那么 Google 就是前端的开路者,Google 的一系列动作让人们发现前端,重视前端,发展前端,并且还指出了前端未来的出路。 跨端技术的发展和推进,工业界一直到现在都有着很大很强烈的诉求,客户端团队每年的KPI或ORK都有能和这个扯上关系的方向。老板们不希望做一个 app 要养三个团队,曾经的前端热一个很重要的原因就是前端低成本的跨端能力。 跨端技术在我看来是有三条线在推进的,这三条线以前端的利益视角来看,对应的就是上中下三个路线。

  • 上等路线

视角重新回到 Google,为什么刚才说 Google 是前端的开路者。因为Google做了几件十分重要的事情,极大的促进了前端的诞生和发展。

  1. 浏览器标准大一统

1990年蒂姆·伯纳斯·李在他开发的世界上第一个浏览器里,用键盘敲下WWW的时候,标志着前端有了诞生他的土壤。随后不久就进入了像春秋战国般的浏览器标准大战时代,“诸子百家”谁都不服谁,直到chrome出现,渐渐统一了浏览器的度量衡,有了统一的标准,这才使得webapp与native app 有了一战的基础 2. v8 引擎 没有V8引擎,JavaScript 仍旧只是一个 script,直到V8的出现让 JavaScript 不再是个 script 。V8极大的提升了js的性能,让webapp和nativeapp之间没有了性能的代差。 3. PWA 与 chromeOS 有了上面的铺垫,PWA和chromeOS才是 Google 为前端指明的两个方向,我也很认同这两个方向,的确是前端的光明大道。 webapp相对native缺了啥,Google 是非常明白的,所以PWA从能力方面极大的缩减了与native的差距。首屏直入、离线渲染、通知能力、后台同步、启动动画等等等等 PWA的路虽然对,但是太难了。 国内的安卓市场很大,但是国内安卓是去 Google 化的,不集成chrome,PWA没有市场和受众体,更不要提开发生态了,国内的业界和产业在PWA的路线推进和贡献上我看来几乎为0。 PWA严重依赖终端厂商的支持,IOS那边对这个看的清清楚楚,PWA普及了,AppStore还怎么坐收渔翁之利。迫于国外业界生态和用户的压力,IOS才在11版本毫不情愿遮遮掩掩的做了支持,而且还是功能极大阉割版的支持,用起来就是web快捷方式,跟native完全没法比。 至于chromeOS,如果它的市场占有率节节攀升,那应该就是前端的狂欢与盛宴了,还有谁比前端更懂 chrome? 上面这些看起来跟跨端没有什么关系,没有框架没有代码,似乎都是些很虚的东西,然而这才上等路线。Google 做完了基础铺垫之后,剩下的都在用标准用生态,去建设去推进前端的终端化。Google认为未来世界的终端,只要有一个Browser就够了,应用完全不需要什么下载安装。用什么软件,玩什么游戏,地址栏按回车就好了,立马所见即所得。他们也是这么去一步步去做的。 如果这条路线很顺利,我们前端从业者还是每天该干嘛干嘛,隔一段时间学习下新特性,不知不觉之间就会从web developer变成OS developer+any device devloper,实现“产业升级“。 所以跨端是什么,前端就是万物的端,不需要跨端。

  • 中等路线

Google的想法很美好且远大,但是工业界等不及,远水救不了进火,现在做个app要养三个完整的端侧开发团队完全不能接受。 于是FaceBook给出了方案,那就是react的virtual dom。我们前端熟知的react框架,说的准确些应该是react+react-dom框架。react是这套体系的核心,virtual dom是连接各端的中间层。按照facebook的想法,对接浏览器用react-dom,对接ios和android就用react-native,对接mac就用react-mac,以此类推,react-windows,react-linux,react-anything。 这条路线可以让前端和客户端分庭抗礼,全靠前端这套方案无法落地,需要各端去配合才行,并且即使落地也做不到完全取代客户端 然而现实是这条路接近难产。。react-native快成react-naive了,现在1.0版仍是迟迟不出,iusse积累了2k+,priority:mid的bug,最早17年的bug还没有解决。 weex的方案本质跟react的思路就是一致的。我们在weex生命的末期用weex做过一个中型应用,做几天就要跟产品说这个我们做不了,十分尴尬,能力上就是前端浏览器上面的子集。之后小程序出来的时候,第一件事就是把这个应用小程序化。 跟客户端的同学聊过,他们并不认为这个方案能走的通,这种映射标签的方式去跨端,也就弄个玩具可以,要实现真实环境的生产看不到希望。 后来weex已经不维护了,react-native还在坚持着,我真心的希望他们能坚持下去,让这条路线能够成功。

  • 下等路线

理想很丰满,现实很骨感,最终的剧本还是写向了这里。 首先是国内的厂商受不了了,前端虽然能跨端,但是能力上不能满足后面的发展需求,facebook的那套方案难产多年,仍是看不到头,PWA不适合国内的国情。于是推出了小程序这种业界毒瘤,放眼世界,只有国内有这种东西。别看他归属到前端,其实就是前端的特洛伊木马。他的出现严重割裂了Web生态,破坏了Web开放、自由的理念,极大的使前端的一码多端能力倒退。我们自己还要造个taro这种轮子,去找回曾经属于前端自己自带的能力,是不是有些可悲。 RN的难产,也让客户端们重新审视这个方案,又把放到一边的flutter重新拾了起来继续发展。flutter跟RN 不一样,一个最简单的例子。一个 RN 项目,找一个前端和一个客户端同时去做,出来的产品,老板和用户们用起来看不出来差别。但是用flutter 老板和用户就能体验出差别了,一个发热耗电严重,另一个就没有这种问题。归根原因还是前端在操作系统上没有什么积累和认知,多任务开发,并行并发的根本搞不明白,搞明白的也不知道怎么运用到实际中。 所以基于 flutter 的这一轮跨端在我看来没有前端什么事了,曾经 rn weex 的时候,客户端需要拉着前端一起搞才行。而现在的客户端没有任何带着前端一起搞的必要,我这边现在的情况也是这样。这一轮的跨端就像是客户端的自我革命与救赎,彼此都放弃了自己熟悉的语言,用新的语言去推动两端的统一。

  • 其他

这么些年前端业界在端侧方面的努力上在我看来主要有两个方向,一个是提升 UI 交互开发的效率,降低维护成本和上手难度,这方面以 MVVM 为代表。另一个是增加了渲染流程的层级,页面渲染不像过去一样拿到数据直接修改 dom 结束,还会经历许多的中间层处理最后的最后才是 dom 的修改与渲染。 而在浏览器能力的拓展上,尤其是移动端,业界没有对厂商产生升级变革的压力和提升能力的诉求。所以这么些年过去了,我们能肉眼可见的看到 chrome 的能力一点点变强,但是手机上的浏览器,除了兼容性变好了之外,曾经能做什么,现在还是只能做这些。浏览器的能力和辐射范围才是前端未来的天地。 -----------2023.2.25 03:08------------

敢问路在何方

互联网是社会的影子,赛博世界情绪的积累,最终也会影响到现实世界中的每一个人。 看着评论有不少人在焦虑,这有些违背了我的本意,生活本就很难了,再去散播焦虑没有任何意义,这只会让我们连当下的幸福都把握不住。 回答这个问题的初心是不想让年轻人走弯路,他们在最好的年龄,可以有更好选择,年轻人是最有可能创造新的赛道和领域,做大蛋糕带领人们走出内卷的人群。尤其是在当下死气沉沉,哀鸿遍野的环境里,更需要他们的朝气与创造力,而不是去卷那些暮气沉沉的八股文。 不建议去学前端,我这边主要是两条线得来的结论。一个是从我入坑以来在职场上提炼出来的几个无解问题,就像评论里有人提到的,后端客户端一样能遇到,只不过某些方面前端相对来说更加突出。第二个是用发展的思路,通过回顾过去,立足现在,去推测未来的方式,来看前端的发展。 所以我得出的认知和结论是不建议学前端。这里有个隐藏的前提,就是想要在程序员这条路上走的更远,职业生涯更长。 如果你不符合这个前提的话,我的建议就不一定适用于你,仅供参考。 这个回答到此为止后面不打算更了,之前的回答如果有不对不准不全的地方,只会对内容做更正(会体现出 diff)。 如果在评论区或者其他地方,看到有高人能够站在更高层面的视角和维度,对前端当前的现状和未来拨云见日,指点迷津的话。我会把这个放在回答的最上面,毕竟我也喜欢前端,希望他能变得更好。 最后用西游记主题曲的一句词作为结束。 敢问路在何方? 路, 在脚下