关于前端布局嵌套一些疑惑。

[whyrookie]

最近断断续续学习一些前端知识，在看一些视频，里面的老师写页面的时候似乎很少强调减少布局的嵌套，自己一直都是写 Android 项目，对于布局的多层嵌套特别敏感，为了提升一些性能，想尽办法减少布局嵌套。是否是因为前端这块布局嵌套对性能影响比较小？

[crazyweeds]

你可以用 react 的 chrome 插件看下阿里云效的嵌套层数，应该有 50 层吧，也有人说嵌套尽量别超过 10 层。
所以，我感觉优先代码可维护性即可。

[flyqie]

Android 跟浏览器在性能上的优化点是不一样的。。

况且现代化的 JS 前端框架都会对布局嵌套这边做某些优化。

[superedlimited]

Android 必须减少嵌套，所以才会出现 constraint layout ，但是现在的 compose 似乎和前端一样，不用强调减少嵌套了。

[lisongeee]

曾经做过微博 Android 客户端的无障碍节点查询，当时用的 forEach + 递归 遍历树，直接爆栈了
查了一下发现最深的节点是 104 层，后面就不用递归改用数组了

[retrocode]

换个角度想就理解了, 不是什么嵌套别超过多少多少层, 而是控制整个页面的总节点数量避免影响渲染性能, 主要是初次渲染性能,
现在配合虚拟 dom 和各种优化, 嵌套层级尽量少现在更多是"规范", 主要点是减少无用嵌套增强代码可读性, 真正需要靠较少节点优化性能的场景已经很少了

[star7th]

web 的嵌套确实对性能影响非常小。而且为了实现复杂布局，web 的嵌套可能会有很多层。

[karott7]

多年页面仔表示第一次听说要减少布局全套的，一直没想过这个问题，不过写代码肯定会下意识减少无效元素

[thinkershare]

Web, 不用刻意减少嵌套，只要记住标记应该是内容，而不应该是为了添加某个样式而构造，有了 flex 后，Web 的嵌套以前没有以前那么变态了。

[ixiumu]

现代浏览器不需要考虑这个 又不是 IE 时代 不要无限循环爆内存就行了 你找两款大型 HTML5 游戏 体会一下

[wangtian2020]

学校教的和工作用的完全不是一回事，学校里的老师教的实践知识只有过时的、错误的。
比如我上学的时候 sql 老师说一定要手写建表语句，后来发现公司里都是用图形化建表。
前端性能问题只会出现在代码中逻辑算法层面，稍微有点常识的人都是写不出来的。
前端安卓也有原生 Android APP 和 web APP 的区别，不明白你是指哪个。
代码只管写只管跑，不卡就不要管

[LavaC]

web 元素这么多，为了实现某些样式嵌套是必须的，不要有心理负担。
不过这倒让我想起来以前 V 友做过的一个测试浏览器性能的网页，你可以借此一窥浏览器套框框的上限 t/864602

[thetbw]

我也感觉，html 写起来好爽呀，一个布局怎么写都行，反正是那样的。反而是安卓，感觉写起来工作量好大

[Jame00001]

前端也强调啊，不过是要求自己的。没有必要肯定越少越好。毕竟元素越多渲染消耗越大。

[Track13]

性能影响几乎没有，而且不少人不让他多套几层就得费更多时间。

[Anarchy]

在 Android 也是个伪需求，我除了在面经上就没遇到过因为嵌套过多导致的性能问题，这大概率都是早年设备太渣了。或者有些 Layout 本身写的有问题导致了一些操作变成指数级上升，不过 Android 比较容易自己去改测量、布局的代码，结合这些才有这个不要过多嵌套的经验吧。

[ruoxie]

开发体验 > 开发速度 > 性能，也许你写的页面上线一个星期后就没人用了

[wunonglin]

怕不是没看过 cloued.google.com 的控制台。去看看能吓死人

[darkengine]

业界的一个准则，不要提前优化

[ChefIsAwesome]

网页一样的。渲染的节点数越多，速度越慢。三个方面：
1.dom 本身耗性能。
2.css 计算耗性能。
3.创建 dom 对应的 js 耗性能。

网页现在都是拿来做电脑端的管理后台。硬件性能强不说，资源还都耗在页面首次渲染那一下，100ms 和 200ms 没什么区别。
做移动端就不一样了。像那种 recycle view ，网页上做的性能非常差，滚过去内容渲染不出来。不去抠嵌套、节点数是不可能优化出来的。

[autoxbc]

@darkengine #18 减少不必要的嵌套并不算优化，只是把事情做对。两点间直线最短，走直线算优化么，挖虫洞才算