We are perfectly capable of writing native GUIs, and we have powerful tools for it as well. QTDesigner comes to mind as a well known example.
The problem is, about 12 years ago, application design went through a gameification and "toy-i-fication" phase, from which it has yet to recover, because suddenly, everything had to look like it was designed for tablets or gaming consoles. Then the "javascript for everythiiiing!" happened, and suddenly the tools and workflows behind all the bloated, inefficient, low-information-density apps were swept into the desktop world.
But, since the modern definition of an "App" is basically everything that is displayed on a phone ever, and devices got so powerful that no matter how badly devs f* it up it still kinda-ish works (if we ignore the battery screaming for dear life), and this situation has generally been accepted.
Even before that, application design was usually terrible. Apps were almost universally ugly. Developers just aren't very good at it; it's not in their skill sets. They're good at making apps fast and small, but not at making them usable.
Rare companies would hire separate designers, and the apps could be functional and attractive, but they were the exception. It was a lot of money for something generally considered ancillary.
Browser-based apps get to leverage the work done by browser makers, who put in the effort to make toolkits that looked nice by default. They're not small or fast -- though Moore's Law has made them usable anyway. They also favor the things that designers like -- including not overwhelming the user with dense information. You can still use them badly, but by default any programmer can make an app that isn't awful.
There never was a golden age when developers made good, small, fast apps. It was usually a "pick two" situation, except by spending a lot of money. I'm just as happy to let my battery scream and not cringe at every single app that comes up, and so cheaply that they can give it away or cost dollars rather than tens or hundreds. Others disagree, of course, but I think the market tends to show a heavy thumb on one side of that scale.
I don't know which apps you are talking about, but I use apps built and designed by developers every day, and they all work great.
My problems start when Apps are NOT designed by developers, but rather people who have seen 100 videos about color theory, and know all the latest fonts their social media du jour is excited about, but very little about hardware, programming, and the difference between localhost and accessing a server over cheap WiFi from somewhere else on the planet.
Because these are the "apps" which do something ridiculously simple, but somehow manage to eat up 2-3GiB of RAM and let the laptops fans spin out of control.
>They're not small or fast -- though Moore's Law has made them usable anyway.
Moores Law is over however, and there is no justification for an app that, say, plays locally stored mp3s to require 2GiB of RAM and 10% CPU. If an application thinks this is justified, it will get to know my good friend `rm -rf`, beacause I have vlc running in ncurses mode right now, playing my entire playlist, and its eating less memory than the terminal emulator it's running in ;-)
The answer to bad software, and overloaded/overused/oversold frameworks is not "built more powerful computers" but "make better software".
>There never was a golden age when developers made good, small, fast apps.
Good != Beautifully designed.
Good means small, fast, portable, reliable, easy to install, easy to learn, easy to remove, does its job.
The registers at B&H photo in NYC appear to be some DOS terminal system, but the employees know the keyboard shortcuts by muscle memory and the interface’s reaction time is instantaneous. If that’s not good software I don’t know what is.
From the people who make choices about where to put their money. You can get away with ugly software -- especially if you had something that worked 20 years ago and is still sufficient, and there is no alternative. But if users have the choice of something attractive, they'll pick it.
I have the choice of many many many text editors and IDEs to manage my source code.
What do I use? vim. In a terminal(-emulator).
Why? Because I like my editor to be ready the moment my finger leaves the ENTER key, I like direct interoperability with the terminal, I like that I can hack together even the most absurd things in .vimrc, and I like that I have the same editor with the same settings on all servers I take care of, even when I connect to them via ssh.
I also use vlc for playing audio and video. Are there players that have a more edge UX? Sure. Do they come with builtin-full support for almost all formats, have a tiny memory footprint, can be used to convert stuff, don't spy on me and can be controlled via a terminal (hello ncurses mode!)? Nope.
However, after compiling it and measuring it on an older machine (a Lenovo T430 running Arch) against the out-of-the-box vlc install, I can see no advantage in memory footprint or cpu usage, they are about the same. (I compared mvp running in terminal against vlc running with ncurses interface module)
Since mpv doesn't offer an ncurses interface, and is still in development, I will, for now, stick with vlc.
However, the scripting options definitely seem great, as I said i will keep it on my radar.
Maybe you compiled yours with all the bells&whistles which aren't needed for sufficient local playback?
Furthermore I didn't cover (re-)streaming to chromecasts, TVs, or such. Don't have it, don't want it.
This has next to zero impact on its performance, as the ncurses player talks exactly to the parts of libVLC it has to.
>Instantly. Sometimes on even older systems than yours. With probably less RAM. Say 8GB, with something booted from USB, running 'live', so only 7GB, no SWAP.
The system I tested this on has 4GiB of RAM. And I have used `VLC -I ncurses` from live systems-on-a-stick as well. It runs before my finger leaves the ENTER key, same as mpv.
> Maybe you compiled yours with all the bells&whistles which aren't needed for sufficient local playback?
I'd be happy to repeat the measurement with different settings.
Another viable option would be Visual Tcl [2] for Tcl/Tk [3]. Given the event-based nature of Tcl and Tk, I find it matches well for a methodology like VB provided.
And it's far from the only one I remember (although you'll need to do some research here [4]). For example, Komodo IDE used to have a Tk GUI builder that provided for the same kind of methodology, which has been split off in [5].
Enjoy!
[0] https://www.lazarus-ide.org/
[1] https://www.freepascal.org/
[2] http://vtcl.sourceforge.net/
For me - the sweet-spot that I used for all of my own personal projects after outgrowing VB1-6 was... Borland Delphi.
The IDE/designer was at least as good as VB - but the Object Pascal language was so powerful. It was truely object-oriented and if one wanted, one could work at a high level of abstraction. Yet it could also natively drop-down to low-level Windows API's, and handle pointer-based work if necessary.
Unfortunately - for my professional career, Delphi never captured the large-scale Enterprise market - that went to .NET or Java and the rest is history...
(Occasionally I noodle about with FreePascal for the nostalgia factor)
Granted we still had MFC, but then the COM lovers at Microsoft started pushing for ATL, and everything that followed from there.
On the other side we had (and still have) Delphi and C++ Builder, but Borland's management killed the indie culture around them.
From the late 1980s until the mid-2000s GUIs had all kinds of standardized visual cues, context sensitive help, UIs usable by both mouse and keyboard, standard interface designs across apps, data binding, and most of all WYSIWYG GUI design software that worked exceptionally well. We had this on 80286 CPUs with 1MiB of RAM and similarly tiny machines.
Today's desktop UIs are a fucking disaster on both the developer side and the user side.
For developers you have a choice between a hypertext language hacked endlessly into a UI and native UI tooling that's far less intuitive and much uglier than what we had back then. Compare the UI designer (not the language) in Visual Basic in the 1990s to today. You could not only design but data bind a complex app that looked decent in 30 minutes.
For users you have no consistency, no keyboard shortcuts (or different ones for every app), no help or help that only works online, etc.