Comment by stavros
2 years ago
VB6 was fantastic. The language was terrible, but the IDE was the best way to make GUIs that ever existed. The Windows 98 era was excellent for UX as well, with every element on the screen having an accelerator key, consistent menu guidelines, consistent visuals, keyboard shortcuts, etc.
It was just brilliant.
VB6 worked because the environment was simple. GUIs are simple when you don't need to do any styling, do not require any special modifications and most importantly you don't need responsiveness. All of that, and you need a special environment and operating system to run the GUI. Web front-end are a completely different game in that regard.
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?
> Every application had application menus that worked the same way, in the same font, and they all responded to the same keyboard shortcuts.
My experience had been that most (almost all) of them _only_ worked with a single font in a single font size and a specific window size. If you did change any of these, it got unusable.
About consistency: except for those that didn't, not even MS themselves were consistent. http://hallofshame.gp.co.at/shame.html
The 90s had been also the time of programs like Kai's Power Tools https://mprove.de/script/99/kai/ and Winamp.
I'm sorry, but "interface consistency" is not something that comes to my mind when I think of 90s and early 2000s Windows programs (neither was Linux). Irix with 4DWM had been quite consistent at that time.
7 replies →
I think you're forgetting how much more dense and complex even a basic web ui is in controls. Every HN comment in the default story view has something like up to 10 clickable controls - a pair of vote buttons, username, timestamp, a bunch of nav links, a hide control, a reply button. HN, the famously minimalist, oldskool website. The web made new ui and even the back-in-the-day version of that ui is way more complicated than the back-in-the-day desktop app UI you're thinking of.
13 replies →
> Windows has several competing "official" UI libraries. Every library has a different look and feel, and all are in various stages of decomposition
I can’t fathom why they made the decision to push every style to a different rendering engine. Working on Windows gets you to see every look and feel and the deeper you go, the closer you get to Windows 2000.
They dropped the ball because no major part of their current business model involves creating a better operating system for the sake of attracting new users
They seem to aim at minimising users leaving and maximising the extraction of data obtained per user
Hasn't there been a set of web components that tries to reproduce this?
I think about this every time I'm asked to build a custom dropdown menu. Can we just use a <select>? No- it must be 'branded'!
2 replies →
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.
wxWidgets sizers raise their hands!
2 replies →
> 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.
That's why I'm still hoping on Flutter or something similar for actual web applications. But it's been a long time in the making, I'm not quite convinced it will ever be able to replace the more traditional stuff.
I have to disagree on that.
Most of the controls you have on the average GUI app are present in HTML. The big difference is that HTML describes active documents, not dialog boxes.
>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?
Responsiveness lets you target two platforms with shit UIs for the price of one good one*, which is what businesses want[0], per the good ol' "worse is better".
* - two for one up front, ongoing development and maintenance costs of modern responsive UIs is going to be much greater than doing things right 2 or 3 times, but those costs are beyond the next sprint, and pay the good chunk of salaries in this industry, so...
--
[0] - And, unfortunately, this thinking became the zeitgeist of software development, so OSS projects do the same.
"Desktop" encompasses everything from ultrawide 8k monitors to 768p laptop screens where the user may have scaled down the browser window - and that's on brand new hardware, I know people who are still using 15+ years old laptops!
This alone means you either handle any window size and size ratio or your UI will break for some users.
1 reply →
There are many different screen resolutions. Being able to adjust the application based on available space makes the application usable to more people.
2 replies →
I think Delphi was slightly better. The components in Delphi were more powerful at the time. But the general idea is the same.
C# with WinForms is still usable today and provides a similar experience. Although the design language has fallen out of fashion.
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
The GUI WinForms editor in Visual Studio 2022 is a direct descendant of the one in VB6 and has all the exact same functions that I remember from VB6.
Let's not forget Delphi and OptiPerl https://www.uptiv.com/free/optiperl/ Till date I have not seen any IDE that could reproduce its amazing box and line coding feature
Delphi was even better. Great IDE, great language, compiled executables. Too bad that paradigm didn't survive the web.
>> but the IDE was the best way to make GUIs that ever existed
It was Lifted in spirit from NeXTstep's Interface Builder, so it was okay. But still a pale comparison.
P.S. If you are old enough, you will remember when $MSFT tried to steal Quicktime so its video products didn't suck. They got caught because they copied the machine code. Byte by byte. #howSad
I couldn't agree more, although I wouldn't be quite so hard on the language. It did have some strong points (for example, it was awesome for integrating with MS Office). To this day the GUI builder was the best I've seen. The current Mac stuff is more powerful, maybe, but the VB builder was way more intuitive and discoverable.
Back in those days, I (and many others) would use VB just to build the GUIs for C or C++ programs. It was that good.
was the language even that bad?
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.
"On Error Resume Next" never died, it just became serverless!
4 replies →
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.
You can create classes in VB 6 from IDE where you would add a class module and define code in that module. There was no "class" keyword AFAIK.
There was definitely a `Type` keyword that was similar to a struct.