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

[int_19h]

> Likewise with Java Swing and designers like Netbeans Matisse.

Matisse is the only UI designer that I know that does true drag and drop (letting you position widgets exactly where you want them) while also producing flexible layout. And IIRC they had to write a custom Swing layout manager for that.

[pjmlp]

That custom Swing layout manager is a standard Java layout manager since Java 6, released in 2006.

https://docs.oracle.com/javase/6/docs/api/javax/swing/GroupL...

Sun prototyped it on Netbeans, made it open source and then when everyone was happy, it became yet another layout manager available in any Java compliant platform.

That is the whole point of a layout manager engine, they are extensible.

Which is why project Houdini is having a layout engine APIs as well.

https://developers.google.com/web/updates/2016/05/houdini#la...