轻量级前端框架在提升开发效率与用户体验中的重要作用
1006
2022-08-06
web前端工程师在移动互联网时代里的地位问题(移动互联网应用开发工程师)
支付宝十周年推出了一个新产品:支付宝的十年账单,我也赶个时髦查看了一下我的支付宝十年账单,哎,感慨自己真是太屌丝了,不过这只是说明我使用淘宝少了,当我大规模网上购物时候,我很讨厌慢速的快递,所以我大部分消费都贡献给了像京东这样具有火箭般快递速度的电子商城了。不过在支付宝十年账单里,有个统计数据引起了我的危机意识,在中国一些偏远或者是经济欠发达的省份,电子购物在居民的全部消费里的占比比发达地区高多了,而这个的助推剂居然是移动互联网在中国的普及,在中国使用智能手机和平板电脑购物的人们已经远超使用PC电脑的人们,这点不管是经济欠发达地区还是经济发达地区都是如此,而且全世界移动互联网发展最好的国家就是中国,这点连美国都不如。
我最近一段时间又把精力放在了web前端技术的研究上,本来打算这个周末再接着这个主题写几篇文章,但是看到支付宝的统计数据,一种末日般的危机感悠然而生,我是不是在研究一个即将过时,就算不是过时,是不是已经快到发展瓶颈的技术呢?我如果不做改变,会不会在不久的时间后,我的web前端技术会丧失优势呢?因此我今天想要分析下移动互联网对web前端技术的影响。
在移动互联网出现之前,互联网系统都是建立在Browser/Server的架构之上,即我们常说的B/S架构,B/S架构其实是Client/Server即C/S架构的一个子集,而到了移动互联网时代,大部分的传统互联网产品都需要我们去安装一个APP即一个客户端才能使用,这个客户端相当于PC电脑上的桌面软件,而每个客户端都是某家公司专门为自己定制的,移动互联网的web应用蜕变成了一个标准的C/S架构。说心里话这个现象的转变让我很诧异,传统的PC也是可以装客户端,为啥C/S系统在PC端没有流行起来,却在移动互联网下流行了起来,更诧异的是,移动设备和个人电脑一样也都是默认装有一个免费的浏览器,为啥移动端的浏览器在很多应用里都是靠边站,人们更加倾向于先麻烦自己一下,-安装个客户端APP呢?
我今天和一位正在做移动互联网开发的朋友聊了下天,我提出了自己的疑问,在一系列扯蛋以后,我似乎有了上面问题的部分答案,我总结了下,大致如下:
1、移动设备上网虽然可以使用WiFi,但是很多人在所谓关键时刻使用移动设备上网时候都是在2G、3G、4G移动网络下进行的,一般情况下这些网络的速度和一般宽带相比还是太慢,更重要的是这些网络的资费要贵的多,很多人一个月使用这些网络上网的资费比宽带贵很多,但是享受的流量却常常不足一般宽带的10%,在使用移动网络的背景下移动端的B/S网站往往会加载很慢,流量消耗很大,不管是用户体验还是经济效率考虑都会影响商家产品的竞争力,所以商家需要一种手段改进这种局面。
2、移动设备本身的CPU、内存以及存储设备和PC电脑相比,差距还是很大,同样的一个应用在PC电脑上处理假如需要10毫秒,换到移动设备上可能会需要几倍的处理时间,而互联网上的应用响应时间太慢会导致大量客户的丢失,商家为了让自己应用响应更快,自然就会考虑自己定制客户端,这个客户端会根据移动设备特点做相应的性能优化,使应用的响应速度更快。
3、移动设备本身的安全机制没有PC电脑成熟和完善,移动端的浏览器和PC电脑的浏览器相比,就如同一部简配阉割的汽车,它远远没有PC电脑上的浏览器那么强大,特别是一些浏览器的安全机制,移动端浏览器是远不如PC端浏览器,这点在智能手机上非常明显,例如我们在PC电脑上购物,到了支付环节,不管支付工具使用的是各家银行的网银还是第三方支付系统,都会在输入银行卡密码,信用卡CVN2时候使用密码控件(密码控件解释:我们使用网银时候如果不安装密码控件,密码输入框上会提示我们-密码控件,等控件安装好了后,文本输入框就会显示出来,其实这时候的密码输入框已经不是传统html里的input密码输入框了,而是使用像C这样的语言编写的浏览器插件模拟的密码输入框,我们在这样的密码框里填写密码是非常安全,基本上很难被人截获),密码控件会保证关键的密码信息的安全,但是这点到了移动端浏览器就很难做到,我们基本很少见到在手机浏览器里提示我们安装密码控件的现象,就算有,浏览器也会调出相应的APP帮助我们完成支付操作,究其根本原因还是移动设备浏览器对这类技术支持不够。
4、在浏览器里开发一套漂亮、用户体验好、安全的网站还是很有难度的,不过技术难度都是内部问题,对外都不是问题,问题的关键是分辨率的问题,移动设备屏幕有大有小,这种差异和PC电脑相比简直是恐怖,而浏览器的布局技术往往又是跟分辨率有着千丝万缕的关系,其中最致命的一个问题就是有的移动设备的屏幕大点,它也许可以在一行里显示出三个元素,但是到了一个屏幕小的手机上一行显示三个元素就会使得页面严重变形,而浏览器的排版技术行row是一个基本边界,元素如果碰到换行显示就会打乱整个布局系统,所以在移动端浏览器开发一个能适应所有浏览器的网页难度非常之高。此外能在PC电脑上显示的网页也许可以适应像pad上的浏览器,但是到了智能手机上,这个网页就不得不重新开发,重新开发倒无所谓,最要命的是就算重新开发,小屏幕的网页很难囊括原来PC浏览器网页所有功能,这和移动浏览器功能和屏幕太小所致,这样的结果会导致商户很难将用户引流到移动端,从而丧失了移动互联网的先机。
5、浏览器的布局技术在移动端浏览器技术普及上的作用是很关键的,在PC上开发网页我们常把布局技术称之为html+css技术,其实在网页排版里图片的作用是非常重要,而针对互联网的web网站上图片的份额更加多,而且常常会及时更新,图片对于网络流量昂贵的移动网络而言就是人民币,而浏览器是个公共的平台,虽然我们有很多技术手段可以让很多图片缓存起来,但是平时运用里重复加载图片还是家常便饭,而这样的流量消耗就是在浪费人民币,这点也同样会成为企业竞争的一个砝码,所以使用APP会对老百姓更加实惠,也能让商家表达更多对用户的体贴。
6、移动设备由于屏幕较小,因此制作APP界面设计的复杂度比传统PC电脑要小,这其实降低了一定的开发难度,而且APP开发的界面效果还是比浏览器界面要好。此外桌面软件开发天然就是响应式驱动,交互性比网页更好,而且开发响应式应用的难度更低,所以使用APP开发的应用比传统网页更加吸引人。
由以上6点我们可以知道了,用户在移动设备上忽视浏览器的原因还是移动浏览器的给予用户的产品没有APP好,孰好孰坏老百姓的心里都是雪亮雪亮的,老百姓是很聪明的,忽悠不到他们的。
在中国移动互联网发展迅速,甚至已经开始挤压PC端浏览器的份额,而移动设备是广大用户的首选,那么这是不是说明web前端技术到了移动互联网领域就会没落了?为了说明这个问题,我想谈谈为啥在PC电脑上我们会选择浏览器开发商家应用,而不是为商家专门开发个客户端软件呢?很多人说这点是商家出于成本考虑推动的,因为世界上操作系统很多,如果要做客户端就得要为每个操作系统开发一个客户端,就算是同一个操作系统,系统升级后客户端就得有相应的更新,就算操作系统没有升级,出于安全考虑很多客户端也会经常升级,而浏览器则不同,开发一套网站就可以打遍天下无敌手,可以不用自己考虑客户端升级的问题,其实用户怕麻烦本性也帮助了这个潮流的发展。那么这个理由在移动互联网里还有效吗?
我们看到的现象得到的答案似乎是无效的,因为移动互联网下浏览器已经没落了,更多人会选择APP而非移动设备的浏览器,但是PC端浏览器大行其道的理由放到移动设备上,仔细掂量下还是很有市场的。
当今世界智能手机和平板电脑上流行两大操作系统:苹果公司的IOS和谷歌的android,虽然Android是一个独立的操作系统,但是到了各个具体手机生产厂商,其手机上所使用android都会被或多或少的改写,甚至有的公司能将其改的面目全非,在移动设备上操作系统的差异处理问题比PC操作系统要严重的多,毕竟个人PC电脑上微软的windows操作系统还是一家独大,我们只要满足了windows的客户端,至少在中国就能满足90%以上的用户需求了。APP就和PC电脑上的桌面软件一样,开发它需要调用大量的操作系统底层API,所以我们想让自己的应用覆盖到大多数用户就不得不为每个操作系统建立一个团队,而这些团队开发同样的业务功能,只不过是使用的技术不同而已,结果会使得一个业务系统拥有多个不同版本,造成了人为的系统异构性,这种异构对系统的运维也产生了很大的影响,不同的系统运维需要彼此独立的运维团队,这样就增加了企业的成本压力。
移动设备并没有抛弃浏览器,浏览器的html、css以及javascript技术不管是那种移动操作系统上都是高度的一致,这种一致性甚至超过了PC电脑上不同厂商浏览器(移动浏览器基本都是webkit内核)的一致性,通过浏览器相关的开发技术消除平台的差异在移动端任然是可取的,而且现实中移动端的平台差异性问题的严重程度其实已经远远超出了PC平台,其对公司造成的成本压力也是不可言喻的,但是移动设备上浏览器的局限性是一个很难跨越的鸿沟,那我们有办法解决这个问题,答案还真有,移动端操作系统将浏览器底层的接口都做成了API,我们很容易将APP和浏览器技术结合在一起,因此时下出现了phoneGap技术,phoneGap技术核心就是解决不同移动操作系统的差异性,使用phoneGap的技术人员可以很少去考虑操作系统的兼容性问题,而只用关心浏览器技术就可以开发出一套在IOS和android都能正常运行的APP,这套技术对于刚刚创业的小规模的互联网公司非常有现实意义,可惜为了兼容不同操作系统,却牺牲了应用的性能。
对于有实力的大公司又该如何选择了,大公司的成本压力会比小公司小很多,但是高企的成本也是一种潜在的风险,大公司面对这样的问题,好的解决方案应该是减少重复性劳动,减轻运维压力,其实时下大部分的APP都相当于一个自制的浏览器,只不过这个浏览器是带有公司自有的业务,因此大公司的做法应该是将APP开发和浏览器开发分离开来,APP开发主要职责是做个框架,不过这个框架相当于新开发个浏览器,这点和java里SSH框架有一定区别,而业务开发人员可以只关心浏览器开发技术,用浏览器技术完成业务开发,至于到了业务运行阶段,主要是业务开发人员的事情,这样就避免了建立重复开发的技术人员团队同时也达到了专业的人做专业的事情,运维也变得简单多了,系统稳定性和健壮性也增强了,还有个最关键的好处那就是可以复用原来的客户端开发的技术人员,这是减轻人力成本的一个重要手段。
由此说来,web前端在移动互联网领域并没有没落,而且移动互联网会给web前端带来大发展的机遇。
在移动互联网时代web前端技术会变得越来越重要,比以前任何时候都要重要。但是移动互联网对web前端开发带来了一个弊病,这个弊病就是web前端技术或许会变得越来越复杂。
首先不管哪个移动端操作系统,浏览器的内核技术达到了前所未有的统一即大部分都是使用webkit内核,由于移动互联网没有pc电脑的历史负担,移动端的浏览器一开始就支持了最新的html5,html5是颠覆性的技术,传统的web前端开发人员要重新学习很多新的知识才能掌握它。
Html5技术提升了浏览器做富客户端开发的能力,这种提升不是量的变化而是质的变化,html5让web前端在整个web应用里的作用提升到了前所未有的高度,富客户端将会更加富有,我们在移动互联网里开发web前端不能在那么随意了,而是需要将web前端技术更加框架化和工程化,那么javascriptMVC技术会应用更加广泛,web前后端分离技术也将更加被人重视,到时如果有人再说web前端技术是一个玩具技术,那么这人就等于还生活在互联网的原始社会了。
移动互联网对web前端技术影响或许还会导致一个新的职业方向的出现,这个方向就是客户端工程师,虽然移动互联网发展迅速,但是移动互联网想完全取代PC电脑,这种想法还是非常不现实的,所以在很长时间里传统的互联网和移动互联网会并行发展,只不过我们再去做互联网系统客户端这块开发不仅只要求满足PC浏览器了,也许公司希望能找到一个能帮忙解决所有客户端的工程师,当然这种客户端工程师应该会站在web前端技术之上来消除不过客户端的差异性,不过到了解决移动互联网客户端问题时候,客户端工程师或多或少都要了解到不同操作系统APP开发技术的细节,当web前端工程师进化为客户端工程师后,对那种web前端工程师和美工等同的偏见估计会更加没有市场,新型的客户端工程师需要掌握的技术门类更多,技术会更加全面,在加以富客户端在web应用的重要度提升,客户端工程师也许在整个互联网行业会更加吃香。
移动互联网的大发展导致当今这个时代做一个大型网站的成本越来越高了,因为我们不得不去满足更多的客户端。回到传统的PC浏览器技术,作为一名前端工程师我也感受到最近几年传统的PC浏览器技术也在以前所未有的速度发展,就连恶心的微软公司开发的ie浏览器也在发生着巨大的变化,版本发布更加频繁了。html5刚出来时候有很多朋友说这个东西不知道猴年马月会流行,不要做深入学习了,这个说法发生在两年前,但是时下html5技术开始以前所未有的速度普及,很多人可能认为这是浏览器厂商的驱动的,但是我确认为根本原因还是移动互联网上html5的普及间接影响到了PC浏览器的发展,移动互联网的普及挤压了传统PC电脑的部分生存空间,迫使那些原来依仗自己垄断地位不愿改变的厂商发生了变化。
移动互联网的普及对互联网服务端系统架构也会产生很大的影响,对于这个影响的思考还是源自于有一天和一个即将毕业的大学生的聊天,那天他问我自己到底是做web前端开发还是做移动开发好,当时我们简单聊了下两种技术的差异,他觉得客户端技术之间的差异太大,更新太快,他似乎对这种不可控性感到有点害怕,如是他又问我:移动端对应的服务端技术和PC浏览器所对应的服务端技术是不是一样的,我的回答当然是一样的,所以最后他觉得自己还是从事服务端开发比较好。
当我写这篇文章时候让我想起了这次聊天,我有个很大的疑问那就是客户端的不同会对服务端的技术实现产生影响吗?把这个疑问放的再大点,客户端的不同会对我们整个web系统架构,不管是web前端架构还是web服务端架构会产生重大影响吗?
我前面说到最棒的APP应该是APP技术和浏览器技术结合,但是APP和服务端的数据交互真的可以全部有浏览器技术完成吗?如果某些请求不得不用socket完成,那么这种交互模式就和传统PC的web的服务端发生了变化,假如这种情况很多,那么我们就不得不单独开发一套针对移动端的服务端程序。就算上面的问题不是问题,小屏幕和大屏幕所能容纳的信息量是不同的,在PC上有些交互一个http请求就可以完成,但是到了移动端可能不得不拆分成多个请求协同完成,这样的差异也会导致PC端的服务端不能复用,如果这样的差异很大,我们还是不得不重新开发一套服务端,这么说来就算服务端技术线路一致,例如都是使用我十分擅长的java,但现实我们还是不得不做很多重复劳动,如果没有移动互联网时候,领导让我们开发一个新网站给我们两个月时间就能完成,那么现在开发一个新网站,人力资源不变的前提下,两个月我们能完成任务吗?到时这样的结果一定是老板和员工一起痛苦了。假如我们真的为不同客户端对应开发一套新的服务端程序,这做法就好比洪水来了我们赶紧修河堤,洪水越大,我们的河堤就做的越高,最后大河成了天河,那天河堤出了点纰漏很有可能大堤溃坝,后果非常严重,治理洪水最好的解决方案应该是我们如何疏导洪水,那么在软件领域这种疏导最后是重新审视我们网站系统的整体架构,在架构设计层面就考虑到方方面面,从架构上重构系统往往会达到事半功倍的效果。
其实从服务端角度而言,按MVC架构思想考虑,客户端不同影响到的是V层和C层即视图层和控制层,对于服务端而言就是控制层了,那么要减轻服务端改造压力,我们必须要将服务端的控制层和模型层解耦的更加彻底,最好的方式就是采用分布式技术,控制层和模型层变成两个独立的系统,两个系统通讯就采用我以前讲到的高效远程调用的方式,远程调用使用起来和本地调用差不多,这样也减轻了服务端技术变迁的压力。服务端的控制层和客户端的关系太过密切,虽然控制层听起来很高大上,但在做开发时候控制层的发言权实在是小的可怜,所以这里我想先讲讲视图层即客户端的改变,不管移动端是怎样的APP,也不管开发移动APP的技术有多好,我相信移动端的APP一定是一个强有力的富客户端,这点到了PC上的浏览器客户端就有很大的不同,虽然当今ajax技术深入人心,但是想在pc浏览器上写出强大的富客户端是有一定难度的,而且现实下很多pc浏览器端的程序都是非常不健壮和书写随意,这主要web前端技术精通门槛较高,还有大量小公司对web前端技术的重视度不够所致,这样的现状就更不要说让自己的web前端达到javascriptMVC的程度,所以我觉得我们要对pc浏览器端的程序进行重构,将pc端的前端做成javascriptMVC模式,那么javascriptMVC的客户端就变成了SOA里的一个服务了,它和控制层的交互就可以像SOA架构里不同系统调用那样,定义好服务接口报文格式即可,这种做法也非常适合APP,因为APP开发时候也只是在需要服务端数据时候才会交互,而大部分页面展示都可以在客户端本地完成,例如我们可以让所有的服务端数据交互都已json格式进行,那么如果客户端请求数据有变化我们顶多就是增加个新接口就行,PC端能被复用到移动端的接口还是可以照用不误。
我相信web前端技术不会没落的,它只会越来越重要,如果有一天互联网开发里真的出现了客户端工程师,那也是web前端技术的升华,web前端会越来越专业,要求的技能会越来越高,记得我4年前我打算往web前端发展时候,我曾经碰到很多技术难题,当我找到解答时候发现很多解答却带来了更多疑问,疑问源自解答里依赖于浏览器内核的解释,如是我在一些技术群里询问相关浏览器内核的资料,某个群里有位朋友跟我这么说研究浏览器内核有啥用,那是老美做的事情,在中国研究这个一点前途都没有,只要会用就行了,“不要没事找抽,自找麻烦”,引号差不多是原话了,而前不久我在京东上买到一本讲解webkit内核的书籍,为了以后看懂他,我最近一段时间重温了很多web前端的技术,看看现在的招聘,很多公司都开始大规模招聘了解浏览器内核的人才,这件事情让我有点感慨,学习虽然最终都是为了达到某种功利心,但是要学好东西,一定得要报着解决自己疑问的目的,不畏艰险,而不要过多去考虑现在这个有用如否。
好了,文章写毕,祝大家晚安。
版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。
发表评论
暂时没有评论,来抢沙发吧~