相对CSS定位比JS定位快吗？

Question

我想知道JS在确定某些值时是否比CSS慢，因为它们都必须进行相同的计算。

换句话说，如果我在%中将一个边距设置为一个元素，它将使用它的父元素的宽度作为基。例如，margin: 50% = margin: 0.5 * parent.width。那么，在内部，浏览器必须根据父节点的宽度计算正确的边距，对吗？那么，这与JS中的计算有什么不同呢？为什么CSS更快？是什么内部CSS呈现使这些计算过程比JS所能做的更快？

这是一把小提琴。两个子div都是相同的，但是一个div的边距是用CSS (margin: 20%)计算的，另一个是在JS中计算的：

var $cont = $("#container");
$("#js").css("margin", $cont.width() * 0.2);

考虑调整大小: CSS引擎将不得不在调整大小时重新计算边距，对吗？

考虑加载时间:我只讨论实际的执行时间。换言之：

var $cont = $("#container");
    $("#js").css("margin", $cont.width() * 0.2);

与

#css {margin: 20%;}

不包括任何额外的(库)加载时间。jQuery和vanilla之间的区别不应该包含在答案中。我知道两者的表现不同。

Answer 1

这个问题将有一个模糊的答案，因为它是非常依赖浏览器。但是，可以肯定地说，CSS在这里通常会更快。

首先要注意的是，我们并没有将CSS作为一种语言的速度与JavaScript本身进行比较。在这个意义上，CSS不一定是重复的executed。它的重点是指定非常适合浏览器核心的属性。浏览器可以解析它一次，然后对该规范做它想做的任何事情。事实上，如果它一次又一次地检查/执行相同的未更改的CSS代码，它通常会是一个相当糟糕的浏览器。

因此，看这个问题的一个方法是，我们并不是真正地问为什么CSS比JavaScript更快。CSS不是这里进行计算的那个。我们要问的是，为什么本地web浏览器可以比它能在上面运行的客户端JavaScript更快。

如果您将自己置于浏览器开发人员的境地，那么在解析CSS文件时，您可以看到一个规范，即元素的相对大小应该是其父元素的50%。

现在，当页面被重新绘制、滚动、交互时，您可以对规范做任何您想做的事情。您可以将该大小规范存储在核心数据结构的核心，如果需要，甚至可以使用金属刮取组装代码。您可以在一次传递中计算这种相对大小的子级的新的绝对大小，从父级下降到子级。您可以使用SIMD一次计算4个孩子的绝对像素大小。给定初始属性规范，您可以做任何事情。

对于JavaScript，我们没有这样的控制。客户端脚本在这里可以做任何事情，所以我们必须触发一个调整大小的事件，如果JS端调整了一个调整大小事件的大小，它可能会触发一整串这样的事件，甚至可能重置/干扰计算客户端矩形的常规进程。一个元素的大小，即使在百分比级别，也变成了一个空白，一个巨大的问号，在某种意义上必须反复地被“质疑”。这一切都是推测的，因为它非常依赖浏览器。

但是，不依赖于浏览器的是，考虑到CSS的静态、可预测和属性指定的性质，CSS允许这些浏览器本机优化。JS拥有更多的自由，所以它必须在上面运行，不能拥有允许浏览器开发人员任意使用它的特殊特权。

对于CSS，球是在本地浏览器开发人员的领域。有了JS，球就在您的地盘上了，考虑到JS代码在浏览器上运行，要击败浏览器开发人员将是相当困难的(如果可能的话)。

Answer 2

( 1)最后，都是CSS定位。在JS中计算它，而让CSS +布局引擎计算它只是意味着，一旦您有了这个数字，您就需要将它分配给元素(或其他地方)，并让CSS引擎从那里获取它，并在下一次重绘期间应用它。

2) CSS内部可以访问实际的像素宽度。有时需要确定元素的计算样式，以便进行计算.

...that意味着您需要调用一个方法，该方法读取这些值，将其解析为可行的数字，进行计算，将其转换回表示单位值的适当字符串，并将其发送回CSS/layout/呈现。

这并不意味着JS不能跑得很快。

同样，也有一些JS可以做的事情，CSS自己永远也做不到(比如高级的，动态的动画-混合)....but的诀窍是，在适当的情况下使用这两种方法，并且出于上述原因，知道您所写的东西每秒运行数十次，不能与每次触摸使以前的计算无效时只需要计算的东西相比较，这样做的好处是，您可以随意更改JS版本中的细微细节，并编写各种序列，这些序列可以动态分解和重新组合，在CSS中，您可以听凭预先定义的动画的摆布。