←back to thread

37 points fanf2 | 1 comments | | HN request time: 0s | source
Show context
nicoburns ◴[] No.46184193[source]
The problem with a constraint system is that it would likely be even more subject to performance problems than the current setup.

IMO what CSS layout really needs is:

1. A "proportion of available space" unit. That is, something like the fr unit in CSS grid except applicable to the width/height properties so it can be used in all layout modes and without an implying content-based minimum size (like fr does).

2. A new "display: stack" (name provisional) layout mode that simply stacks boxes one after the other like "display: block" but that works in both axes, and doesn't have quirks of block layout (margin-collapsing, floats, inline-block splitting, etc).

When combining 1 and 2 you'd have a much more intutive layout system that would still give you most of the power of Flexbox and could be implemented with much better performance.

(and you'd still be able to use the existing layout modes if/when you needed to extra power)

replies(4): >>46184268 #>>46184619 #>>46184644 #>>46185777 #
rendaw ◴[] No.46184268[source]
Why would it be subject to more performance problems?
replies(1): >>46184448 #
nicoburns ◴[] No.46184448[source]
My understanding is that constraint based layout performance is heavily dependant on providing lots of constraints so that the solver doesn't have too much work to do. But that the reason people like constraint-based layout models is that they don't have to provide many constraints.

Couple those together and you get poor performance. Or more specifically, unpredictable performance with lots of performance pitfalls that are hard to debug. Apple's AutoLayout is the real-world case study for this.

replies(1): >>46184521 #
rendaw ◴[] No.46184521[source]
A constraint like "make the top of this 20px below the top of the screen" should be no more computationally expensive than "margin-top: 20px". I'm not familiar with Apple's Auto-layout but why is it so slow? Maybe you have an example of what you're thinking of.

My guess is provides the power to do layouts that are difficult to do in CSS and also more computationally expensive, so it's not that constraints are slower, but that doing more complex layout requires more computation.

Edit: https://microsoft.github.io/apple-ux-guide/Layout.html (FWIW, by Microsoft?) seems to confirm this. Performance for normal layouts is normal, doing complex things with lots of chained, dependent constraints that modify many things is slow.

So, I don't think this is a good argument against constraint systems. People can do crazy things with more power. In fact, they already do crazy things because they can use Javascript which is ultimately powerful. Adding one more powerful system isn't going to change things. Companies do have limits for loading/rendering times for websites they publish, as loose as they are.

replies(1): >>46184577 #
nicoburns ◴[] No.46184577[source]
It's constraints like "line up the left side of widget A with the right side of widget B" that can be slow. In this case no width is provided for each widget, so the constraint solver has to find one (which likely involves calling into the widgets to size themselves, adjusting the sizes according to some algorithm and then laying out those widgets again with the final size).

These are also the kind of cases where CSS layout ends up being slow. But a constraint solver based layout gives you more power to shoot yourself in the foot with.

> but that doing more complex layout requires more computation.

It's exactly this. The question is whether that makes for an ergonomic system to use for the developer. My assertion is that if there is no feedback when you create a slow layout, then it is not actually an easy system to use, and you're better off with something more constrained that guides you into the pit of success.

replies(1): >>46184643 #
1. bryanrasmussen ◴[] No.46184643{3}[source]
>It's constraints like "line up the left side of widget A with the right side of widget B" that can be slow. In this case no width is provided for each widget, so the constraint solver has to find one (which likely involves calling into the widgets to size themselves, adjusting the sizes according to some algorithm and then laying out those widgets again with the final size).

this problem somewhat already exists with layout thrashing https://web.dev/articles/avoid-large-complex-layouts-and-lay...

And given how layout thrashing and similar problems work I feel that you can code CSS in a constraint manner at least part of the time.