4 ms·

As somebody who has optimized both CSS implementations and native rendering engines / UI frameworks, the main reason why I am fundamentally skeptical about the

As somebody who has optimized both CSS implementations and native rendering engines / UI frameworks, the main reason why I am fundamentally skeptical about the performance of CSS as an application platform is incremental layout. No one has ever implemented CSS with incremental layout in a way that is even close to being competitive with native UI code. If you want to make a responsive UI, doing work incrementally and amortizing the cost of actions across frame intervals is more important than raw performance. This is especially true on mobile, where frequency / voltage controllers for CPUs and GPUs are tuned to work best on consistent workloads rather than bursty workloads.

pcwalton 11y ago
> No one has ever implemented CSS with incremental layout in a way that is even close to being competitive with native UI code. So this is a really broad statement and without further clarification it's hard to pin down precisely what you mean. By incremental layout do you mean partial layout, or relayout after dynamic changes? For the latter, I don't see how flexbox (for example) is worse in this area than springs and struts, as it essentially is springs and struts. And for absolutely positioned UIs (the old way mobile apps were laid out), layout time of CSS is essentially zero. For the former, it's commonplace to use frameworks that will do the standard "UITableView" sort of optimizations in script. Moreover, though, there's CSS Containment [1] coming soon to allow for these sorts of optimizations without having to use JS. I agree that CSS Containment is critical to allow CSS to achieve the performance of native frameworks, but this is an area of active work, and I don't see any roadblocks in the way of partial layout once CSS Containment arrives. [1]: https://drafts.csswg.org/css-containment/ https://drafts.csswg.org/css-containment/

pcwalton 11y ago

> No one has ever implemented CSS with incremental layout in a way that is even close to being competitive with native UI code. So this is a really broad statement and without further clarification it's hard to pin down precisely what you mean. By incremental layout do you mean partial layout, or relayout after dynamic changes? For the latter, I don't see how flexbox (for example) is worse in this area than springs and struts, as it essentially is springs and struts. And for absolutely positioned UIs (the old way mobile apps were laid out), layout time of CSS is essentially zero. For the former, it's commonplace to use frameworks that will do the standard "UITableView" sort of optimizations in script. Moreover, though, there's CSS Containment [1] coming soon to allow for these sorts of optimizations without having to use JS. I agree that CSS Containment is critical to allow CSS to achieve the performance of native frameworks, but this is an area of active work, and I don't see any roadblocks in the way of partial layout once CSS Containment arrives. [1]: https://drafts.csswg.org/css-containment/ https://drafts.csswg.org/css-containment/