SPA的缺点是什么?不利于SEO,首屏打开速度更慢。同时,与业务模块之间的关联紧密,不好拆分。对于桌面网站,大都跑在网络环境较好的情况下,优势并不明显,而劣势却完全凸显。SSR可以部分解决问题,但是SSR性能并非最优,并且成本也不低。因此算不上最优解。而且很多桌面网站在SPA技术之前就已经搭建好了,相关的技术问题也成熟并够用,配合Gulp之类的也能很好解决工程化的问题。
SPA框架要实现得优雅,离不开现代化的API(浏览器特性或语言特性)。对此,移动端的环境比桌面端好不少,很多桌面端网站的兼容性要求的包袱大大限制了框架的应用。SPA框架的历史比绝大部分桌面网站的历史短,网站还没发展到需要被SPA革命的时候,后接手项目的开发者的重构动力还没达到非得使用SPA的程度。
国内微信和 QQ 等应用内置浏览器(至少 iOS 是这样)的毒瘤属性,如果你是用 pushState 改变的 url,那么分享出去的时候还会是最初点进去的那个 url,这就导致,如果你想让你的内容能被正确分享,不要分享出去的时候以为是 A,结果别人点开是 B,那么你至少对「具体内容页面」(比如一篇文章、一个帖子)不能采用框架内部路由,而只能用最原始的 href 改变 url。很多网站没有做成SPA并不是技术原因,而大多数是业务划分和遗留代码的问题。
很多网站不同的业务或者产品对应不同的业务和开发部门,因此他们会独立开发自己业务的网页(目前基本上都选择SPA了),然后再去和主站集成,这里“集成”一般都会直接在主站添加入口链接。有时候选择多页面模式也是刻意为之,如果业务复杂多样,在一个SPA上加载太多东西势必会影响网站性能,将不同业务做成多个SPA,对用户体验影响并不大,但是会简化业务的独立开发、部署和维护。
另外就是遗留代码的问题。前端技术更新太快,一般新成立的项目都会选择使用新的框架语言,遗留代码都是旧的技术问题,如果想要做成SPA,那意味要在一个页面加载多个框架,必然会影响性能,因此会选择多页面,然后再做旧页面到新页面的迁移。
目前比较多被提及的前端微服务化,是希望多个前端服务能够整合到一个SPA上,但是由于技术问题目前还是有局限。网站设计的相关东西都是不断更新的,如果出现一些新的东西也有可能没有那么快适用,所以还要选择合适的。
本文地址://hailanjianghuncun.com//article/2442.html