[
"user":{
"id": xx,
"provinceList": [
{
"id": "1",
"resource": xx
}
]
}
]
有一个汇总界面,后台API输出如上的JSON结构,需要遍历user/provinceList下的resource按省份进行汇总,前端已经有了计算逻辑了。 现在需要把这个界面的功能搬到子系统首页,前端不干了,说是计算会阻塞主线程,导致首页加载慢。 按照我的理解,会阻塞主线程的操作只会出现在超大规模的运算和频繁的DOM操作上。大家随便开个控制台试一下,10000000次的循环加法只需要10ms左右,而这次循环数据量不超过1000次,这样就影响宝贵的前端加载时间了? 争论了很久,到最后谁也没说服谁,最后前端还是妥协了,说是放到异步计算。我对前端不精通,着实没搞懂,这样的计算还需要异步进行?而且这样的计算还能异步进行? 简直大开眼界!!
以 cpu-profiler 数据说话最好了。
不是很明白,前端已经有了计算逻辑了,就是原本就在前端做的, 现在搬到子系统首页,还是在前端做的, 都在前端,争什么?
@captainblue2013 因为“首页要加载得足够快”!!!我简直要疯了,差一点我就被逼着把前端的计算代码全部copy到后台了
跑 profile 啊 还有,不要在控制台跑,控制台没有开 jit,相当于 eval 的效率
拿数据说话,否则两个人都得被气死0 0
@scheshan “首页要加载得足够快” 每次听到这句话,我都不想跟产品,技术讨论下去了,莫名的想发火。。
是前端觉得 groupBy 的算法写得不够好么?
可能有强迫症。
就是那种前端只负责展示,只要现成的数据。
应该没那么费时吧 费时可以后端做 也可以开webworker做 具体看一下 cpu-profiler
计算效率是差 ,不过就一般前端的计算量,差也没什么明显感觉
本质上两个人都想偷懒,我会让服务端的写。职责分清。一个人写了一个内部系统在用。有点感悟。 数据逻辑后端做,交互逻辑前端做 这是最好的。 前端可以做但是不做 , 把一些逻辑放后端复用性更好。
JS是单线程的,栈被计算填满就没有时间执行其他东西,但这点计算真的算不了什么 ,不要把DOM操作放进遍历循环就行了。