Comment by sheepscreek
6 months ago
> Visual Basic was the pinnacle of graphics programming
I am still shocked how no tool since has managed to come even close to VB. You could easily develop a moderately complex GUI application that felt snappy in an afternoon. C# with WinForms is the second closest to that. All other iterations since have not been designed with individual developers in mind, sadly.
A powerful developing alternative to this paradigm could be what I’m calling speech/voice driven development (SDD or VDD). It takes some pain of typing so much away - makes interactions with AI feel a bit more natural. Like talking to a colleague. But for it to really work well, AI models will need to become even faster.
The simplicity and efficiency of Visual Basic UI programming relied on several assumptions that became obsolete in 2000 when LCD and high-DPI displays became widely available. Everything in the VB UI editor was based on a fixed layout. There was a fixed font size, fixed DPI-density display expectation, and fixed button sizes. Every dialog assumed fixed sizes and was non-resizable. Adding a translation to such an application was pure hell. Typically, you needed to add a lot of buffer space for English strings to ensure that German strings, for example, would not break the layout too much. UI frameworks that solve these problems with a proper layout management system are obviously more complicated, but they address issues that VB6 never touched.
> The simplicity and efficiency of Visual Basic UI programming relied on several assumptions that became obsolete in 2000 when LCD and high-DPI displays became widely available. Everything in the VB UI editor was based on a fixed layout. There was a fixed font size, fixed DPI-density display expectation, and fixed button sizes. Every dialog assumed fixed sizes and was non-resizable.
There are visual UI editors that provide for dynamic layouts. (The old Glade editor for GTK+ was one example; modern GTK+4 still does not come with a standard UI editor.) The underlying issue is pointless churn in modern UI frameworks, not the assumption of a fixed-DPI display.
Even Java's Swing, introduced in 1999 (or maybe 98 in beta?), dealt with the problem of dynamic layouts fairly well. Of course, it performed like an absolute dog to begin with, but most of the performance kinks were dealt with during the Java 1.3 era (2000), and by 1.4 in 2002/3 or so, performance was absolutely fine, with most of the rendering quirks of the native look and feels having been dealt with as well.
Moving to C#/WinForms in late 2004 after working with Swing for 4 years felt absolutely jarring by comparison. No concept of layout managers and very limited options for dynamic layout in general (docking was about it, IIRC), really hard to customise components (if it was possible at all - for many it wasn't because they were just thin wrappers around Win32). It was terrible by comparison and I seriously considered quitting the job I was in, even though I liked the company, and finding a role in a Java shop again instead because I hated WinForms so very much.
Swing is obviously ancient history now. Is it still a thing? Do people still use it? Are there still Java desktop apps? I've no idea. But even 20-odd years later Microsoft have never managed to surpass it for desktop app development. WPF is OKish, and certainly addresses a lot of the problems of WinForms, but it's always felt over-complicated and the syntax of XAML has never really been a plus point in my opinion. Silverlight was... a debacle.
And, really, since 2013 I've only paid attention to distributed systems, web, and back end development (all of which have their own problems and complexities) so I've really lost touch with Microsoft's desktop development paradigm.
But I do find myself often yearning for the "simplicity" of desktop app development. Of course, that simplicity comes at a cost: you're trading it for complexity in licensing, distribution, deployment, and support because you have no control over your target environment, and you have to support almost unlimited combinations of machine configuration (which is not necessarily a picnic when you have thousands, tens of thousands, or hundreds of thousands of customers for each product). And, let's be real: nobody misses InstallShield and MSIs.
6 replies →
> fixed DPI-density display
This part is maybe technically true but not in spirit. High-DPI didn't exist in Windows as a literal scaling percentage, but it had "Large Fonts" as an option which acted as a system-wide scale. VB GUIs were scalable based on twips (device-independent unit). The entire form and all controls would scale according to the Large Fonts setting.
Many of my VB6 forms were resizable. There was a simple library that let you have anchors in the Tag property so you didn't have to write any sizing logic yourself.
This really shows the value of saying “no” to use-cases you consider peripheral.
If your customers live in one country, and you don’t care about cloud scalability, things can be much simpler.
Of course, some applications really do need all the complexity.
Even today many apps still fit perfectly within those constraints. I'd gladly accept a fixed layout and no internationalization if that would mean sitting down and writing a rich app with one single dependency (!), zero boilerplate setup, and easy deployment.
Qt Designer can do visual design for flexible layouts quite well.
> The simplicity and efficiency of Visual Basic UI programming relied on several assumptions that became obsolete in 2000
This is a great point that extends beyond rebutting the rose-colored glasses for the gool ole days of programming. While yes, things were simpler. That simplicity came at a cost. For instance, how accessible were VB apps to people who had sight-related disabilities?
> how accessible were VB apps to people who had sight-related disabilities?
Coincidentally, they were very accessible because they used corresponding Win32 components for all logical UI entities, despite being fixed in layout. Therefore, they worked really well with screen readers.
Sadly, this is not the case with UI frameworks, which render the screen as a Vulcan/DirectX/OpenGL canvas. By the way, for today's Electron-based apps, you can use WAI-ARIA (or similar) standards to achieve a similar level of accessibility.
2 replies →
More accessible by default than modern electron-based apps
> Everything in the VB UI editor was based on a fixed layout. There was a fixed font size, fixed DPI-density display expectation, and fixed button sizes. Every dialog assumed fixed sizes and was non-resizable
Yes, everything in the layout was fixed, unless you chose to resize it through code
I've developed many applications in VB that dynamically resized every control to maintain a consistent UI regardless of the window size
I mean, simple things like this
textarea.width = form.width - ( textarea.left * 2 )
to keep it centered and preserved the margins
Granted, for complex layouts, it quickly evolved into a dedicated procedure to resize all controls in the correct order and handle edge cases. But it was absolutely doable, even by an amateur teenage programmer
I think other IDEs (Delphi maybe?) had anchors and other helpful features to assist with resizing
Delphi was superior to VB even back in the day, and is still around, as is Lazarus. C# WinForms is actually closest to that, not to VB - and is also still around.
It's not surprising, Delphi and C# design were both led by the same person, Anders Hejlsberg. (He then went on to design Typescript.)
I find Qt Creator to be quite comparable to the experience I remember with e.g. VB6. Have you tried it?
Yeah if you know c++ decently, you can whip up a basic app pretty quickly.
Works with python too, you can build a desktop UI for your app in an hour
Delphi, C++ Builder, and there are still other ones around like Xojo.
Problem is the amount of Electron crap nowadays.
> I am still shocked how no tool since has managed to come even close to VB
Over on OS X/macOS, Xcode's Interface Builder carried this torch a long way until Apple introduced SwiftUI. Windows developers just didn't notice because it was a different platform.
It was also very easy to build the visual aspect, tying it together was step 3 for me. It felt more like a mix of designing and powerpoint than programming in the beginning of a project. Very fast visual results to keep your momentum.
Take a look at the twinBASIC programming language. VB6 compatible and can import VB6 source code and forms and adds modern features too.
I did some iphone development around 2010. The interface builder in xcode was pretty powerful. You could set up multiple screens and hook them up to eachother with drag and drop.
[dead]