[GuB-42]

Maybe I am not a UI designer but I much prefer rule based approaches than drawing.

Rule based means I tell use instruction like "this button must be on top on that button horizontally centered", "this label must fit that text", "this image must be between this and that", etc... and let the layout engine deal with it. UIs are usually not paintings, window sizes vary, text length changes with localization, decorations change depending on the environment, etc... Approaching a UI like a canvas will certainly yield good results on the designer machine, but will look out of place everywhere else, if it is usable at all.

I think it is the basis or what they call "responsive web design".

[intertextuality]

This is basically how designing ios/osx apps in xCode works. You set a bunch of constraints that are relative to one another. You can also specify what type of screen those constraints will work on (like iphone vs ipad screens) and portrait / landscape.

I find it quite pleasant once you get used to it.

[daurnimator]

It is (or at least was) all based on Cassowary: https://en.wikipedia.org/wiki/Cassowary_(software)

[Animats]

I am not a UI designer but I much prefer rule based approaches than drawing.

CSS isn't even rule based. If it was a constraint system, like "A must be to the left of B", and "C and D must have the same height", extended with "A and B must be at least this big, and drop C if it won't fit", it would be rule based.

[saagarjha]

What you're looking for is constraint-based layout such as AutoLayout on iOS and ConstraintLayout on Android.

[Retric]

This really depends on how the UI designer does layout.

Nothing says you need to allow users to do absolute positioning vs rule based when someone drags stuff around. You can help this along with multiple common views at different resolutions, so users don’t try and force a pixel perfect version.

[blattimwind]

It's funny how web development still doesn't offer the ease and productivity of early 2000s RAD environments.

Even this software is actually not simpler, on the contrary: It is far more complex, because you don't know how to create a given widget [assuming you already learned what widgets there are, because the software doesn't tell you]. You have to learn what the software recognizes and how you need to draw it in multiple strokes. Since recognition is ML-based, it is difficult to tweak and a black box to both user and developer ("why doesn't it recognize this...?").

Contrast with 90s form designers with a simple drag-and-drop palette. (They didn't have layouts just yet, that came a bit later). You can immediately see what widgets are offered and to instantiate them you simply drag them from their "reservoir" to the active area. Simplicity itself.

[pjmlp]

Actually there are a couple of companies doing it, but they have commited the capital crime of asking for money, as such they remain a niche product.

WebFlow and OutSystems are two examples that come to my mind.

I hope that WebComponents will make it easier to adopt such tooling.

[mhb]

Would be nicer if those could be tried without signing up. A misdemeanor.

[int_19h]

Early 2000s RAD environments had a much simpler model to work with, that didn't accommodate things like changing the size of widget's contents well. If all you needed was a button of a fixed size, that would always stay in e.g. the bottom right corner of the window, they could do that. If you wanted a button that would automatically resize as its label grew longer, some of them could do that too (pretty much every framework could do it for labels, but many couldn't for other widgets).

But the moment you wanted something like: there's two buttons, one following the other in the bottom right corner of the window, with a certain fixed spacing between them, but otherwise dynamically sized to content, it all broke down. And this just happens to be one of the most simple scenarios, just a basic dialog box with "OK" and "Cancel"!

How did it work in practice? We just made widgets "wide enough" to fit anything that could conceivably be thrown at them. If later that assumption was proven wrong - e.g. because translators came up with a very long string for the label - then the developers would have to go back and redo the UI.

[ZootAllures91]

None of the issues you're describing really still exist now in the majority of those kinds of tools, though.

Keep in mind it was usually always the case you could set widget sizes (or do anything else you wanted) "in code", also.

It's not as though you were ever forced to always use the visual designer for absolutely everything.

In general, there are no significant differences whatsoever between the way something like React actually works and the way something like WinForms works.

[pjmlp]

Motif might be a pain to use versus Win32, from my point of view, but layout managers were a central piece to it.

Likewise, Windows Forms table layout managers and Swing layouts, while not as powerful, did the job.

[int_19h]

Yes, but those layout managers were also incompatible with UI designers, generally speaking.

(WinForms designer technically supports them. But it's less "drag and drop", and more like "drag and ... um, what the hell is this thing doing there now?").

[pjmlp]

For me it was always "drag and drop" + setting the respective properties, not sure what the problem is, other than not bothering to learn how to use them.

The only problem is how buggy VS designer in some releases tends to be, forcing to restart VS from time to time.

But that affects all kind of stuff, including apps not using layout managers.

And regarding Motif, I surely recall the GUI designers being relatively good.

Likewise with Java Swing and designers like Netbeans Matisse.

[rzzzt]

MiG Layout sounds similar (see the small example at the bottom of the page): http://miglayout.com/

[fouc]

That sounds a bit like CAD actually, where they let you set properties on various dimensions and auto-fit/organize everything else according to that.

[maxxxxx]

Totally agree. You have to be able to model the relationships between controls. WPF is actually quite good about that.