Comment by novok

Yeah. Back in the day, every application was expected to use the same common set of controls - which were well written by the OS vendor, well tested, well documented and well understood by users. Every button on windows 95 looks and behaves the same way. Every application had application menus that worked the same way, in the same font, and they all responded to the same keyboard shortcuts.

These days every application reinvents its own controls for everything. For example, in a web browser the tab bar and address bars are totally custom controls. Electron apps like vscode take this to the extreme - I don't think vscode or spotify use any native controls in the entire UI.

I blame the web in part. It was never designed as a system to build application UIs, and as such the provided UI primitives are primitive and rubbish. Developers got used to building our own custom elements for everything - which we build fresh for every client and style in alignment with the brand. UIs built on the web are inconsistent - so our users never get a chance to learn a common set of primitives.

And for some reason, OS vendors have totally dropped the ball on this stuff. Windows has several competing "official" UI libraries. Every library has a different look and feel, and all are in various stages of decomposition. Microsoft's own software teams seem as lost as everyone else when it comes to navigating the morass of options - if windows 11 and MS Teams are anything to go by. Macos isn't quite as bad, but its still a bit of a mess. Every year I expect the people building xcode to know how to build and debug software on macos. And then xcode crashes for the 3rd time in a week. Xcode achieves the impossible of making the javascript ecosystem seem sane and attractive.

I'd love a return to the halcyon days of vb6, where UIs were simple and consistent. Where there was a human interface guidelines document that UI developers were expected to read. I want users and developers alike to know how the platform works and what the rules and conventions are. F it. How hard can that really be to build?

Uhhh, aren't native GUI toolkits "responsive" by definition? I remember in VB6 you could have elements take up a given % of its container, and I am pretty sure you could even make them appear/disappear programmatically (e.g., depending on container width). Sure you didn't have to make it work across a huge set of resolutions, but it was quite flexible still.

> GUIs are simple when you don't need to do any styling

Styling should be provided by the host, not the app. The app should give, at most, hints to the system - that this button is the default, what the tab key navigation order is, etc.

> Web front-end are a completely different game in that regard

They shouldn’t be. The API is different, because the presentation layer leaks all over the place into the app logic. With runtimes such as VB’s the UI elements see and react to events, while the runtime takes care of pushing those events either to the host software or to the event handlers that are part of the app.

That and the fact that web is built over a language for text, not UI. HTML is a terrible foundation for UI.

>and most importantly you don't need responsiveness

I'm gonna ask a dumb question out of ignorance because I know responsiveness is all the rage, but... what do we gain from it? Would it not be more straightforward to build UIs from the ground up for desktop and mobile targets than make one UI to morph to fit both?

I agree on all points. In Delphi designers and properties felt more logical and consistent.

For me, WinForms always had an element of struggle not present in Delphi

Well, a language that allows something like "On Error Resume Next" is not that great by any definition of the word...

Having said that, I must also say that I started coding on VB6 and if I had to show some elemetary programming to a ~10-yo, I'd give them something like QB64 in a heartbeat. There's something good in grappling with a "bad" language, educationally speaking.

It was a running joke about how bad it was. It was a bit before my time although, but even when I saw people use it as a kid and playing with it myself, it was pretty obvious how fast it was in making things.

It was terrible. Under that surface friendliness was hiding an ocean of incoherent rules, bugs and straight madness.

tl;dr: Aside from whatever flaws the VB6 language had, people writing so-so code in VB6 contributed to it's reputation as being a bad language.

Something that my sibling comments haven't (yet) mentioned:

VB6 was really easy to create a GUI with, had great DB support, and was a pretty easy language to get started with. Given that a lot of business apps boil down to "present a nice, user-friendly interface to the company database" (particularly biz apps for smaller businesses) VB6 was a great fit for business consulting types. And use it they did! There were a lot of business consultant types writing code in VB6. They were smart people but not necessarily the most hard core coders.

I think that's part of why VB6 coders (as a group) got a reputation as being "lesser" programmers - they were derisively called "code monkeys", etc.

Regardless of the language itself, I think that seeing a lot of "minimally viable code" being shipped by people focused on delivering business apps helps to contribute to VB6's reputation.

Side question: I wonder how many people here on HN have a 'career origin story' something to the effect of "Yeah, so I was in college/high school/middle school, and the <name of small organization/mom-and-pop business> wanted to use their computer to streamline things. I was just learning how to code but was able to get VB to do <minimal but useful task> which really helped <org mentioned prior>. Looking back on it that was some really gnarly code I wrote, but it worked, <the org> appreciated it, and it got me hooked on programming"

IIRC, there were no user defined types. You had to write the whole app using primitives.

VB6 could do more than access. I used both in the day and I found Access basic was limited and once you had some tools in VB6 to deal with databases and tables then it was easier than access.

However this is so long ago I have forgotten the details.

Access was probably simpler for a simple database entry and query.

However Access"s database was a disaster constantly getting corrupted etc. However I would note I was in companies that had access to full databases like Sybase and Oracle and as we had site licenses they were effectively free for each project. We often took a users Access project and made it maintainable in VB6.

One thing that i think would be very useful would be for VB to have inherent database support at the language/core level with the IDE being able to edit tables, etc. Essentially something similar to what tools like dBase/FoxPro/Visual dBase/etc but also being a generic application development tool like VB.

Visual Basic did have some database support but the actual database functionality/engine relied on external engines instead of being part of the runtime itself and it wasn't really part of the language. Being able to define a data type that is transparently mapped to a table's columns in a database and variables being cursors in a database would help with a bunch of smaller scale applications.

Basically something that mixed VB and Access. Ssadly that'd mean one would cannibalize the other's sales so it was never done.

Exactly, and the pre-made window doesn't even have the plan A / plan B buttons. For such a simple example it's hard to understand why they didn't just implement it properly.

Same. I learnt VB because VC++ with MFC was too complex for what I needed it for then. Hated VB after seeing Delphi.

Just wait until Billy in Accounting gets their hands on embedded Python...

https://support.microsoft.com/en-us/office/get-started-with-...

I guess that was about tooltips for the listbox items, because just a tooltip for a component would be the same with Windows Forms by just setting a property in the properties panel (granted, it's basically an ancient form of attached property that uses a separate tooltip component, but the UI streamlines this.

That's how it works today in Qt Creator too

It's the same in WinForms, my example was bad as I was trying to do something "unsupported" by the base objects :)

The pascal language requires things to be declared in a certain order. It's a bit awkward some of the time bit it enables the compiler to work in a single pass. This meant that running an application was extremely fast by any standards and this really made it stand out compared to other development tools out there.

VB created applications that had to ship with a shared runtime library. Windows wasn't great at versioning these libraries so developers often shipped their own VB runtime with their executable. The executable was small and the runtime was comparatively huge which had a negative impact on user perception when downloading the installers.

Before moving on to Microsoft in 1996, Anders Heilsberg was the Chief Engineer at Borland that oversaw the development and release of Delphi 1.0.

For years, VB felt like an application that could make deployable versions of itself. Delphi felt like a programming environment that compiled code into applications.

After Heilsberg moved to MS, a lot of improvements were made in VB that utlimately made Delphi less attractive, especially during Borland's strategic waffling known as "The Inprise Years": https://en.wikipedia.org/wiki/Borland#Inprise_Corporation_Er...

If you want to get a feel for what it was like then check out the FOSS clone "Lazarus".

Having worked with both Delphi and Visual Basic, I've found that Delphi had the edge, especially for professional apps. Its use of Object Pascal meant you got compiled, efficient code right out of the box, and it didn't need an extra runtime like VB.

The VCL component library in Delphi is still unmatched in native code – very comprehensive built-in (and commercial) components, and customizable. Plus, Delphi's database connectivity was unparalleled and can be setup in the designer where you could see data queried and returned live in your grid component!

Delphi also supported advanced language capabilities (when compared to VB), like inline assembly and pointers, which were essential for low-level optimization or system hacking. The robust error handling in Delphi was another plus compared to VB's older 'On Error' style.

Few things that made Delphi great: for one thing you could develop all sorts of apps in Delphi - from system management apps, to database heavy apps, to editors, to games etc.

1. The component architecture was just great - I have yet to see any language/platform with a more sophisticated component structure even now.

2. There were all sorts of free and commercial components that you could download and install into the IDE and have it running in your application in next to no time. ActiveX etc didn't even come close to the level of integration and speed that the Delphi component architecture provided.

3. Components could be loaded into the UI during the design time itself and you could see it functioning directly within the IDE when you place it on your form. Example: You could connect to a database, run a query, put that into a table with all sorts of sorting and navigation functions and you could see this working even without compiling the 3pplication.

4. It was trivial to develop components for Delphi - even though it was so sophisticated. You could develop one in about 15-30 minutes.

5. The compilation speed was just insane. It just blew everything else out of the water and so you could do fast compile+run cycles.

I wrote a neural net ML app in the 90s using Delphi.

VB was easier to start but Delphi was nearly as fast to build, code was compiled (fast!), Object Pascal supported OOP and the UI features like visual form inheritance I have yet to see implemented anywhere else.

Visual Basic 6 was quite limited, it was a programming language designed for doing applications.

Delphi, with its Object Pascal roots, was(is) a systems programming language that also happens to have a nice RAD tooling for GUI applications.

Put in another way, it didn't own anything to C++ in capabilities, and had VB like tooling.

VB had to wait for version 6 to support AOT compilation and being able to implement its own COM based controls without depending on C++, and even then it only supported a subset of COM features.

Meanwhile the GUI framework being used by C++ Builder is actually written in Delphi.

1. The language was better for big apps (statically typed, more powerful, lots of features like proper exception handling). It supported proper multi-threading and better Win32 interop, which in practice you often needed for advanced effects in both Delphi and VB.

2. The documentation was excellent and always reachable from anywhere in the IDE. It was all local of course so if you wanted to know about something - a control, an API, a part of the UI, whatever - you just pointed at it and pressed f1. Help would appear immediately with low latency. It also came with a big pile of yellow and blue covered books that taught you everything you needed to know.

3. The UI was well optimized with things like tabbed editors before tabbing became popular. It was made up floating but dockable windows, sometimes this was annoying but other times it let you keep things on screen.

4. Very good support for database connectivity.

5. The ecosystem was more coherent. VB wasn't usable for many advanced tasks so VB devs relied heavily on components written in C++ (OCX controls). Delphi was more powerful so components were often written in Delphi itself, with all the attendant advantages.

6. "Components" were more powerful than ordinary libraries of the type you get today - you could install a component into the IDE and it'd appear in a components picker at the top. You could then immediately drag and drop them onto a "form" (window) and begin configuring it with an interactive property and event UI that was always present on the left. This worked even for components that were not UI components, for example, you could drag/drop a timer from the component library onto a form, see all the properties and configure them visually, and then double click on the event to be taken to an editor window with the event handler already written out for you.

7. There were lots of little quality of life things, like it came with some stock icons for buttons.

Last time I used Qt Designer was the KDE2 days, it's almost certainly better than Delphi by now.

Versus the way we do things today, some stuff was better and some is worse. Delphi was primarily a wrapper around Win32 so apps written in it weren't portable. Back then it didn't matter of course, Windows had a monopoly. That meant it inherited Windows' limitations - UIs weren't responsive, styling barely existed, typography was limited, and the deployment story was nonexistent. That's why you keep seeing references to how great it was that Delphi made statically linked EXEs; same reason people like Go today. Operating systems suck hard at deployment, one of the things that eventually pushed people towards the web. In the grand tradition of platform devs ignoring deployment entirely, Borland never fixed it even as the web ate their lunch along with Microsofts.

On the other hand, the components model was pretty nice. Being able to configure libraries using a simple auto-generated GUI made them often much easier to use.

I used it. The user experience is not remotely close to Delphi, but it has WYSIWYG. The closest Python had to Delphi was Boa Constructor, but it stalled quickly, decades ago.

That's 20 years old. People like native apps, it's just that GUI programming is generally such a pain that many people avoid it.

> Of course there can be language extensions like C++ Builder did for C++ but they'd need to maintain their own compiler (or fork).

This is exactly what I hope would happen, except this time with Rust or Go. They don't need to integrate fully. I am not hoping for the ability to write Go/Rust for GUI code, just to be able to call into them without the clunky foreign functions.

I leave out Pascal now because besides the GUI part, the value isn't there anymore. The language is archaic otherwise.

> Personally i get the impression that Visual Basic and Delphi's language features were added in tandem with the underlying framework (if not deciding first how the framework and IDE features will look like and then deciding on the language features to support those) whereas modern UI stuff are made with whatever the target language has in place.

I agree. But the features stabilized, more or less. IDE experiences have not gotten better in a long while. It's not much of a moving target.

> language features like metaclasses, RTTI, properties, etc which allow the framework to register classes, instantiate them at runtime and inspect the class definitions so that serialization/deserialization and IDE features like the object inspector will work. AFAIK neither Go nor Rust have this.¶ The only language off the top of my head that has it is C#

Smalltalk and Objective-C?

FYI, since 2017-ish doing layouts in HTML is much easier if you use "display: grid". Just be aware that the numbering is based on lines, not boxes. Also be aware that to use percentage-based heights at top level, you have to style the `html` and `body` too.

Additionally, use of `@container` queries (the modern, poorly-documented alternative to `@media` queries) lets you do more advanced layout changes on element resize. This requires adding `container-type: size` style on the parent (I found this very confusing in the docs).

i'm struggling under the misconception that having things flex properly as the window sizes is the default in html and basically impossible in vb6. but i'm very open to having my misconceptions corrected. is there a public video that demonstrates what it looks like when an expert uses vb6, so i can see what things that are hard in html are easy in vb6?

i have no idea what segment, revenuecat, mixpanel, datadog, sentry, etc., are

Turbo Pascal for Windows did have a GUI designer, but it was a separate application from the code editor. It wasn't as integrated as VB.