前端框架的性能什么的真的有意义吗？

前端对性能要求的场景在实际项目中，见的少。但是代码不就追求这样么

那是你没写过复杂项目。。。

自从各种 mvvm 开始用性能就已经扔一边去了
正常的前端应用还主要在渲染上 少刷新 dom 少放东西就是王道
包括大数据图表都可以通过抽点解决问题 大列表也可以假拖动
真的出性能问题 游戏的话都上引擎做 app 了 可能视频类带特效弹幕是最容易出性能问题吧

@chairuosen 所以复杂到有性能瓶颈的项目都是什么样的

话说 Google 为了解决 Gmail 的性能瓶颈，搞出了 v8 …

遇不到

追求性能的不会用框架，特别是 mvvm，完全和性能背道而驰的设计理念

@dorentus #5 这个说法的根据是啥？从逻辑思考这个想法不是很站得住脚，即使 Google 自己的 Javascript 引擎解决了 Gmail 的性能问题，如果 Gmail 自己不改善代码，它在其他的浏览器上的性能也没有保障但是 Gmail 网页版本来就是要让所有的人都能轻松访问 Gmail，如果限制在 Google 的浏览器上，何不推出 Google 自己的客户端来访问（反正，都是 Google 的软件，不差这一个）？

@feverzsj mvvm 和性能背道而驰是因为频繁操作 DOM，很多 mvvm 框架都优化过其操作 DOM 的频次和范围，并不是主要的性能问题。

图表数据可视化方面的需求是性能重灾区，而图表本身的复杂度也导致许多中小公司开发人员依赖前端框架，那么框架性能问题就有意义了。

当遇上超大数据量的滚动 table，左滚右滚的那种。
当遇上大数据量的图表展示，还特么的五彩斑斓还会动的那种。


当遇上
$(xxx).css();
$(xxx).html();
$(xxx).data(xx, yyyy);
$(xxx).on(click, func1);
$(xxx).on(click, func2);
打死不缓存系列这种。

@luoway batch insert 了解下 模板渲染插入一气呵成，但是 mvvm 你每个节点都要绑定又蜕化成一个一个插入的年代

除了吹没什么卵用

还有说操作 DOM 是浪费渲染时间开销大什么的，来来来，你说一个不操作 DOM 的办法

还有说 JQ 操作 DOM 性能差，那也只能呵呵了，性能差换电脑啊

还有说渲染大数据列表慢，这个慢相对于服务器响应和网络传输，基本忽略不计，是微服务查询发送 10w 条数据慢还是渲染 10w 个 dom 慢心里没点 B 数么

还有说用 mvvm 操作数据绑定 dom 快，什么虚拟 dom 缓存什么的，缓存确实可以提高一下效率，但是，你把 JS 执行的时间和消耗的内存算上去，和原生操作 dom 对比一下，谁快谁慢还不一定呢

前端谈性能是没啥意义的，因为可以从设计层面规避性能问题，比如渲染 1000w 列表，而且很多东西都不能控制，比如 dom 的渲染层级，浏览器的缓存等，虽然很多大佬甚至各种框架都在谈渲染效率，但那也只是作为一个参数看看就行，不止前端，包括所有客户端的执行效率都是和配置相关，代码提升效率只是次要的，虽然有黑科技提高效率，但是依然不能把 1FPS 的吃鸡提升到 60FPS

@whypool
> 包括所有客户端的执行效率都是和配置相关
那你觉得安卓淘宝、支付宝那么卡，是因为接口慢吗？

@luoway 那是因为你启动的不是淘宝或者支付宝，是阿里的全家桶以及所有能跟支付宝沾边的东西

框架渲染效率提高，最大的受益者不是用户，而是前端开发，渲染效率提高了意味着你那坨屎一样的代码不用专门优化速度也不会太慢。

其实大家说来说去都不是重点，我来说点关键的：浪费的是用户的电和时间，所以开发者和公司不在乎

@whypool 操作 DOM 说的是频繁操作会有性能问题

列表那里，是大量数据会导致卡，不是慢

@murmur 原来如此。这说明客户端是可以做到性能负优化的。

卡就换电脑啊

对实现需求和开发效率的要求比性能高太多了

@autoxbc 跟挖矿比浪费电？

牺牲运行效率换开发效率不是所有编程技术的发展么？付出一点运行效率用 Web 跨平台我觉得是个很值得的 trade-off。框架再怎么优化都是有上限的，追求的其实是让一般的程序员写出比自己手写稍微强一点的代码就行了。