前端js,如何在结构化与性能中做取舍。

js发展中的问题

随着前端web技术的发展,js要解决的问题也变得越来越多,越来越复杂。
解决更复杂的问题,需要更好的结构。 解决更复杂的问题,也需要更好的性能。
结构的优化在一定程度上会牺牲性能,同样的,性能的优化也有可能会破坏原有的结构。

一般化的例子

我们先来看看以前这些问题是如何(被)解决(妥协)的。

jquery vs 原生api

回到10年前,精通jquery是前端程序员的一个里程碑,没有人执着于原生api。原生api有更好的性能,jquery有更好的结构。但问题在于开发效率的提升,兼容性的提升,jquery结构化的收益大大超过了其对性能的一点点浪费。

再来看angular1 vs jquery

回到5年前,面试最喜欢问,你知道什么是脏值检测么?angular不仅带来了更复杂的结构,而且带来了更难理解的开发模式。但出乎意外的,jquery败下阵来。
angular的性能更差,兼容性也不如沉淀了多年的jquery。 可是,angular胜在了面对复杂问题时的解决能力、维护支出与开发速度。5年前,互联网正处于高速发展中,大型项目增长迅速,对开发资源的需求达到了顶峰。时间就是金钱,高效率就是时间。

react(vue) vs angular1

再来看两年前这场pk,随着MVVM的框架日渐成熟,angular1败下阵来。react借鉴了angular1的思想,vue同时借鉴了react和angular1的思想。jsx等模板语法带来了开发效率的提升。grunt,gulp,webpack等工具带来了工程化能力的提升。es6的逐步成熟也给开发者带来了更多的效率。这些都使前端的结构更加的复杂。但别忘了虚拟dom,带来了更好的性能提升。

这一路走来,前端的结构变得越来越复杂,但性能却并没有越来越差,在大型网站项目中,反而性能得到了提升。因为复杂项目中,难以维护的杂乱代码带来的性能损耗,有可能超过层级结构比较深所带来的损失。

结构化与性能的取舍,在实际开发中,如何进行呢?

实际开发中,其实是在大环境中的一个缩影。
在当前的前端开发技术背景下。结构化的问题往往交给框架来解决,项目结构化问题应按需求来构建。

  1. 如开发大型项目,则应首先对性能有所预期。性能要求低的部分可以采用通用框架,性能要求高的部分,可以采用更极端的技术方案。
  2. 如开发小型项目,则应在框架选择上有所取舍,舍弃复杂的架构往往更节约资源。

最后,如果在开发项目过程中,遇到了绕不开的性能问题,我的解决思路如下,可供借鉴:

  1. 首先,如果是代码质量问题导致的性能问题,应先优化代码质量。将问题从性能与架构的冲突,变为性能与编码能力的冲突。
  2. 如确实因架构导致的性能问题被识别出来以后,应首先考虑这样的性能需求是否应由前端来保证,是否可以由服务端辅助完成,或者业务是否设计合理。
  3. 最后,如以上两点还不能解决问题,那么在有限的范围内,可以采用其他框架或方案来解决原框架的性能瓶颈,或者可以期待下一次的项目升级与重构了。

总结

结构化与性能本身并不是完全对立冲突的两个方面。虽然他们二者互相影响,但随着个人计算机软硬件升级、v8引擎带来的性能提升,以及MVVM框架的日趋成熟,结构化代码组织如今越来越远离web开发的性能瓶颈区。
但不幸的是,性能问题还将在可预见的未来内,始终如影随形的伴随着每一位开发者。

上一篇:XHTML结构化


下一篇:ElasticSearch 5学习(10)——结构化查询(包括新特性)