[crawshaw]

I could type ~four lines and an alert box response from a visual form.

For years I have lamented the amount of paperwork necessary in most of modern programming to get things done. I don't know how important that is now that I have a machine fill out the paperwork. It would still be better if there was less fuss.

[kccqzy]

    <button onclick="alert(1)">Click Me</button>

The amount of paperwork is controllable. It’s just that most programmers have a tendency to prefer more paperwork because they believe it is a better software architecture.

That said I also lament the death of WYSIWYG-style HTML authoring tools. This is I think the same affliction that caused programmers to prefer writing code to build UIs rather than drawing it interactively.

[Arch-TK]

Interactive UI design tools are cool when you're not a programmer, an inexperienced programmer, or lack the imagination necessary to create new abstractions.

UI preview tools are incredibly useful, hot reloading when doing UI work is, again, incredibly useful.

What nobody needs in their life is to meticulously hand place elements and align them only for the auto-resizing logic to fuck things up.

You want good abstractions which let you easily and quickly define UI elements and to define new composable widgets. So that you can declare in your code details of how things should be aligned with respect to each other, and leave final layout to more code which, if you are lucky, you might not even need to write.

For an example, check out jetpack compose. It's not completely flawless, but it truly isn't bad.

[kccqzy]

Yeah this is the kind of programmer’s thinking that led to complexity that is present by default and sometimes not warranted.

> meticulously hand place elements and align them

You don’t need as much meticulousness as you imagine. Have you tried placing some text boxes in Keynote or PowerPoint and hand aligning them?

> for the auto-resizing logic to fuck things up.

Auto-resizing is often unnecessary during rapid prototyping. Even in prod, even if you are developing internal apps in an enterprise environment, it’s still not necessary. Make your window non-resizable if you are targeting native, and set a fixed viewport <meta> for web apps.

> define new composable widgets

The kind of people who are enjoying VB6 don’t need new widgets let alone composable widgets. Just use whatever widgets that are builtin.

Basically your entire comment is describing the kind of complexity that I said was not always necessary.

[Arch-TK]

You don't need to be meticulous if you want your software to look like a 5 year old drew it, which maybe you don't care about.

But even so, hand placing 20 labels, editing them to say the right thing, then hand placing the entries, making sure the tab order is correct, you don't want to be doing that by hand. And it gets worse if you need to edit this in the future.

I am not saying this because I think it sounds stupid, I am saying this because I spent 4 years at an organization where this was the only method to do things and I _know_ for a fact that it is stupid and tedious. Given that we had the list of fields, if the language wasn't hot garbage, and the organization wasn't stuck in the past, we could have made it so 99% of fields on 99% of forms could have been placed automatically and cleanly saving literally months of development time in total.

We needed a complex UI for something which could not be done natively using this technology and I proved this to be true when I made a data driven UI in a fraction of the time it was taking to iterate on the legacy version which had 1/10 of the features.