In 1990 we had drag and drop UI creation, double-click on the button and write the code behind it. Where did we go wrong?
All the VB-style development and developers moved to the web, but the web's layout paradigm is fundamentally reflowing-resizeable-document-based, not the drawable, draggable absolute positioning of dialog box controls.
Not to mention the fact that code was now split into three languages on the front end and one or two on the back end. You can't just write code to respond to a button click to read from the database, because now you need an API and authentication and all that...
I'm sure there are a few exceptions, but VB was never used for "traditional" app development in the first place -- you weren't going to write a Photoshop or Word in VB, or even something small like a CD ripper or a music player, since it was so cumbersome to access any of the Win32 API's -- and performance wasn't anywhere close to C/C++ either.
VB was used for business apps that connected to databases, and those apps really did just entirely move to the web. It was such a gigantic benefit that web apps were inherently cross-platform, didn't have to be installed or deal with different versions of binaries, and could add new features instantly for everyone.
And Microsoft inadvertently hastened the transition by making VB.NET backwards-incompatible with VB6, at just the time that web apps had become capable enough. Since all this software was going to need to be rewritten to some degree anyways, might as well rewrite it for the web sooner than later, and get all those new benefits.
There was no single language back then. Node.js wasn't even an idea at that point.
And regardless, you've still got to learn HTML and CSS and often SQL.
Or for really perverse IE only stuff, VBScript in ASP and VBScript in the browser.
Delphi had layout, so did Java (many of them). Resizable was always a thing, aside for the extremely lazy development with null layouts by some programmers.
VB used to be considered a lame/toy language with its "onerror resume next" paradigm.
Do you prefer more lines written by hand? Or more frameworks?
Because those are meant to offset each other.
If native app ecosystems had as much invested in them (monetarily and people-hours) as the web ecosystem has, it would easily blow away anything you can currently do with a browser, and it'd be much easier. But investment got steadily and increasingly redirected to the web, while simultaneously progress was being held back by the limitations of the web.
Native app ecosystems benefit from the fact that they are a singular computing and OS target. Web apps have to work on everything. It's the same reason gaming consoles tend to have a wider variety of AAA games than PCs. It's easier to optimize for the PS5 or Switch and call it a day, than it is to port a game to work on 6 year old video cards and get it to work on Mac (both ARM based and x86 based), Windows, and Linux. A web dev has to inherently target thousands of different devices, dozens of different operating systems, 3 or 4 browsers, and dozens of screen resolutions, and cannot make any assumptions about what type of input devices are available.
Oh, and they also have to assume an async programming environment with intermittent connectivity, and possible throttled connections as low as 100-200 kbps, so try to keep the bundle size under 100KB to keep time to first paint under 1s, mmkay?
Even Windows 95 apps could assume a few dozen MBs loaded in via disc, and count on cached assets being available on disk.
So maybe mobile phones are just not meant to be tools for actual work, despite of what marketing departments of phone manufacturers tell us?
Qt has a visual designer that's less intuitive to use than VB was, but on the other hand you don't need to write all that resizing code by hand, or to be stuck with a fixed size window.
https://learn.microsoft.com/en-us/dotnet/desktop/winforms/hi...
VB forms were something that was very easy to get started with, and then took forever to actually polish. If you wanted to make things pretty you'd spend ages adjusting positions by hand.
If you want to make a fixed layout you still can with modern tools. The difference is that instead of painfully adjusting everything by hand because something is longer in Spanish and doesn't fit, you can just resize the window in the IDE and be done in 10 seconds.
Many of us grew tired of being locked in to Microsoft's platform, their simple yet stifling assumptions and their hostile behavior.
Those who walked away from Microsoft's Omelas went in a thousand different directions. While some grew tired of being pioneers and returned or found new walled gardens, others refused to trade their freedom for comfort or simplicity.
As for running the software the platform has a proprietary license obviously but you can host your own Retool backend from which to serve the apps to your end users (check the docker repo). This is an alternative to the SaaS/cloud based app hosting at https://retool.com/.
There's a free tier to edit and run the apps but professional usage will have a license fee. This is not unlike making an app with VB which required buying VB and having end users buy and run Windows.
I've worked in multiple C# shops with both WinForms and WPF. Everyone in the WinForms shop hated it due to the enforced designer usage, and everyone in the WPF shop only used the designer as a preview window and never directly used it to build anything.
I can't speak for the C++ side of things.
Also, I think I read a few times on other HN threads, somewhat recently, that the GUI development scene on Windows is a mess these days, because MS changes the recommended framework every now and then. Is that true?
[1] By framework, here, I mean the layer such as WinForms or WPF, that GUI developers program to.
Someone correct me if I'm wrong, I've been in WinForms land for a while (unfortunately).
I can't believe there's no browser-based point and click software that lets you build web apps in JS.
Prototyping for a dB backed app is extremely easy.
I'm fully aware of all it's drawbacks, but there's still nothing like it available today.
But yeah, both tools are great for in-house applications in my experience. It’s quite easy to provide actually useful features very quickly. It might not win you design awards, but often that’s not a problem in reality.
I’d rather have an inventory that is correct but maybe looks a bit homegrown than one that looks like it has been designed by Jony Ive but is wrong for example.
Much of your point seems debatable. I had a band director that was able to write a GUI app in 1992 on a 12MHz 80286 with a couple megabytes of memory. Put today's tooling in their hands and I don't think they'd be nearly as effective. Today's tools may be better by some definitions, but certainly not by all.
building a UI now with modern tools makes me lose sleep