Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.





>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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: