[dahwolf]

Not just VB, but also things like Borland Delphi.

25 years ago, you could visually compose a UI using standardized components, including advanced concepts like a layout manager. You could do data-binding visually by navigating a linked database. You can write logic/events just by double-clicking a button and the event is created. Here you'd write your code which would typically be pretty easy because all contextual objects are readily available.

Sure enough, I understand that the above development model also has its limitations and doesn't serve all common modern needs. But still, it's pretty pathetic what we ended up with. Our tool chains are much more complicated and we program at a lower abstraction level whilst requiring a laundry list of skills.

[askvictor]

Having used both early in my career, Delphi absolutely shat on VB. But I'd be really interested to see the code I wrote in the 90s and see how it stands up in terms of reliability, maintainability, testability etc.

The closest thing I've found in the modern age is https://anvil.works - basically works like Delphi/VB, but web based, and in Python. For both frontend and backend.

[lelanthran]

> The closest thing I've found in the modern age is https://anvil.works - basically works like Delphi/VB, but web based, and in Python

You haven't used Lazarus (https://www.lazarus-ide.org/)?

[ulope]

And everything looked like the same unusable mess with 25 nested tab groups and tree views

[jules22]

I'd take a Delphi/Lazarus UI over most Electron apps. They started fast, took little RAM or disk space, used very little CPU, had fast response times, supported standard UI conventions.

Today, we have endless options. But most are not as comprehensive as what Delphi is/was. I'd rather write a UI in Delphi/Lazarus (LCL/VCL/FireMonkey) than any other UI framework even today. The trouble is, I don't want to use it for anything else other than the UI.

UI design and data binding should be a simple mouse driven activity. That's adequate for most designs. Why do we need code? It's like expecting everyone to use LaTeX than RTF. Sure, it's more flexible, but an overkill.

I wish there are more integrations with modern languages than 20 types of grids with overlapping functionality. I'd write my code in a language appropriate for the task and just use Lazarus for the UI. Currently, Python (Python4Delphi) seems to be the only one with components for that, but even that needs more polish (and largely stagnant for over 20 years). Most I can do is do shared libraries and call in.

[postalrat]

Do you have an example screenshots of what you are talking about?

[mike_hearn]

https://imgur.com/T9VnXi8

Why did this stuff happen?

Creating custom controls was difficult and considered to be for advanced programmers only. If you did create one, you'd get little to no help from the OS. You got lines and rectangles basically. You lost all layout support, there was no good typography features, etc. Coordinates would all be computed by hand. A real PITA. So everyone used the pre-made widgets even when they weren't really appropriate.

There were no icon packs and very few icons that were widely recognized by users anyway. So, everything was very text heavy.

There was a strong convention back then that you did not use scrolling to reveal controls. In other words, if you had more controls than fitted on the screen, you were expected to use button-like things to switch between pages of them, not expect the user to scroll down. The UI toolkits didn't support scrolling of widgets all that well as a consequence. This bias goes back very far and is partly due to the lack of compositing and pervasive optimizations for slow redraw speeds - it was more efficient to do a single redraw from old to new set of widgets than the constant rapid redraws required for animation.

All the UI code is being written in relatively bad languages like VB or C that aren't designed with refactoring in mind. The word "refactoring" doesn't even exist in this era, IIRC. Certainly, IDEs that help you do it don't exist.

Layout in this time is mostly absolute, or scaled to font sizes at best. Layout managers barely exist, so windows that aren't resizable are standard. As a consequence if you run out of space in a window, it can be disastrous - adding a new button or feature can become a tedious nightmare of relaying out everything by hand. So once code is written and app architecture is set early on, it's never changed. Features get added but redesigning the UI is so painful people just don't do it, and so if they run out of space you get ever more tabs, dialogs, buttons that open more dialogs that have more tabs, in an endless maze.