你是拿锤子的前端开发吗?
前言 接上篇《说道说道前后端分离》今天再次对前端现状作一次分析(吐槽)。
再次引用一句《穷查理宝典》中的理论:
在手里拿着锤子的人看来,所有的东西都会是钉子。
因为有锤子的关系,遇到任何问题,都会先想如何用锤子解决。久而久之,陷入了一种思维定式。任何工具带来便利的同时,也带来了局限性。而这往往是用锤子的人很难看到的。
事出有因 这种现状在开发圈内决不少见,不仅限于前端。本文只说说前端的现状,原因是笔者最近在工作中遇到一个棘手的问题:性能优化。
最近接手了多个现有的前端项目,是公司比较核心的移动端官网,作为门户网站访问量和用户量都比较大,但是随着项目的迭代出现了性能问题,页面加载速度在WiFi网络下达到3s,3G网络15s以上,更差的网络40s+。加载的资源小则3M,大则6M。如果一切往好处想,假设所有用户使用最好的网络,用户和公司都不在乎流量费,两三秒的加载速度也还挺快的,每次打开页面费个3M流量也不是个事。但如果考虑这些问题的话就会发现这不是小问题。
对以上问题分析得出结论之一:资源过大,有兴趣的可以打开淘宝网看下首屏资源做下对比,可以看到资源不超过3M,时间不超过2s。
而我们一个移动端网站的资源居然能超过3M,究其原因:
图片大 js大 css大 图片大是因为图片基本没任何大小控制,都是使用了最高标准原图。js和css大基本是属于架构问题,一个项目中包含的上百的页面每个页面600多k的js是绕不过去的(vendor.js,app.js等打包资源,不包含其他引入资源)。
看到vendor.js,app.js这两个名称很多人应该想到了,这是vue(react)框架开发的网站。 是的,就是用vue开发的移动端网站,使用vue开发网站本身也不是什么大问题,毕竟有实力的公司不需要SEO,直接竞价排名就行。而我要说的问题是,不是什么网站都可以用vue来开发,不信请继续往下看。
问题分析 我司的移动端网站作用并不仅仅是用来展示公司形象的,更重要的是用户转化的,就是让用户注册的。而且是要和很多第三方机构合作投放引流,经常需要分析页面UI的不同对转化率的影响,所以需要的页面不是几个,而是几十上百个,还在不停增加,每周都有三五个页面增加。 由于vue主要是以开发单页SPA应用为主的,在开发人员不考虑真实需求的情况下自然会使用流行的技术,最终把网站开发成一个单页应用。单页应用的特点就是单页,就是把不同的页面做成一个页面一次加载,加载完成后页面之间的切换就会很快,一般无需再加载资源,用户体验也会好很多,可以套用一句话:“一次等待,处处快速”。
这个特点在管理后台项目中很合适,但是在只需要展示一次的项目中也合适吗?不合适。
我们的网站项目是用来做很多落地页的,各个落地页之间没有关联性,不会A页面跳到B页面,从B页面跳到C页面,A页面中不需要B页面的资源,B页面也不需要C页面的资源。然而vue项目打包的时候会把每个页面独有的一些资源都融合在一起,形成公共资源。结果就显而易见了,一个页面总要加载一堆无关资源,不仅资源大,还有很长的白屏时间,用户体验下降。
还有一点不该使用单页应用的原因是我们的页面是纯展示的页面,不需要很多数据交互,vue能起到什么作用?操作数据?驱动UI?模块化?通通不需要。现代html可以不借助第三方库和框架的情况下完全能实现。
结论 JavaScript 的最大优势之一是它不需要编译,所以可以在浏览器中直接运行。这样你就可以立刻获得编码的反馈。入门门槛很低;你只需一个文本编辑器和一个浏览器就能编写软件了。 不幸的是,这种简单性和可访问性已被称为过度工具链的风气破坏了。这种风气已经将 JavaScript 的开发工作变成了一场噩梦。我甚至看过一整套关于配置 Webpack 的课程。这种乱象需要有个尽头——生命苦短啊。
VUE,React这类框架用于构建应用方面很合适,但不太适合构建网站。应用是需要有较多的UI和数据方面的交互,而网站则更多的是信息展示,你可能根本不需要JavaScript(框架)。
追求新技术可以让我们获得新奇感,成就感,解决老问题,而不是带来新问题。复杂性才是造成软件问题的根本原因。——试问:离开框架的你还会开发网站吗?