5 ms·

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 importan

by csomar 3y ago

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.

josephg 3y ago
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?
- pvg 3y ago
  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.
  - josephg 3y ago
    Hm. I don't think it would be that hard it would be to remake HN's UI using an old school UI component library. The up/down arrows could use the up/down buttons on this screenshot from macos's old color picker: https://guidebookgallery.org/pics/gui/interface/dialogs/colourselector/macos753-1-1.png https://guidebookgallery.org/pics/gui/interface/dialogs/colo... ... But limited to only allow you up/downvote between -1 and 1. Everything else could be done with buttons and a TextField / Label for comments and replying. The web is a bit weird in that it taught us to build every UI as a giant scrolling document. And HN is no different. A more "classic" UI approach would be something like Thunderbird mail - with 2 panes: a "comments" tree on top and a "message body" down the bottom. That would be harder to read (since you'd need to click on the next message to jump to it). But it might encourage longer, more thoughtful replies. Thunderbird: https://lwn.net/Articles/91536/ https://lwn.net/Articles/91536/ Or you could reimplement HN with classic controls and something like TB 114's UI: https://www.ghacks.net/wp-content/uploads/2022/08/account_mail_tab.png https://www.ghacks.net/wp-content/uploads/2022/08/account_ma... Probably still worse that what HN is now though.
    - tomatocracy 3y ago
      A "traditional" UI for HN would surely look a lot like Usenet newsgroup readers. I think Thunderbird might even still support NNTP. Usenet had a much better model for discussion groups/forums like HN in my view, though crucially for the modern world it is missing some kind of "comment voting"/user-driven moderation. I wonder if there's an HN<->NNTP gateway around somewhere?
indigochill 3y ago
>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?
- Osiris 3y ago
  There are many different screen resolutions. Being able to adjust the application based on available space makes the application usable to more people.
  - funcDropShadow 3y ago
    And it introduces new failure modes. I often experience responsive web applications hiding UI elements in my Firefox windows. Those windows usually use either the left or right have of a 28" 4k display. Why the heck do the hide the sidebar to save space? It is fucking annoying.
  - badsectoracula 3y ago
    In theory that sounds nice but in practice i haven't seen a single desktop application that can actually handle resolutions lower than whatever resolution the developer/designer used. I used a 1366x768 monitor for a long while ~3 years ago and everything looked both gigantic and had padding everywhere. As for the web, responsive design was so great that in almost every site i had to zoom out to make it think i had a monitor with a bigger resolution than i really did. These days and since i do not maximize the browser (because my monitor is huge - like all modern monitors that do not have awful image quality tend to be), i often have to resize the window because sites tend to think i'm using a mobile phone and instead of scaling down / hiding less important stuff (that would at least be appropriate for a narrower viewport) they make thing ultraginormous (because touch screens), overly padded out (because touch screens) and they hide all options behind a hamburger menu (because mobile screens are physically too small). I'm certain there are theoretically ways to do it "right" (a friend web developer told me how but i forgot) but absolutely zero sites (that i visit) do that.
HeavyStorm 3y ago
That and the fact that web is built over a language for text, not UI. HTML is a terrible foundation for UI.
- zeroc8 3y ago
  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.
- rbanffy 3y ago
  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.
lou1306 3y ago
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.
- Shorel 3y ago
  wxWidgets sizers raise their hands!
  - jules22 3y ago
    I liked Delphi's anchors. They were extremely simple, visually defined, and met all of my layout needs.
    - capr 3y ago
      Those were nice because you would start with floating elements that you'd move around with the mouse until you'd figure out a good layout and then add the anchors at the end and make it all flexible. Delphi was all about having a smooth progression from mockup to prototype to production. Compared to it, current web workflows are outright retarded.
rbanffy 3y ago
> 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.

by csomar 3y ago

josephg 3y ago

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?

pvg 3y ago
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.
- josephg 3y ago
  Hm. I don't think it would be that hard it would be to remake HN's UI using an old school UI component library. The up/down arrows could use the up/down buttons on this screenshot from macos's old color picker: https://guidebookgallery.org/pics/gui/interface/dialogs/colourselector/macos753-1-1.png https://guidebookgallery.org/pics/gui/interface/dialogs/colo... ... But limited to only allow you up/downvote between -1 and 1. Everything else could be done with buttons and a TextField / Label for comments and replying. The web is a bit weird in that it taught us to build every UI as a giant scrolling document. And HN is no different. A more "classic" UI approach would be something like Thunderbird mail - with 2 panes: a "comments" tree on top and a "message body" down the bottom. That would be harder to read (since you'd need to click on the next message to jump to it). But it might encourage longer, more thoughtful replies. Thunderbird: https://lwn.net/Articles/91536/ https://lwn.net/Articles/91536/ Or you could reimplement HN with classic controls and something like TB 114's UI: https://www.ghacks.net/wp-content/uploads/2022/08/account_mail_tab.png https://www.ghacks.net/wp-content/uploads/2022/08/account_ma... Probably still worse that what HN is now though.
  - tomatocracy 3y ago
    A "traditional" UI for HN would surely look a lot like Usenet newsgroup readers. I think Thunderbird might even still support NNTP. Usenet had a much better model for discussion groups/forums like HN in my view, though crucially for the modern world it is missing some kind of "comment voting"/user-driven moderation. I wonder if there's an HN<->NNTP gateway around somewhere?

indigochill 3y ago

>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?

Osiris 3y ago
There are many different screen resolutions. Being able to adjust the application based on available space makes the application usable to more people.
- funcDropShadow 3y ago
  And it introduces new failure modes. I often experience responsive web applications hiding UI elements in my Firefox windows. Those windows usually use either the left or right have of a 28" 4k display. Why the heck do the hide the sidebar to save space? It is fucking annoying.
- badsectoracula 3y ago
  In theory that sounds nice but in practice i haven't seen a single desktop application that can actually handle resolutions lower than whatever resolution the developer/designer used. I used a 1366x768 monitor for a long while ~3 years ago and everything looked both gigantic and had padding everywhere. As for the web, responsive design was so great that in almost every site i had to zoom out to make it think i had a monitor with a bigger resolution than i really did. These days and since i do not maximize the browser (because my monitor is huge - like all modern monitors that do not have awful image quality tend to be), i often have to resize the window because sites tend to think i'm using a mobile phone and instead of scaling down / hiding less important stuff (that would at least be appropriate for a narrower viewport) they make thing ultraginormous (because touch screens), overly padded out (because touch screens) and they hide all options behind a hamburger menu (because mobile screens are physically too small). I'm certain there are theoretically ways to do it "right" (a friend web developer told me how but i forgot) but absolutely zero sites (that i visit) do that.

HeavyStorm 3y ago

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

zeroc8 3y ago
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.
rbanffy 3y ago
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.

lou1306 3y ago

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.

Shorel 3y ago
wxWidgets sizers raise their hands!
- jules22 3y ago
  I liked Delphi's anchors. They were extremely simple, visually defined, and met all of my layout needs.
  - capr 3y ago
    Those were nice because you would start with floating elements that you'd move around with the mouse until you'd figure out a good layout and then add the anchors at the end and make it all flexible. Delphi was all about having a smooth progression from mockup to prototype to production. Compared to it, current web workflows are outright retarded.

rbanffy 3y ago

> 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.