IMO the real loss in IDE tech is the speed that visual basic 6 gave you to make desktop guis.
Web and mobile development (which I have done all 3) are significantly slower than what you could do with VB6. It's really strange why we haven't gotten back to it.
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?
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.
I realised I should've added: Have you actually seen a proper dense UI? Look at any professional software. You will die of old age before you can implement just the layout for it using web technologies.
Here's Cubase with TAL-U-No-LX synth emulator in front of it: https://pbs.twimg.com/media/E8M6-QOWEAQMgGl?format=jpg&name=...
Can MIXXX be considered professional software?
The skins are made using XML and QSS (Qt CSS).
It's not web per se, but it is not too far from it either. I would say it's a combination of both, Web and Desktop technologies, into one.
https://i0.wp.com/djtechtools.com/wp-content/uploads/2021/07...
It's not web technology by any stretch of imagination
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/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/
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_ma...
Probably still worse that what HN is now though.
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?
Voting could be handled with comments with specific content - wouldn’t even need to have a body, as everything could be in the headers. Totals could be computed at the server, unless we wanted real NNTP-style distributed discussions.
It really isn't. Web is anemic in controls and layouts compared to what's actually possible with proper controls and control over those controls.
Yeah; especially given the number of pixels we have at our disposal. Old UI screenshots look simple but they had to work at tiny resolutions compared to modern user interfaces. I remember when 800x600 was considered luxurious.
Web apps also can't use a lot of native shortcut keys to build keyboard-friendly UIs. Its rude to override the browser's right click menu. Alt-anything might bring up browser native controls. Ctrl/Cmd+S is owned by the browser. And so on. Some of this stuff you can override, but even if you do, users never experiment because those shortcut keys basically never do what you expect.
Dense?! I've never seen a web UI remotely close to what I'd call dense.
The HN UI would be very easy to recreate in something like Delphi, I'd call it trivial.
We use Delphi at work. Our main application is a regular Windows desktop application. I recently had to add a new module to our application at work, it required three new input windows/screens, each with 100-150 input fields, few dozen buttons, and several grids.
I made the UI parts in a day. A few more hours the day after and all the UI logic and database loading/saving was done, and I had a functional UI for all three windows/screens.
Many of our customers have HTML-based ERP or CRM systems that we integrate with. I've never seen any of them that are close to dense UIs, and most of the time I see the user having to click through multiple sub-screens just to do a relatively simple task like looking up a couple of values. With a denser UI that could all have been on a single screen and saved the user a ton of time.
But I'd love to be proven wrong. Any examples out there of actually dense, in the good sense, web UIs?
I don't see anything special in having tens actions on a UI item. Toggles, action links and vanilla buttons would take care of it.
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.
I used Windows 98SE for eight years. I never saw any issue changing window sizes.
I can't speak to font sizes since IIRC that was an option but I left it default.
For all my apps that had controls pinned to a specific coordinate, I made sure to make the windows fixed-size.
I taught courses on VB from versions 3 to 6 and this was always something we went over.
In the "hall of shame" you linked, they list applications which misuse radio buttons. Uh oh, call the police. Sure, there were a few inconsistencies. But honestly, up until the ribbon in Office, it was incredibly homogeneous compared to today.
In comparison, modern windows doesn't even hide its inconsistencies. Try right clicking on the desktop in windows 11. You get a dropdown with large item spacing and rounded corners. But then if you click "Show more options", the dropdown is replaced with a different dropdown with subtly different menu items, small spacing and sharp corners.
They aren't even pretending any more.
This isn't Kai's photo goo we're talking about here. This is core windows.
Unless you opted out, basically every application in the 90s and early 2000s was built using the core platform's UI library. There were a few exceptions, but the 90s were a golden age for platform consistency compared to today.
Now its hard to find any 2 applications on windows which use the same UI style. Firefox and explorer? Nope - the maximise and close buttons have a different style. Spotify? Nah thats some custom webview. Visual studio? Nope, thats using an old windows library. Whatsapp desktop? Qt. Intellij? Some java thing. And so it goes. Its an absolute zoo.
Interfaces were WAY more consistent than they are nowadays even when taking into account some applications slightly altering their themes. One application using a listbox instead of a tree (like one of the Microsoft examples in the site you linked) does not make a UI inconsistent (even as the wrong control, the listbox still looks and works exactly like the other listboxes in the system), it only makes it an odd/bad choice. And from a quick browse, most of the issues mentioned there are things like that (including, amusingly, a ribbon-like interface in Windows 3.1 in the tabs section[0] :-P).
IMO the fact that someone cared enough to make a site about what is largely nitpicks like this shows exactly how these stood out in the otherwise consistent landscape of UIs in the 90s.
Nowadays such a site would have 99% of every application released. It could even be automated, just somehow track all new .exe files in GitHub, MajorGeeks, Softpedia, etc and add them automatically to a hall of shame list, chances are even without human supervision the overwhelming majority will be correct :-P.
[0] http://hallofshame.gp.co.at/tabs.html
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'!
If you’re in a rare team doing agile halfway right, see if you can start providing separate level-of-effort for a feature with good UI that’s also quick, and the worse-for-the-user “on-brand” one.
Part of what causes this crap is that the costs aren’t visible. If you can get it through stakeholders’ heads that they’re cutting the feature development rate in half (and making UX worse, and paying in maintenance time and a higher defect rate, but those are harder to make them understand) with their twee UI, some can be steered away from it, or at least convinced to tone down the most-harmful parts.
A billion times this. And this is when the next version of the design system isn’t incompatible with the previous one.
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.
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?
There are many different screen resolutions. Being able to adjust the application based on available space makes the application usable to more people.
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.
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.
"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.
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.
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.
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!
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.
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.
was the language even that bad?
IIRC, there were no user defined types. You had to write the whole app using primitives.
There was definitely a `Type` keyword that was similar to a struct.
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.
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!
It was terrible. Under that surface friendliness was hiding an ocean of incoherent rules, bugs and straight madness.
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.
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
Delphi was even better. Great IDE, great language, compiled executables. Too bad that paradigm didn't survive the web.
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
Or even better one: Delphi (if you were into pascal)
I’ve often heard people mention that Delphi was a superior RAD GUI experience than Visual Basic, but as someone who’s never used it, what is it that made it so great compared to VB or other GUI builder type tools (eg Qt Designer)?
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".
Well, not actually. With Anders' move to Microsoft, VB6 (aka, VB "classic") was discontinued. Microsoft supported Visual Basic syntax on the .NET runtime, but the vast majority of VB programmers considered this to be a different language because developing for the .NET Framework (remember this is ~2001) was a huge departure from VB Classic.
Many VB developers petitioned Microsoft to open-source VB6 or continue releasing improvements on it. Microsoft did not and chose to continue with their .NET + C# strategy.
.NET 2.0 fixed much of those complains and even brought back Me.
There's a bit of a gap there though between 1996 and Visual Basic classic being discontinued. VB.NET came out in 2002 but VB6 was supported until 2008.
VB5 in 1997 and VB6 in 1998 really closed the gap with Delphi from what I remember.
VB6 was my last VB. It came at just the time when getting a computer onto a network to download and install a giant distribution was touch and go. The building where I worked didn't have networking in the labs, the "labs" were whatever space we could find, and the "lab computers" were old cast-offs retired from office use. It meant that supporting VB.NET with a brand spankin new networked computer wasn't a safe assumption.
At the same time, I was playing with Linux at home, and wanted tooling that could run on either platform. I learned Python at home, and then made the switch at work.
One of my last VB6 apps, thousands of lines, has been running in the plant without issue for 15 years. On one occasion I had to bump up the declared sizes of some fixed length arrays.
As for GUIs, I never found anything close to VB, but also decided to just write a thin wrapper around Tkinter and let my layout be generated automatically by default. I haven't missed laying out my GUIs, which were always a hodgepodge anyway.
This is (from Borland's telling) not an accident. https://news.ycombinator.com/item?id=29513242
Hard to not waffle when your major competitor hires away your top talent.
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.
Until VB 6, which introduced AOT compilation based on VC++ backend, and creation of OCX in VB itself.
To this day, one of the easiest way to do COM on Windows, even better than .NET Framework (.NET Core made it harder, yet another thing that Framework does better).
I thought VB6 used p-code embedded into the EXE? I don't think compiling VB6 to machine code would have been easy.
Nope, that is how VB worked until version 6.
In version 6, you could chose what compilation model, classical (p-code) or the new AOT backend.
Compiling BASIC to machine code is how it was born after all, the interpreters came to be in 8 bit machines, due to their hardware constraints.
Besides, Microsoft already had similar experience with a dual compilation model in Quick BASIC.
And not to leave this being my opinion only,
"Microsoft Visual Basic allows you to compile your applications to fast, efficient native code, using the same optimizing back-end compiler technology as Microsoft Visual C++. Native code compilation provides several options for optimizing and debugging that aren't available with p-code. These options are traditionally called "switches," because each option can be turned on or off."
https://learn.microsoft.com/en-us/previous-versions/visualst...
It allowed for both, the default being pcode (IIRC because it was more compact) but it could also do native code. The feature was introduced in VB5.
Note that it still required the VB runtime either way.
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.
Interestingly enough, the VB6 runtime has been part of Windows for quite some time, to the point that my old VB6 projects still run fine, while my experiments with VB.NET in .NET Framework 1 and 2 currently don't, since the ringtone isn't preinstalled. (granted, moving those to modern .NET is probably fairly easy)
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.
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.
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.
VB6 was the only “low code / no code” tool that actually delivered on its promise.
Bill Gates demoing it from 32-years ago.
https://youtu.be/Fh_UDQnboRw?feature=shared
Microsoft Access was way ahead, in my opinion. Especially that it came with a ready database, reports, etc.. and with VB6 you could practically do anything you want with the operating system. It's interesting we have thrown it all for something much more inferior.
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.
Excel is arguably the most successful low-code tool.
Even non programmers can come up with some crazy stuff in Excel that just works, that will just run on any machine in their company.
Just wait until Billy in Accounting gets their hands on embedded Python...
https://support.microsoft.com/en-us/office/get-started-with-...
Minor nit: he is demoing VB 1
That demo is partially faked - if you look at the "plan B" button, it doesn't actually make the UI show some newly changed data, it simply hides the entire window, and shows a different pre-made static window.
Even the "plan A" button code doesn't show the only interesting part of the code - how the UI is actually updated in response to the changed underlying data.
I spent a long time doing VB6 and Windows.Forms, the idea that it was meaningfully better than NeXT or Delphi is just wrong.
Delphi was even better. In fact, having used both, I hated vb6.
I would really expect there to be some FOSS Python or JS insta-app-maker that's as easy as VB was, but for some reason nobody wants to work on such things.
There is Gambas: https://en.m.wikipedia.org/wiki/Gambas
It's more that few people want to make and distribute small desktop apps anymore.
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.
I don't think it's the GUI programming, at least not for me. It's the cross platformness, and the fact that everything needs some kind of sync feature these days, plus just the sheer size of modern GUI apps.
i am working on such a thing myself at https://github.com/yazz/yazz. Also there are many other people trying to build something similar
Open source devs often don't like writing GUIs or documentation, which VB-like environments rely on very heavily.
Commercial devs meanwhile will work on those things, but generally want to host the resulting app on their own cloud for a monthly fee. That's lockin which is scary to people and so outside of platforms where there's no choice (e.g. Apple) they prefer to have a less productive dev environment but more vendor options.
30 years ago devs were much less sensitive to lockin concerns. Open source barely existed so the question was merely which vendor would you choose to get locked in to, not whether you'd do it at all. And fewer people had been burned by projects going off the rails or being abandoned. The VB/Delphi era ended when VB6 suffered execution-by-product-manager and Borland renamed itself to Inprise whilst generally losing the plot (wasting resources on Linux, etc).
Open source stuff tends to have much worse usability, but there are no product managers, no corporate strategies and in the unlikely even that the project decides to radically change direction it can always be forked and collectively maintained for a while. That concern outweighs developer experience.
Also the ecosystem is just way more fragmented these days. In the 90s everyone coded for Windows unless you were doing mainframe stuff, and on Windows there was C++, Delphi and VB. That was pretty much it and they could all interop due to Microsoft's investment in COM. These days you have JS, Python, Ruby, Java, Kotlin, Swift, C#, Rust, Go ... and they barely talk to each other.
Have a look at https://anvil.works -it's a drag and drop web app creator using python for front and backend. It's as close to Delphi for the modern age as I've come across.
You're totally wrong.
The IDEs I was making in VB6 in the 90s I'm making about twice as quick in Visual Studio 2022 in C# with WinForms.
In fact, quicker because I'm getting GPT to write any gnarly code I need -- like I just asked it if it was possible to add a tooltip to a ListBox and it churned out exactly the code I need, something I would have spent a bunch of time figuring out on my own.
In Delphi u didn’t need any code to add a tooltip to a component - just add it as a property in the inspector. U can do it in code if you want, but it’s easy to do since u see the available properties in the inspector.
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.
It's the same in WinForms, my example was bad as I was trying to do something "unsupported" by the base objects :)
That's how it works today in Qt Creator too
I never used VS/C#, but can you drop a TDBGrid connected to a TDataset and then just resize autoloaded columns to your taste? Discussing tooltips on a listbox in RADs is like discussing colors of pencils in a hi-tech workshop.
The above will probably take half a day in web development (assuming an experienced developer), so no, they aren't "totally wrong" at all.
Never really got why Microsoft didn't keep going with that kind of thing. Why don't we have .net properly inside excel instead of VBA?
Money? Internal elitism?
VBA can't really be removed due to the need to support legacy files (especially Excel). For more sophisticated stuff they expect you to use Office Developer Tools or similar now.
Office Developer Tools exist.
They're trying to steer people away from end-user programming towards using more well-defined, tested, features. I find it patronizing, but, having seen some VBA, understand the reasoning.
Sekhurity.
Can't have user-programmable tools, because they could be used to ship (gasp!) malware, or let users (GASP!) work around policies of their employers' IT staff.
what aspect of the development speed do you feel is faster? i feel like i can write things like
faster in html than i could in vb6. maybe i'm wrong about that?you can try it in your url bar: data:text/html,<select name=title><option>Mr.<option>Ms.</select><input name=name><input type=submit>
of course that doesn't give you database integration, but if you just want crud, you can get crud pretty quick out of django's admin
here's a couple of things i've hacked up recently in dhtml which i think wouldn't have been easier in vb6
http://canonical.org/~kragen/sw/dev3/ifs a 2-d iterated function system editor
http://canonical.org/~kragen/sw/dev3/clock a watchlighting clock
Now try to make a layout with that form example that you could free form put anywhere in 2d space and have it flex properly as the window size changes beyond the defaults that html gives you and make the generic B2B SAAS dashboard like Segment, RevenueCat, Mixpanel, Datadog, Sentry, etc. I bet you could make a VB6 / Pascal equivalent much faster than you would be able to with a mobile or web app, especially if they were updated with a decent graph widget set.
Also your two examples are drawing canvas examples, thats a pretty different target that delphi / vb6 have with their GUI toolkits.
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
Didn't Microsoft more or less just copy everything from Borland Delphi? They had drag and drop GUI stuff in the early 90s.
No, Delphi came out years after Visual Basic. There was an earlier Turbo Pascal for Windows, but it didn't have visual design features as far as I remember.
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.
VB6 was primitive compared to what Delphi gave us. It had live design time data binding, visual form inheritance etc. VB and VC++ were primitive compared to that. VCL vs MFC? No contest. The API was powerful, fast, great to extend by inheritance, best in class layout management. There were about 8000 third party components at web sites like Delphi Super Page. Half of those were free, rest were affordably priced for commercial use.
Much of the 90s experience lives on in FPC/Lazarus, but it did not get much better after that, and few use it. I wish they aligned themselves with a more popular language like Rust or Go for a more cohesive experience, while keeping Object Pascal (built with IDE experience in mind).
I still prefer the GUI building experience in Delphi 6/7 than anything that was produced since then. C#/Winforms is fine, it was designed by the same person - Anders Hejlsberg, but I wanted something native.
It's unbelievable that something modern like Flutter still fails to capture the design convenience of Delphi, from decades ago. Yes, the design markup is great, but I don't even want to look at it most of the time.
The later Swing/SWT editors never came close. Even Qt, which was inspired by it, never provided the component market experience of Delphi, and it was much more bloated in runtimes.
I fell in love with GUI design with Delphi, but otherwise hated it since.
A very core aspect of LCL and how Lazarus works (and VCL/Delphi for that matter) is 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# (which isn't surprising considering both Delphi's dialect of Object Pascal and C# were designed by the same person).
Of course there can be language extensions like C++ Builder did for C++ but they'd need to maintain their own compiler (or fork).
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.
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.
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.
Windows Forms is pretty much the successor to VB6 and I think is still supported. Still nothing like it on Linux though, even though people say Linux is way better than Windows for software development :/
The subset of GUI software is much much smaller than the greater whole.
I do agree though that any GUI programming on Linux is a pain compared to Linux / Mac. However the proliferation of web based apps, even those running in electron shows how valuable a truely cross platform GUI framework that is easy to use would be.
Google is trying with flutter and dart but last time I used it I felt it was still being iterated on far too quickly, maybe a bit ( maybe even now ) it will be more friendly to use.
Would this be similar to the .NET Webforms? That could be done in C# or VB.
The equivalent would be WinForms
Building apps with VB6 was so productive, wish it was that easy to build mac apps these days.
I haven't used it recently on macOS but Lazarus[0] has mac support. I used it some years ago on my iMac.
If you don't mind proprietary languages, there is Xojo[1] which seems to be designed mainly around Mac (it can do Win32 and Linux apps though).
[0] https://www.lazarus-ide.org/
[1] https://www.xojo.com/
Flash and Actionscript did this for the web but then Apple killed Flash.
Maybe in the era of LLM-assisted webdev tools (like teleporthq.io or MS Sketch2Code etc) the LLM will help sidestep API moats and help bring back such low-code IDEs. Or it could backfire and bring about API moats with non-human-accessible APIs (obfuscated binary only).
Apple did not kill Flash. Flash killed Flash.
Adobe claimed that they could get Flash running on the first iPhone if Apple let them.
When Flash finally did come to mobile via Android in 2010, it required 1GB of RAM and a 1Ghz CPU and it still ran badly.
The first iPhone had a 400Mhz CPU and 128MB of RAM. It could barely run Safari. Were you around when the only way that Safari could keep up with your scrolling was by having a checkerboard pattern while waiting on the screen to be redrawn?
Yes, Delphi too. So also tools like Powerbuilder for developing database-heavy apps. There is nothing even remotely close to those tools now.
If one wants, VB.NET with Windows Forms still does offer a similar experience.
I doubt it
VBA is still used all the time. As long as you have Excel or Outlook you can use it.
I dunno, I worked with Qt5 and Qt6 recently and creating a UI felt pretty fast and smooth to me (Much more so than the last time I did frontend web work anyway)
That said, I've never used VB6 so maybe I'm missing something...
I think by overall value it pales in comparison to Delphi. At leas this is my experience.
There was also PowerBuilder and other "4GL" tools.
As an old fart, GUI toolkits and building tools are one of those categories of absolutely essential software that gets scrapped and rebuilt (not in a good way) for every platform.
Kind of like IDEs for new languages, to the point of the article. First comes the language and basic CLI tools, and then about ten years later you might have a mature IDE with full language-specific syntax coloring, autocomplete, visual debugging, variable watches, etc.
And these 4GL tools were doing this with BASIC variants (not compiled) atop maybe 200-300 Mhz processors and 16-64MB (not GB, MB) of RAM. It blows my mind that modern OSes have slowdown and stuttering when the amount of CPU, considering multicore, more pipelining, branch prediction, etc, is likely 100x stronger than the the CPUs back then.
The 4GL languages/tools were all closed source and that did not age well. PowerBuilder folded (probably killed by Visual Basic), and then Visual Basic was killed in one of Microsofts platform purges.
They also were tightly coupled with databases in a UI --> DB architecture. As server architectures exploded in complexity beyond that, the 4GL tools couldn't adapt, partly because they were leveraging so much power of SQL under the hood, and the various server and RPC/invocations never offered the same power and flexibility.
But I can hear you .. SQL over the wire? Like send SQL to a backend service so it can be intercepted and injected and all that? Yup, probably part of the problem. Thick clients and direct internal LAN communication is an implicit requirement.