Comment by thw_9a83c
6 months ago
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.
> But I do find myself often yearning for the "simplicity" of desktop app development.
Yep, isn't it great to use an API that is actually all about UI widgets, rather than having to indirect through a document markup language.
I've been doing development using JavaFX, Swing's successor, for many years. It's got its quirks, and places where the dev team stopped iterating on the API a little too soon; but it works and does some really nice stuff.
Swing is still a thing, at least for all of those using JetBrains products, and still comes wiht the JDK, whereas JavaFX was placed into open source, and I think it only carries forward thanks to Gluon's work.
In what concerns layout managers in .NET, you could do it in Windows Forms via TableLayoutPanel and FlowLayoutPanel.
WPF has always used layout managers from the get go, which is why its drag and drop workflow feels strange to Windows Form devs.
3 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.
And to add to that, because some people might not know or have forgotten, colors where easily adjustable in winforms, so dark mode, high contrast mode, green, blue, hot pink etc. were all easily adjustable for all these apps and back in th day that was pretty standard to do for visually impaired people. No extra work from programmers was necessary, so vastly superior to today where you have to beg for good dark mode support.
1 reply →
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