前端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，带来了更好的性能提升。
这一路走来，前端的结构变得越来越复杂，但性能却并没有越来越差，在大型网站项目中，反而性能得到了提升。因为复杂项目中，难以维护的杂乱代码带来的性能损耗，有可能超过层级结构比较深所带来的损失。
结构化与性能的取舍，在实际开发中，如何进行呢？
实际开发中，其实是在大环境中的一个缩影。
在当前的前端开发技术背景下。结构化的问题往往交给框架来解决，项目结构化问题应按需求来构建。
- 如开发大型项目，则应首先对性能有所预期。性能要求低的部分可以采用通用框架，性能要求高的部分，可以采用更极端的技术方案。
- 如开发小型项目，则应在框架选择上有所取舍，舍弃复杂的架构往往更节约资源。
最后，如果在开发项目过程中，遇到了绕不开的性能问题，我的解决思路如下，可供借鉴：
- 首先，如果是代码质量问题导致的性能问题，应先优化代码质量。将问题从性能与架构的冲突，变为性能与编码能力的冲突。
- 如确实因架构导致的性能问题被识别出来以后，应首先考虑这样的性能需求是否应由前端来保证，是否可以由服务端辅助完成，或者业务是否设计合理。
- 最后，如以上两点还不能解决问题，那么在有限的范围内，可以采用其他框架或方案来解决原框架的性能瓶颈，或者可以期待下一次的项目升级与重构了。
总结
结构化与性能本身并不是完全对立冲突的两个方面。虽然他们二者互相影响，但随着个人计算机软硬件升级、v8引擎带来的性能提升，以及MVVM框架的日趋成熟，结构化代码组织如今越来越远离web开发的性能瓶颈区。
但不幸的是，性能问题还将在可预见的未来内，始终如影随形的伴随着每一位开发者。
