Hacker News Reader

Comment by Ao7bei3s | Hacker News Reader

Delphi and Visual Basic 6 were definitely not the pinnacle of UI development.

For example, all layout was pixel based. Making windows resizable required much complex ad-hoc code, and internationalization was hard as well. Very early in my career, I have spent person months clicking through every single screen in a large desktop application to find words cut off due to words having different lengths (measured in pixel) in different languages. I knew what "Ok" and "Cancel" meant in half a dozen languages. At the time, Java was really breaking ground with container based layouts in Swing. Delphi and Visual Basic caught up only in the .NET era.

View on HN

Don't know about VB6, but at least Delphi had Align property and TPanel/TGroupBox. Together, it allowed to make apps that handle resizing just fine without any custom logic.

(it has been a very long time, but I think those only handled internal composition and not overall window size.. so you'd still need some custom code if you wanted dialogs as compact as possible. But as long as you never missed setting Align property, you did _not_ have to manually resize every control for different text/font size).

It's actually not entirely correct with respect to VB6. It did indeed use absolute layouts, but unlike Delphi with its pixel units, in VB everything was measured in "twips" (1⁄1440 of inch, or 1⁄20 of point). This would then be converted to actual pixels based on the DPI setting of the system.

> Delphi and Visual Basic 6 were definitely not the pinnacle of UI development.

> All layout was pixel based.

I'd say that was a very reasonable trade-off at the time, when most screens were somewhere between 640x480 and 1024x768 resolutions at 72 DPI. This simplified UI design sufficiently enough that VB/Delphi provided an optimal solution that, yes in hindsight, would most accurately be described as a "local maxima" for the environment and the time.

> Making windows resizable required much complex ad-hoc code

I remember there were ActiveX controls one could drop onto their form that would attempt to derive the layout based on initial positioning of controls, i.e. that a lower row of buttons should be anchored to the bottom of the window, while textboxes are took up a larger area would automagically resize with the window.

> For example, all layout was pixel based.

These sort of excuses always come up when Delphi and its insane productivity is mentioned. The same thing happens in conversations about how slow software has gotten.

High-DPI displays, internationalization, and accessibility are a pain but don't introduce enough complexity to hand-waive away the criticism.

Going a bit off-topic, but the browser is carrying around so many legacy concepts and ideas - it's a complete disaster - but it's the only option. The document object model is slow and weird to use to build reactive user interfaces.

We should demand something better. The browser is a local maximum as an application platform, and we should stop defending it.

The browser is the OS. We can already put WASM on a <canvas> and ignore most of it, but turns out rendering text properly is hard.

Accessibility too

You can’t look at the language in isolation. Visual Basic was backed by the fantastic Visual Studio for development. That ecosystem was way more mature than Java ever got with Swing et al. IMO, if there’s one thing MS ever did right, it was how they nailed WYSIWYG GUI app development. Now they’re going backwards with the WinUI XAML crap.

> Now ... XAML

Microsoft has been pushing XAML for long enough that it could drink, drive and vote in my country

The experience has become worse with WinUI 3. They got rid of the designer view. So now you're developing the UX code first. This is very unlike the prior paradigm, where you would typically drag and drop the components in your workspace/design view and then code the interactions. It is precisely what made Windows programming so accessible to the millions of developers. This is a step in the wrong direction IMO.

VB6 was its own thing separate from Visual Studio.

No it wasn't, this keeps being wrongly repeated.

Both had layout managers, they just required a bit more effort to use, and developers as we know are all lazy.

I came from Visual C++/Basic world when I first got my Mac and dove into Xcode for the first time (2002? 2003?). Flexible layouts, connecting UI elements to datasources, localization...

Oh my was I amazed.

Visual Basic could connect UI elements to data sources.

Layout managers were well established industry-wide by the 90s, which is where I started using them.

Absolutely - Qt had already figured out how to do layout before Swing was much of a thing (AWT doesn't count, yuck).

I suspected AWT had layout managers as well, so looked it up:

https://docs.oracle.com/javase/8/docs/api/java/awt/class-use...

Believe that was there from the beginning, mid 90s.

VB6 (and its predecessors) didn't ship with windows resizing and alignment out of the box, but there were 3rd party components that did that nicely. This happened way before Java.

https://web.archive.org/web/20160406102051/http://vbrad.com/...

"easy UI development" Java never really got that part right.

Yes it did, IDE tooling was the answer, and Netbeans still provides its Matisse, WindowBuilder on Eclipse, and as does InteliJ.

Back in the day, JBuilder offered a Delphi like experience.

What I would agree is that the thing that actually made Swing hard are the defaults, which required books like "Filthy Rich Clients" as gate into making wow Swing applications.

Reply on news.ycombinator.com