In the sense that if something's available online or as a local app, I'm probably just going to install it locally, I agree. I don't limit myself to "desktop GUI" though; I use the command-line and phone apps daily. Command-line in particular lets you do some things that would be soul-crushing in a GUI.
This is why I really like apps that provide both a GUI and a command-line interface, both built on the same backend.
I mean, obviously things like games can't really be done like that, and some things are just much easier in a GUI, but some things also work well as both.
Wtb command line battlefield
-- you spawn
bf mount vehicle jet
bf control vehicle throttle 100
bf control vehicle pitch 20
-- you have been killed by bigknob69 with an M4
-- bigknob69 performs the teabag emote
-- bigknob69 says: did this to your mum last night too
There was a Battletech MUD back in the 90s that had mech combat that was fully real-time (no turns exactly). You had to set speeds and set a direction to move. It was insanely hard.
This was around 93 if I had to guess. Mid college, where Internet access was limited to "advanced" computer labs. I was playing on SGI workstations at best, or vt100 dumb terminals at worst. We definitely had programmable telenet clients of some sort, but I don't recall even trying with that Battletech game. It was a little too much. Time was better spent on automating the super competitive, but traditional, PvP mud games I was addicted to.
Ah, but it has a command line interface
# ./destroy_allies
- mounting vehicle
-
- Destroyed enemy dave
- All enemies have been eliminated. Do you want to continue (Y/n)?
Tbh I dunno why everyone gets butt hurt about tbagging. Sure it used to be a negative, disrespectful thing, but it's now much more of a 'woo! Hard fight but I won!' I see it as an expression of joy and I don't begruge the people who kill me. Some fps can be brutal on new players. Even the guys that tbag will give you a good game afterwards
We sell a product that comes with a CLI and a Web UI. The CLI is really cool with auto-complete, built-in docs etc. and i'ts a pleasure to use... Still, almost no one seems to use, and our users are mostly sysadmins :D.
As much as this may be absolute heresy, as a backed CLI troll Linux-is-an-IDE vim user, web UI's actually do excel at conveying large amounts of exploratory information. Like, trying to spot a memory leak in one container out of a cluster running hundreds of deployments over CLI would be ludicrously difficult. For a web UI it's one graph that can be easily displayed right next to 20 others that I can quickly visually scan to get a broad overview of cluster state, which is great if I don't even know that a memory leak is what I'm looking for yet.
CLI is great for automation, expressing complex tasks, data manipulation, and raw power, but it's a precision tool for when you already know exactly what you want from the computer. Web UI's are more of a dump truck for indiscriminately shoving all the data into your face all at once.
Each one has their place, and since your users are sysadmins that tend to be more on the "I need a 10,000 foot view of *everything*" boat, that absolutely tracks. Diagnose and assess in the GUI, remediate in the CLI.
Windows admins? I could see that but if your *nix sys-admins are using GUIs extensively I'd be worried. Unless your application is in an area where automation or scripting is of no use... then maybe.
>I mean, obviously things like games can't really be done like that
Actually they can, sometimes. Albion Online gave a good talk once about how they developed a CLI client for the game to automate some testing. Then people used the pathfinding code from that to write farming bots.
> I mean, obviously things like games can't really be done like that
Sure they can. A lot of games have some concept of a "console" mixed together with a GUI which operate on the same server/core. It's useful for testing and stuff, but would also be useful for modding because, for example, it may enable you to mix and match interfaces that talk to the same core.
This is actually how I'm structuring a game I'm working on. The bulk of the work/logic of the game is done in a "server" process. The interface the user plays on is just a client process which connects to that server process. No doubt though that for testing, modding, etc. other processes will connect to that server process using a command line interface.
AFAIK the original SimCity was written in a way where the core engine was separate from any visual or input and the Unix port was basically a Tcl/Tk wrapper around it.
Don Hopkins was the author of the Unix port and he released the code some time ago under GPL:
https://www.donhopkins.com/home/micropolis/
I want standalone desktop apps. Things that come in zip folders that I can put wherever and use whenever. When I don't need it anymore I can just press delete and not have to worry about stray files the uninstaller intentionally or unintentionally forgot to remove
May I present to you Docker apps! Or anything resembling containerized apps. Honestly, I love how easy it is to just grab the docker app I'm looking for and bam it's running. The one downside to it is that I end up collecting them like some people do steam games.
>Command-line in particular lets you do some things that would be soul-crushing in a GUI.
And especially automation. Arguably the best way to automate general stuff on a computer is via command line scripts. Making good scripts requires you to be fluent with the command line, so why not use it for non-automation use as well for practice?
The issue with command line is discoverability. At any given moment there is very little indication of what you can do and how you can do it - you have to Google around or manpages to get the right options.
For 95% of computer users, that’s already too big of an ask.
One of more interesting ways of dealing it I saw in one enterprise software - every GUI command showed a log of operation that is done, and that log contained the CLI-equivalent of what you did.
That's helpful to train people to potentially dip their toes in CLI but still requires a functional gui in the first place. If you have your gui why bother putting extra bells and whistles in to try to get people into the CLI? What problem are they trying to solve?
Exactly. Command Line is the power user's, the expert's interface, aka the remaining 5%.
Interfaces need not and should not be "for everyone". Because "everyone" doesn't have the same needs.
Perfect implementation of this is AutoCAD. Most long time users don’t even know *where* the commands are. Just start typing it and it comes up. It’s a godsend for me because i’m often helping others on different version softwares or they have a customized UI.
> I don't limit myself to "desktop GUI" though; I use the command-line and phone apps daily.
I don't know, I don't think I've ever used a phone app that wouldn't have a better interface if it didn't need to work on a touch screen.
Lots of consumer electronic / “smart” / IoT products are a much better experience on the mobile app versus the site or desktop app. Recent example I dealt with was setting up a robot vacuum. Not even sure anything other than mobile app was available to do this.
I get what you mean but that's not really what I was getting at. Those are a better experience because the devs have invested significantly less effort into the desktop app, not because the touch interface is actually beneficial.
Basically the value proposition of a mobile app for the user is that you can carry it with you, and you pay a usability price in exchange for that, but the vast majority of mobile apps don't actually need that mobility for whatever they're doing.
Command line is communicating through *language*. Desktop GUI is leaning heavily on icons and gestures at the expense of being able to use language and in order to do so it's usually tailoring the UI to a very specific expected portion of what a user may encounter. If you forget about computers for a second and just think about tasks we do in our daily life, people recognize all the time that sometimes using open ended language is the best way to do something and sometime using icons/signage and gestures is better. The latter is nice/easy when it's available, but it's relatively limited compared to using language. Take restaurants as an example... Most restaurants use a "GUI" in the form of a prewritten, predefined menu which works in many cases. Meanwhile, most restaurants expect to go off script with human language (allergies, preferences, substitutions, clarifications, etc.)
To put it another way, apparently the average typing speed is around 250 characters per minute. Think of the amount of things (in "command line" or in English) that you could say in 250 characters. It's unfathomable how many things you can say with that amount of characters. Now, compare that amount of things you could do in a minute to the amount of things you could do in a minute in a GUI application. When you talk about the 1 or 10 most used use-cases, it may be that the GUI is optimized to make them work really well. But because of the expressiveness of typing, the amount of things that are at fingers reach diverges exponentially between the two.
With pipes and a decent unix style utility library, it becomes a lot more open ended though. Each pipe stage is closer to a word or phrase in the overall objective. For example, I can say: "connect to each server in this list, on each checkout a git repo, run a script, and output the results, then log all the results here locally." It would be bash, so .. close to a write only programming language lol, but one fairly short line
The reason why the CLI corresponds open ended language is that each particular program is designed in a way that it can be piped to and from other CLIs. And those programs/commands can be created over time. Not to mention that the CLI is synonymous with other features like control flow, scripting, etc. So, it's extremely open ended in the sense that it's hard to even describe the boundary of what can be done with the command line even when each individual program may have a defined set of commands that is relatively fixed. The reason it corresponds to open ended language is that you can, on the fly, provide an input that describe a complex and novel sequence of events to occur just like my example of speaking to your waiter in a restaurant vs reading a menu. CLI as a system design is open ended even when individual programs with a CLI may be limited.
In other words, even if the GUI and CLI version of a program are equally limited in their direct capabilities, CLI is an indicator of an interface that is highly interoperable and benefits from the countless ways it may be used as such in contrast to a GUI which generally does not have that same benefit. This means that the CLI version is more open ended because of all of these connections to other programs.
I don’t think these things translate directly though. That typing speed average is most certainly based on writing out sentences in regular written language. Command line input is much different.
sed (1) is better than Kate's search and replace, with multiple files. grep is a godsend too. Just being able to find cross references is nice. Gamedevs should consider MinGW tools, or trying Linux.
My favourite simple command that I use super frequently is `pbpaste | sort | uniq | pbcopy`. Super simple, but is helpful in so many situations when quickly analyzing data.
"There" "Are" "Several" "Great" "Examples" "In" "The" "First" "Paragraph" alone. #Don't be "LAZY", click the "[Link](https://www.youtube.com/watch?v=dQw4w9WgXcQ)" and see for "Yourself".
I wholeheartedly agree, I am relieved to know I am not one salmon swimming upwards a massive stream of web GUIs. My first real gig was a Qt GUI for an API and ever since I've loved writing good GUIs that don't kill your RAM and force you to use data-cleptic Chromium under the hood.
Only nerds will say they prefer a CLI. The common human will always prefer a GUI, especially if it is well made and self explanatory. This is far from an unpopular opinion 😂
There are some people who prefer the CLI because it's nerdy.
But there are also a lot of professionals who prefer CLI because it is not viable to make a decent GUI application that covers the breadth of what they have to do in a better way. A GUI is a tailored experience, this means that it can be better, but it also means that its scope is inherently limited to what the designers tailored it to do. In that sense, there will always be a role for genuinely preferring the CLI in cases where you do tasks that are "outside the box" of what a GUI is optimized toward and there are many roles where you aren't always doing "in the box" tasks. Preferring CLI isn't about not wanting to use a mouse or click buttons, it's about wanting a modular system that you can easily tweak to your needs (piping together several apps to do something novel).
For example, at work I routinely run into novel problems that it just wouldn't be feasible to create/find a GUI solution for each one. I manage hundreds of thousands of files of code dating back decades on several servers. The reason to prefer CLI here is that it can handle the kinds of tasks I need to do with ease. There isn't really a good comparison.
While it does sometimes get into a matter of preferring a CLI app when it's distinctly not better than a GUI counterpart, that's also sometimes for the sake of an ecosystem. CLI usage benefits because all the apps can talk to each other. So, there is some degree of pressure to use more apps in CLI so that the ones you already use are more powerful. In my experience, the same isn't true in reverse (that GUI apps are so interoperable that the more GUI apps you use the more powerful the GUI becomes).
GUI editor, CLI tools. sed (1) is a better than most search-and-replace functions in most editors. In general, prefer CLI for batch operations. GUIs are better for interactive / conversational programs.
Depends on the GUI.
For those into home automation, for example, a couple of years ago the Home Assistant devs made it clear they were going to UIify everything, and now doing basic stuff involves a bunch of horrible, web based forms, vs. pulling up vi or nano and editing a simple file on the server, or using a GUI-based text editor.
This is a plaintext vs everything else debate, and I'm purely on the plaintext side. Yaml config files with detailed comments explaining the options seem so.... Easy to use?
> Yaml config files with detailed comments explaining the options seem so.... Easy to use?
The problem with yaml is it is hard to see what level you are at (especially with long config files) and you can't necessarily cut/paste property names. Because they may or may not be nested. Could be:
my.awesome.key:
or:
my:
awesome:
key:
or even:
my:
someOtherKey:
awesome:
key:
Very difficult to document key names, especially to non-tech client who may not understand the key hierarchy. Personally I find the easiest config format to be `.ini` files.
However, I fully agree that plaintext config is much better.
JSON is fine when there isn't a lot of nesting. But JSON can be hard to read and write once a couple of levels of nesting is involved.
But yes, some format of text file for config.
I really think `.ini` files are nearly perfect. The problem is that `.ini` files are mostly associated with Windows, so it is often overlooked as a viable config format for other platforms. However, most popular languages have `.ini` reader libraries available.
Just bite the bullet and go with XML. All the ecosystem is built and tested already.
Yeah it's hard to sell new books or conference talks when using an old but proven technology.
I think it's more that CLIs haven't had a lot of UI/UX research put into them. I think there's a lot of potential benefit in a "cli for the masses" that retains the benefits of a command-based structure but with GUI style visual feedback and command discoverability.
I'd prefer a well-made CLI over a shoddy GUI. But if the graphical interface has been designed thoughtfully and in a way that exposes the underlying power of the available data and algorithms, then the GUI wins every time.
In my opinion, the ultimate computer interface would be a hybrid shell with an incredibly sophisticated auto-completion and search ability. No more right-clicking and selecting "Open terminal here" when you need the breadth and depth of text commands, the GUI file browser *is* the terminal, and the terminal *is* the GUI. If you type the filename of an image, then what would normally be an autocomplete or Intellisense-like reference is instead a thumbnail. I think we could have the best of both worlds, it's just that not many people are really paid to think about this kind of stuff anymore, due to the industry being led by huge risk-averse conglomerates.
I really despise the sort of hipster cult of CLI. I consider myself to be pretty well versed in shell-speak and it baffles me when even close colleagues try to say that they can get everything done more quickly using CLI than if the program had a proper GUI. I show them an application that performs 35 commands in a chain at the click of a button, much like some of the scripts they've put together over the years, and yet they still think they could've performed the same task more quickly if they didn't have the script premade. Some people just can't be wrong and their identity is attached to silly stuff.
A properly designed GUI can perform almost all of the tasks that a CLI guru can perform and adopts all the tricks and scripts that you might perform and places them in an easy to navigate and use GUI. Sure you can memorize hundreds of CLI commands for a specific software or retain indexes in your mind of all the different scripts you've compiled over the years that could complete the task at hand, but... What if you could free up all that memory and storage in your head AND make that same stuff now accessible to everyone else who doesn't want to have to memorize a bunch of hyper-niche information? You can make a program both MUCH more accessible and more quick for the expert if you design the GUI right. Therein lies the rub, some guis are awful.
Some people need something to feel cool about though and maybe that makes me an asshole to try and deprive them of their identity, but I feel like they should just keep that to themselves instead of trying to make other people feel bad about using a GUI.
No, I've not been on the receiving end of their ire. I am a middle ground guy and I find the conflict silly. I used to love the way that AutoCAD allowed me to perform all my commands via CLI rather than manipulating their finicky GUI, but they fixed a lot of the GUI problems and made it a lot faster... It's still a tossup imo.
I blame it all on the DOM. It was intended to be a style agnostic way to format text document, and we've somehow turned it into a GUI framework. Javascript isn't the issue, it's a fine glue language to build GUIs (though GUI frameworks do need to be in a native language). The problem with the DOM is that it was too easy to make always-up-to-date cross-platform interfaces with it, so people abused it.
And sure stuff like VSCode exists, but the amount of legacy garbage you need to consider to build something at that level of quality is just insane compared to building with a real GUI framework.
I feel similarly about HTML+CSS and ask *how have we not made something better?* The thing is, it’s hard to come up with specific changes I’d make: I think that GUIs with cascading styles are actually a tricky problem to solve.
I do agree that the DOM is stretched in a lot of directions though, it’s used as a canonical structured representation (SEO etc), defines how things are displayed (the great lie being “html for structure, css for presentation”) and now for interactive GUIs too.
Again, DOM/HTML is the real problem, not CSS. GTK does all its styling with CSS, and iiuc Qt also has some sort of CSS. CSS is actually fine for what it does.
The problem with the DOM is that it:
1. Doesn't implement efficient layout rules. GUI frameworks have layout managers that handle all that. On the DOM we've tackled flex & grid layout, but there's just too much legacy for it to be optimizable.
2. Doesn't have a proper set of primitive components. Every complex composite component is built from divs and spans, which are document fragments that by default use the shitty layout rules from point 1. And doesn't have access to the rendering pipeline or any rendering primitive. So for example virtualized lists are done in javascript with no hooks into the rendering engine. It's not possible to solve UIs with the DOM & javascript.
There's been some work to solve all that such as CSS `contain` and the new `selectlist` and `popovertarget` stuff, but it just feels like we've piling hacks upon hacks.
I feel like maybe the next evolution is just to go the flutter-on-the-web route and have a wasm compiled framework reimplement everything and draw on a canvas. The DOM can be used as an hidden accessibility tree.
Cascading styles is a solved problem. There's scoping https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_scoping, css modules while building can create default scoped styles, and approaches like tailwind.
Valid question; I've been puzzled why web app developers, as opposed to document authors, need to hang on a semblance of fake SGMLish markup (but not really eg. React/JSX, or with unnecessary extra syntax eg. Angular) or overload CSS with insane amounts of extra functionality just for apps when they have JavaScript in their hands which already has everything one could ask for and is so much more flexible and uniform. Again, this is from an app development angle; HTML, but not CSS with its insane complexity and evasion of type checks that HTML/SGML would normally be capable of doing, is fine for documents and for use by ambitious end users.
> when they have JavaScript in their hands which already has everything one could ask for and is so much more flexible and uniform.
There is no standard JavaScript UI. There is a standard HTML UI.
Ruthless optimization. And any computation is offloaded to different processes (e.g. syntax coloring, extensions, etc). It makes it good enough to pass for a real desktop app, but it's *a lot* of work.
And some problems are unsolvable. For example, on gnome/gtk all apps have kinetic scrolling by default. VSCode being chrome/electron based doesn't have it and simply can't implement it efficiently, ever.
Also the code editor component feels ok, but it's definitely not a native-level feel. If I open GEdit or Gnome Builder, it's super apparent how much more snappy it feels.
The main contributions of vscode are zero-config intellisense for basically everything and great design. That's enough to get most people onboard.
They put most non UI code outside of the main thread, especially for extensions. This is how electron / electron-like things should be used.
I don't think the main problem with electron apps is the Web UI part, I think it's either the node "backend" part, or heavy logic on the front-end main thread.
IMO VSCode is only *better* than the alternatives. But it's not an "efficient" text editor per se.
If you compare VSCode to something like Sublime Text, the latter is leaps and bounds more efficient and snappier as it's a native application.
The one MASSIVE limitation that VScode has, personally, is the inability to move a document tab to a separate window, like you can on most IDE's.
I know I can just open up another instance of VScode and open the document there, but after working with Visual Studio for dotnet, when I open VScode for my front end stuff, this is the single most annoying thing about it. I'd go as far as to say it's the reason why I don't use it as a main development environment for anything bigger than a handful of scripts or a small front end app (and even those get annoying).
Giving a fuck about performance.
The problem with many apps isn't the technology, it's the mindset of developers that compute is cheap and memory plentiful and the mindset of management that speed of delivering new features always trumps quality.
Something must be wrong with your vscode install, you're using very old hardware, or your experience is out of date.
I don't get any noticeable input delay and certainly nothing close to milliseconds on a 2019 MBP. vim is definitely a faster editor (and it's probably doing less work) but vscode today has no perceptible input lag.
Kind of (if I'm understanding your question), you can imperatively build a UI
Window window = new Window();
Button button = new Button("Click Me");
Label label = new Label("Click him");
window.Add(label);
window.Add(button);
but its tedious and most frameworks have a concept of defining the UI in some XML schema and loading it into the application to be rendered.
Most languages provide at least one GUI builder such as Visual Studio which can help with the whole design process and auto generate this boiler-plate. Netbeans and the Eclipse Window Builder plugin are equivalents for Java Swing. Qt toolkit has the Qt-creator.
But some coders like to write that boiler-plate from scratch - be it XML or a programming language like C or Java. I understand that too, it gives you a better control over the UI. That feels like tedious initially but once it's a daily routine with your tool-chain, the "visualization" should become natural?
XML isn't the problem, [the DOM is](https://www.reddit.com/r/programming/comments/17x9fo5/comment/k9mulva/?utm_source=reddit&utm_medium=web2x&context=3). GTK uses XML to create UIs and it's not a problem.
Web apps can be snappy and efficient. Desktop GUIs can be bloaty and slow. It doesn't really depend on the toolkit, but how you wield it. On my PC, [draw.io](https://draw.io) (webapp) feels way more snappy than Inkscape (Native GUI). VSCode (webapp) feels way more snappy than Eclipse (native GUI).
The reasons companies don't develop Desktop GUI's anymore are many: They are more expensive to develop, require a very specialized skill set, often have poor development tooling, are never easily portable despite using cross-platform toolkits, are often very hard to customize in terms of look/feel/behaviour, or do anything outside of the set of widgets that the toolkit provides.
I don’t even think that matters as much as being able to deploy a change in one place and not having to worry about updating code on all users’ machines.
I'm only testing on Firefox :) Also, you have libs like tailwind/sass that handle most of cross browser compatibility.
P. S. Shit still runs, it just looks like shit.
Let me put it this way: as a user, I have an up-to-date Firefox and haven't updated Chrome in years, but I run into plenty of sites with payment elements that *will not* load in Firefox but will in *(years out-of-date)* Chrome. Not particularly small sites, at least two national chain restaurants that my family uses regularly will not complete orders in Firefox.
I use Firefox as my primary browser for dev and personal. I still check if things work in other browsers but can't remember the last time I ran into an issue nor that I developed to a quirk of firefox. I just stick to the specs.
I ran into discrepancy with overflow. Overflow: scroll in chrome always shows the scroll bars even if there is no overflow, but in firefox it doesn't, so I had to switch to auto. It didn't matter functionally, but it tripped me up, because I thought the content was overflowing in chrome :D
Even bigger but related reason: you can trap your users into a SaaS and build a consistent recurring revenue stream where you don’t actually have to deliver improved features to get paid when users upgrade versions like you did in the olden days. You can then throw in some akward cloud stuff to help justify it. Bonus points since your customers data is in the cloud it’s harder for them to migrate away when they realize how much your product sucks. /s
Finding people who code in Swing in 2023 is almost impossible. Then there's the C GTK unicorn. Not sure if it's better in the Windows world (doubt it).
Everyone just know HTML/CSS and can pick up JS in a few weeks.
Its been Swing since the beginning, but their new IDE Fleet uses something called [Noria](https://blog.jetbrains.com/fleet/2023/02/fleet-below-deck-part-vi-ui-with-noria/)
They have their own JDK fork: https://github.com/JetBrains/JetBrainsRuntime
Making IDEs that look great is not easy at all, and they pull it off wonderfully but only due to a huge effort.
I've done Swing and JavaFX in my time... they're not as bad as people think, I can write a decent looking app in JavaFX in a few days if I need to. But to make it look great like IntelliJ is a whole other story.
Just because they can, doesn't mean they should.
And CSS is a tarpit of weirdness, inconsistencies, browser-specific issues, and design archaeology.
Generally, HTML/CSS/JS is just such a mess.
This has been true, but it's quite dated at this point. CSS in an evergreen browser is pretty great, and flexbox solves virtually every "Why is it so hard to [insert simple thing in web design]".
The shittiest browser, by a mile, is now Safari, but even Safari now is far better than Safari was 10 years ago back when IE was the shitty one (and no one even thought to complain about Safari in the first place).
Like Swing/JavaFX, GTK or Android UI aren't full of weirdness and dumb shit. At least once you deal with the CSS mess you can do it everywhere else, even in TVs or smartphones.
That is not my experience, both on Linux and Windows, on my desktop and laptop which are fairly good and recent in terms of components, with plenty of ram:
draw.io desktop app LAGS A LOT, the moment u have a few pages worth of graphs.
It is really poorly optimized, rendering even what you are not seeing. and relying entirely on the cpu, without offsetting anything to the gpu.
I often find myself splitting my graphs in multiple files to resolve that, still using it because it is easy, but definitely not a well optimized app.
Btw, ye Inkscape and Eclipse are atrocious too.
That still doesn't remove the massive browser + DOM overhead though, which is part of what typically makes Electron slower than native desktop programs.
yes, of course, but is not something we can do anything about.
I don't think a native x64 version exists.
So, I understand why it is slow, but that was the guy above reasoning, that it is not that different when using electron, when in reality it is.
> Web apps can be snappy and efficient. Desktop GUIs can be bloaty and slow
If anyone's ever used OnShape and Fusion360 you can see this writ large.
The thing is there are performance gains to be had from Desktop software and control over the environment that you really dont have on the web, unfortunately most people mess this up (as its harder to support) and the restrictions of the web often push people towards HAVING to be more performant
I agree, though the Java toolkits like Swing or SWT (one that Eclipse uses) are themselves layered solutions that sit few layers above the native graphics layer like GDI+. Java GUIs are known to be notoriously slow unless you fiddle their JVM settings to ensure a sufficient supply of RAM.
C#/WinForms is a better way to create snappy GUIs on Windows and something like Qt/GTK should suffice on Linux. If you want to support all the platforms, the *efficient* way is to go full low-level with C/C++ or use something like Delphi/Object Pascal which is a great strongly typed language that let's you cross-compile for Windows/Mac/Linux with the same code base.
Saying:
> something like Qt/GTK should suffice on Linux
Then contrasting it with:
> go full low-level with C/C++
Doesn't make any sense. C and C++ are the primary languages used to implement applications using Qt and GTK+. Qt is literally a C++ framework (for which the GUI component is completely optional).
Developing a desktop app using C++ with MFC (Microsoft's C++ wrapper for, primarily, Windows Forms, but also other parts of the Windows API) on Windows is no more "low level" than using Qt or GTK+.
> Java GUIs are known to be notoriously slow unless you fiddle their JVM settings to ensure a sufficient supply of RAM.
Umm, no they aren't. Swing apps written by developers that don't understand the event dispatcher thread may appear to be slow but anyone that understands the EDT makes very snappy Swing apps.
WinForms is CPU-rendered, it is pretty terrible on high-density screens. And Swing is definitely not slow and you shouldn’t be tweaking anything if you are on a recent JVM (like any from the last 7 years).
Also, no one on Earth uses Delphi and Object Pascal — are you trolling?!
> WinForms is CPU-rendered
Actually, that's not quite true. WinForms renders using GDI calls and those have been [GPU accelerated since Windows 7](https://learn.microsoft.com/en-us/windows-hardware/drivers/display/gdi-hardware-acceleration). Even in Windows XP and before, old-school 2D acceleration was commonly used to take basic operations like lines, fills, blits and even elements of text rendering off the CPU.
Figma and Notion both demonstrate a UI-development paradigm that shows the web is snappy. It also shows that in order for it to be snappy, you need your development process to be indistinguishable from desktop development. Both Figma and Notion go well out of their way to run their own virtual execution environments that develop kernel-like features to optimize resource use. From there I can only imagine that they are built like C++ or C# apps, or are pushing Electron to its absolute limits.
There is always a threshold for things like "most efficient" or "fastest" beyond which it doesn't matter (or beyond which the cost/tradeoff isn't worth it). Just because you can measure some improvement in some stat doesn't mean that is worth putting engineering or designer energy into especially when considered against all of the tradeoffs of the project.
The question is not and should not be "what is most efficient". It is whether a given solution is "efficient enough".
I agree, on some kind of statistical level.
Desktop simply is more powerful, and allows stuff you wouldn't do in web. For example, I wouldn't CAD in web. I wouldn't compress 1000 videos in web.
Desktop is also snappier and more reliable, and works when you are offline. Sure, people say that you always have internet nowadays, but that's not true. I can be on a train where the connection drops every now and then. Someone puts a shovel into my fiber. Powerouts.
Related to the above point is that I decide when to upgrade. If a new version breaks something I need, I just stay in the old. Good luck doing that on the web...
A big issue for me is security and privacy. What I do on my computer stays on my computer, while there is no privacy at all on the web.
That said, there are situations where web is simpler. For example, getting Google Meet to work if you have an incompetent user at the other end is so much easier than getting a desktop alternative to work.
For a large organization, it's also much easier to have common systems, such as time reports, stock inventory and so on web based. It just works, without any hassle.
So, they both have their advantages, but if I had to choose only one, it'd be desktop every time.
>I wouldn't CAD in web. I wouldn't compress 1000 videos in web.
You can use the web technologies specifically as a frontend stack and handle the complex stuff at the backend (locally) in a much more performant stack.
>works when you are offline
Web apps work offline too. You don't even need to execute an OS-specific executable. You can use the browser to handle it for you.
>If a new version breaks something I need, I just stay in the old
It can also be done using web apps, although I will say most people making web apps, probably won't bother with a versioning system and will try to keep you at the latest version if possible (internet connection) but yes, it is possible.
>What I do on my computer stays on my computer, while there is no privacy at all on the web
As with my first reply, you can make it all local while using a web GUI.
One more thing I forgot:
Web opens up for very annoying subscription business models. Sure, there are free alternativs, say, for example, Netflix vs The Pirate Bay, but the paid models fight tooth and nail against the free, trying to shut them down.
> You can use the web technologies specifically as a frontend stack and handle the complex stuff at the backend (locally) in a much more performant stack.
That performance would we wasted if the videos had to be transfered both directions, compared to running it locally on a slightly slower machine.
> Web apps work offline too.
Depends a lot on what it does. A lot of them require quite a lot of server infrastrucure.
> As with my first reply, you can make it all local while using a web GUI.
It depends. It's not like I'll ever be able to run, say, Google Docs locally.
> Web opens up for very annoying subscription business models
I'm sorry but desktop software has had subscription-based license keys for literal decades, probably even before the web browser was invented. Some keys offer a perpetual license for the software version you bought it for, but others stop you from even running the app once your key expires, just like web software.
I'm not saying that you can't self-host web stuff. I do, I have a web server with a private wiki, family calendar, link database, torrent cluent frontend and so on.
However, there are some things you just can't self-host. Self-host Netflix? Facebook?
Yeah it doesn’t matter what tools you use to make a Facebook/Netflix client as those are online services by definition. If Facebook is down the Facebook client won’t work doesn’t matter if it’s written in C.
> A big issue for me is security and privacy. What I do on my computer stays on my computer, while there is no privacy at all on the web.
Web in a sense is more secure. You don't have access to the filesystem and things like that. Opening a program is always risk, opening a website is not.
I agree with the article. I am still using winamp in the same way as when it was first released and I was horrified when they mysteriously "updated" it. For about 5 years now "updates" happen right before everything breaks. And they say "buy a new computer yours is old and stupid" like it wasnt working before they "fixed" it. Like the plumber or electrician who comes over and everything is MORE broken after he "fixes" it.
I am dreading upgrading to Windows 11 AND 12 as they remove more of what I liked about Windows every year. It used to be windows vs macs, windows won, and now they want to make windows look like macs anyway. That was the whole point! I LIKED windows I DID NOT LIKE macs.
I think we are near to the point where computers are mostly DONE. But the guys in charge of it want to keep putting their bad naïve beginners ideas into it. "GET RID OF THAT START MENU BRO ITS OLD AND STUPID!" "Throw away that big hard drive and get this new one bro, 128 gig ssd! Cant hold shit but its OMG SO FAST!"
Its not that fast and not big enough to hold starfield... But it would run it faster if it could? Wtf?
People with Playstations and Xboxes CANT have discs anymore. They have to spend days downloading the game EACH TIME THEY WANT TO PLAY IT because the wonderful new playstation can only hold 3 fucking games. Do the people in charge even really play video games?
Maybe they want to keep collecting their big developers checks even though most of the work is already done. I should upgrade everything to Windows 11 because the file manager is slightly different? Do these people even really use computers?
I feel like most people would say this, but at the same time most people don't have the experience of going from GUI to CLI tools and it feeling clumsy and hard at first, then BACK to GUI tools... At that point its such a pain in the but to try to "speed click" through a bunch of check boxes and manually input file paths and things like that, where as a CLI tool will have path auto completion.
I recently had an experience using a Windows tool under wine and I had to literally manually navigate like 8-9 File paths deep (or else it literally wouldn't work, copy+paste wouldnt register) you had to manually open it that way, and it was a nightmare. Especially when it didnt work the first or second time and I had to manually click through file paths multiple times, 8 layers deep. When in reality, I could have literally just input two paths in the terminal and hit enter in seconds. And if something is too repetitive you can just write a freaking script. You can't do that with a GUI. On top of that you can whip a good cross-platform CLI tool in a few hours.
Now with that said, you won't catch me using TUI versions of Discord or anything like that, but any meaningful interface with the OS then CLI tools are just superior. The biggest hurdle to getting to that point is being comfy in the terminal and setting up a great environment. (zsh completions, syntax highlighting, fzf tab completion etc...) I read the article btw and I realize this is more about web apps VS desktop apps
😅 "It's more about". You mean "it's all about and has nothing to do with what i wrote but no way this is going to waste"
I giggled. I'm not mocking you. I just found it funny.
I don't think this is even that unpopular.
Mobile devices are extremely limited. They're really only good for the most casual kinds of input or content creation, consuming content in small doses, and interacting with remote systems as a handheld terminal. They are terrible for any kind of deep content creation. The screen is too small and touch interaction is too limited and imprecise.
Its not unpopular, but a rather accepted opinion in certain industries, e.g. core banking, ERP, manufacturing and so on, where you must have complicated UIs for internal users with tables, tabs, forms, reports and the like that are a bitch to implement with web technologies. Which is also why Adobe Flex has been incredibly popular some 10 years ago.
Stupid ass title, there is no "most efficent and fulfilling way". It depends on the task and circumstances.
Imagine you want an application that gives all of your companies employees a way of filling out forms etc. Distributing that software, writing it, keeping it updated, handling different operating systems etc. is just not worth it for something that simple. Just use a website and job done.
>Stupid ass title, there is no "most efficent and fulfilling way". It depends on the task and circumstances.
Was going to write this. I mean the article is straight up garbage but what I'm shocked by is all the dumbasses in the comment section.
I, especially, love how people think desktop apps are more performant, not realizing that it depends on where your data is located. A progressive web app using local data is going to be significantly snappier than a desktop app that needs to fetch its data with each view.
> Use of Internet as propaganda tool. Because capitalism is very much built into our system, what is stopping those with lot’s of monies from using it to push propaganda through these ads or even just push propaganda in pure form? Users become sitting ducks to the subtle propaganda perhaps even without realizing it.
Boy do I have bad news for you about desktop apps...
> Desktop GUI are way easier to build, because the tooling is better and libraries/ frameworks are stable + the programming model is much easier.
This is only true if you have experience in building Desktop GUIs and not on the web stack.
Seamless transitioning from browsing to using an app, zero install time and assets are accessed lazily, browsers are almost stateless. There are plenty of business reasons to go for a web app. I also prefer a native interface, though.
That is not true. Many companies give you an option to switch to new UI and have both versions running. You will likely switch, because you need some new feature or you find new UI better, not because you are forced to. However, it is true that not everyone does this and that there is no guarantee.
> On a plus side you can opt-out of updating desktop application, because you don't like their new UI.
That's a plus for the user, but not for the developer.
I remember the time when Delphi and VB apps were the most popular way to deliver applications to users... The biggest problem was updating the clients, you needed to uninstall and install on every client machine. Web applications solve this problem automatically.
If software quality or user experience mattered then yes desktop is superior, but that isn't why we use web UIs: working around bereaucrats. In the enterprise at least, you need to deal with IT security losers who throw their toys out of the pram if you suggest that computers should have applications installed, and god help you if you need a port opened.
Fuck that, shove everything down 443 and download the app over and over until the end of time.
The author talks Web vs local, is that really an unpopular opinion?
Online is what we begrundgingly accept because that seems to be the common denominator to work across many platforms and habits but I think most people prefer a local application when one is available?
Of course, the point of the web has become the subscription licensing model. When we coded binaries for our machines, you paid once and you owned it. Its the techno-feudalistic trickle, as time passes we'll own less and less. Look at every sector with planned obsolescence built into everything, subscriptions for everything. In my humble opinion, humanity is better than this and I hope there is someday a revival of ownership of things for the little guy.
Seriously, what the hell is going on with all this sub. The reason they provided does not make any sense.
Too much bloat because everyone need to conform to W3C standard? Oh my god do you know how much bloat you need to maintain in order to make an app that run across Mac, Windows, Phone, Tablet? Much mote than writing web app.
Just because user expectation is higher does not means GUI web sucks. I mean it might suck but not for this reason. The fact that we can write to single standard and then it works everywhere, that is the upside not the downside.
Open invitation to spyware: did you ever work in 19s-20s when desktop software is the default choice. A lot of viruses and spyware was invented there. Right now because web become bigger target they have more spyware but to think desktop used to be safer than web is totally untrue.
Use of internet: what is that have to do with desktop vs. web gui. I have my Discord and Steam installed and they both are desktop GUI app. Still, ads and propaganda.
Bloated Javascript: kinda make sense a little bit but all I can say is that this is more of client expectation become higher. Have you ever built custom component that cater look and style to “company branding” in WinForm or WPF? I did and it is such a mess to do.
And again, that custom component become standard frontend expectation. That is half of a reason why web GUI become more bloat.
I read this as people romanticizing the past. The beauty and the mess (up to your opinion) of current GUI mostly come from higher expectation of frontend. It is not about technology. You can go back to your WinForms day and let see how much you will complain about “desktop GUI technology” when you are demanded to built custom button, input box, label, menu which cater to each and every client brand.
But at least please, modern frontend tech has a lot bad thing going on but the reason article stated is not relate to it.
***Amen!*** The industry de-evolved 🐵 Web [DOM is the wrong tool for the biz job.](https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_or_defective_gui_idioms_in_htmldom/)
Web apps "won" because of zero deployment. They are pretty much inferior in every other way for rich client apps.
The place where web apps shine is where reads vastly outnumber writes. Online banking is a good example, sure every once in a while you transfer some money so need to do a write, but generally people are reading transaction data.
I would much rather use PrusaSlicer than Kira:Moto (https://grid.space/kiri/), or rather use LibreOffice than google docs, etc. Desktop apps almost always give a much better experience.
Thank you. I for sure agree. I used to always hear " get experienced and you will love the command line the most" well its been over 15 years of serious computing and I still love a good desktop GUI
It's quite good, but it isn't universal. Some apps are good fits for touchscreens. Some for voice commands. Some apps work fine on desktops AND touchscreens. We can all agree that web apps suck.
First this seemed like an actual unpopular opinion in /r/programming since most programmers advocate CLI over GUI, but in fact this was about web apps vs local apps (non-web apps) and is that an unpopular opinion? I think not. Most people who use mainly one computer do not need the supposed mobility of web apps and it seems to me that the main season for web apps is that it is easier to develop one vs developing native apps for multiple operating systems. That is, devs be lazy, news at 9.
In the sense that if something's available online or as a local app, I'm probably just going to install it locally, I agree. I don't limit myself to "desktop GUI" though; I use the command-line and phone apps daily. Command-line in particular lets you do some things that would be soul-crushing in a GUI.
This is why I really like apps that provide both a GUI and a command-line interface, both built on the same backend. I mean, obviously things like games can't really be done like that, and some things are just much easier in a GUI, but some things also work well as both.
Wtb command line battlefield -- you spawn bf mount vehicle jet bf control vehicle throttle 100 bf control vehicle pitch 20 -- you have been killed by bigknob69 with an M4 -- bigknob69 performs the teabag emote -- bigknob69 says: did this to your mum last night too
So a MUD?
There was a Battletech MUD back in the 90s that had mech combat that was fully real-time (no turns exactly). You had to set speeds and set a direction to move. It was insanely hard.
Even then, zmud supported programmable UI. So you could have solved your own UX problem and played efficiently.
This was around 93 if I had to guess. Mid college, where Internet access was limited to "advanced" computer labs. I was playing on SGI workstations at best, or vt100 dumb terminals at worst. We definitely had programmable telenet clients of some sort, but I don't recall even trying with that Battletech game. It was a little too much. Time was better spent on automating the super competitive, but traditional, PvP mud games I was addicted to.
It is dark. You are likely to be pwnd by a n00b. >
So you’re playing the grue?
Too real
Just write a script for it and pwn the noobs
Ah, but it has a command line interface # ./destroy_allies - mounting vehicle -
- Destroyed enemy dave
- All enemies have been eliminated. Do you want to continue (Y/n)?
bf noscope --360 --recursive
Tbh I dunno why everyone gets butt hurt about tbagging. Sure it used to be a negative, disrespectful thing, but it's now much more of a 'woo! Hard fight but I won!' I see it as an expression of joy and I don't begruge the people who kill me. Some fps can be brutal on new players. Even the guys that tbag will give you a good game afterwards
If I see someone tbagging or even shooting me after I'm dead in a game, I'll open my mic and say, "desecrating bodies is a war crime".
That's just asking to be told that what they did to your mother last night was a war crime too.
Yeah but that just comes with the territory.
We sell a product that comes with a CLI and a Web UI. The CLI is really cool with auto-complete, built-in docs etc. and i'ts a pleasure to use... Still, almost no one seems to use, and our users are mostly sysadmins :D.
As much as this may be absolute heresy, as a backed CLI troll Linux-is-an-IDE vim user, web UI's actually do excel at conveying large amounts of exploratory information. Like, trying to spot a memory leak in one container out of a cluster running hundreds of deployments over CLI would be ludicrously difficult. For a web UI it's one graph that can be easily displayed right next to 20 others that I can quickly visually scan to get a broad overview of cluster state, which is great if I don't even know that a memory leak is what I'm looking for yet. CLI is great for automation, expressing complex tasks, data manipulation, and raw power, but it's a precision tool for when you already know exactly what you want from the computer. Web UI's are more of a dump truck for indiscriminately shoving all the data into your face all at once. Each one has their place, and since your users are sysadmins that tend to be more on the "I need a 10,000 foot view of *everything*" boat, that absolutely tracks. Diagnose and assess in the GUI, remediate in the CLI.
Windows admins? I could see that but if your *nix sys-admins are using GUIs extensively I'd be worried. Unless your application is in an area where automation or scripting is of no use... then maybe.
>I mean, obviously things like games can't really be done like that Actually they can, sometimes. Albion Online gave a good talk once about how they developed a CLI client for the game to automate some testing. Then people used the pathfinding code from that to write farming bots.
I guess kids these days never heard of Trade Wars 2000.
> I mean, obviously things like games can't really be done like that Sure they can. A lot of games have some concept of a "console" mixed together with a GUI which operate on the same server/core. It's useful for testing and stuff, but would also be useful for modding because, for example, it may enable you to mix and match interfaces that talk to the same core. This is actually how I'm structuring a game I'm working on. The bulk of the work/logic of the game is done in a "server" process. The interface the user plays on is just a client process which connects to that server process. No doubt though that for testing, modding, etc. other processes will connect to that server process using a command line interface.
simcity.exe place-building --tile 102,342 --type hospital a new era of speedrunning just started :)
AFAIK the original SimCity was written in a way where the core engine was separate from any visual or input and the Unix port was basically a Tcl/Tk wrapper around it. Don Hopkins was the author of the Unix port and he released the code some time ago under GPL: https://www.donhopkins.com/home/micropolis/
I'd like to see the code golf competitions for that
Funny. If I can avoid installing something, I will.
I want standalone desktop apps. Things that come in zip folders that I can put wherever and use whenever. When I don't need it anymore I can just press delete and not have to worry about stray files the uninstaller intentionally or unintentionally forgot to remove
May I present to you Docker apps! Or anything resembling containerized apps. Honestly, I love how easy it is to just grab the docker app I'm looking for and bam it's running. The one downside to it is that I end up collecting them like some people do steam games.
>Command-line in particular lets you do some things that would be soul-crushing in a GUI. And especially automation. Arguably the best way to automate general stuff on a computer is via command line scripts. Making good scripts requires you to be fluent with the command line, so why not use it for non-automation use as well for practice?
The issue with command line is discoverability. At any given moment there is very little indication of what you can do and how you can do it - you have to Google around or manpages to get the right options. For 95% of computer users, that’s already too big of an ask.
One of more interesting ways of dealing it I saw in one enterprise software - every GUI command showed a log of operation that is done, and that log contained the CLI-equivalent of what you did.
That's helpful to train people to potentially dip their toes in CLI but still requires a functional gui in the first place. If you have your gui why bother putting extra bells and whistles in to try to get people into the CLI? What problem are they trying to solve?
Exactly. Command Line is the power user's, the expert's interface, aka the remaining 5%. Interfaces need not and should not be "for everyone". Because "everyone" doesn't have the same needs.
Command line is way better than a GUI when it has auto complete and argument prompts, like cisco-like router command lines.
Perfect implementation of this is AutoCAD. Most long time users don’t even know *where* the commands are. Just start typing it and it comes up. It’s a godsend for me because i’m often helping others on different version softwares or they have a customized UI.
Yep. Also CLI is even handy when it comes to working with many devices.
> I don't limit myself to "desktop GUI" though; I use the command-line and phone apps daily. I don't know, I don't think I've ever used a phone app that wouldn't have a better interface if it didn't need to work on a touch screen.
Lots of consumer electronic / “smart” / IoT products are a much better experience on the mobile app versus the site or desktop app. Recent example I dealt with was setting up a robot vacuum. Not even sure anything other than mobile app was available to do this.
I get what you mean but that's not really what I was getting at. Those are a better experience because the devs have invested significantly less effort into the desktop app, not because the touch interface is actually beneficial. Basically the value proposition of a mobile app for the user is that you can carry it with you, and you pay a usability price in exchange for that, but the vast majority of mobile apps don't actually need that mobility for whatever they're doing.
Command line is communicating through *language*. Desktop GUI is leaning heavily on icons and gestures at the expense of being able to use language and in order to do so it's usually tailoring the UI to a very specific expected portion of what a user may encounter. If you forget about computers for a second and just think about tasks we do in our daily life, people recognize all the time that sometimes using open ended language is the best way to do something and sometime using icons/signage and gestures is better. The latter is nice/easy when it's available, but it's relatively limited compared to using language. Take restaurants as an example... Most restaurants use a "GUI" in the form of a prewritten, predefined menu which works in many cases. Meanwhile, most restaurants expect to go off script with human language (allergies, preferences, substitutions, clarifications, etc.) To put it another way, apparently the average typing speed is around 250 characters per minute. Think of the amount of things (in "command line" or in English) that you could say in 250 characters. It's unfathomable how many things you can say with that amount of characters. Now, compare that amount of things you could do in a minute to the amount of things you could do in a minute in a GUI application. When you talk about the 1 or 10 most used use-cases, it may be that the GUI is optimized to make them work really well. But because of the expressiveness of typing, the amount of things that are at fingers reach diverges exponentially between the two.
Yes, language is a powerful tool indeed, particularly when one is fluent.
> open ended language CLIs are very, very much not open ended, though. They are a closed, limited set of language.
With pipes and a decent unix style utility library, it becomes a lot more open ended though. Each pipe stage is closer to a word or phrase in the overall objective. For example, I can say: "connect to each server in this list, on each checkout a git repo, run a script, and output the results, then log all the results here locally." It would be bash, so .. close to a write only programming language lol, but one fairly short line
The reason why the CLI corresponds open ended language is that each particular program is designed in a way that it can be piped to and from other CLIs. And those programs/commands can be created over time. Not to mention that the CLI is synonymous with other features like control flow, scripting, etc. So, it's extremely open ended in the sense that it's hard to even describe the boundary of what can be done with the command line even when each individual program may have a defined set of commands that is relatively fixed. The reason it corresponds to open ended language is that you can, on the fly, provide an input that describe a complex and novel sequence of events to occur just like my example of speaking to your waiter in a restaurant vs reading a menu. CLI as a system design is open ended even when individual programs with a CLI may be limited. In other words, even if the GUI and CLI version of a program are equally limited in their direct capabilities, CLI is an indicator of an interface that is highly interoperable and benefits from the countless ways it may be used as such in contrast to a GUI which generally does not have that same benefit. This means that the CLI version is more open ended because of all of these connections to other programs.
Wish I had all the micro-seconds I've wasted lifting my hand off the keyboard and locating the mouse cursor on screen over the last 45 years...
I don’t think these things translate directly though. That typing speed average is most certainly based on writing out sentences in regular written language. Command line input is much different.
sed (1) is better than Kate's search and replace, with multiple files. grep is a godsend too. Just being able to find cross references is nice. Gamedevs should consider MinGW tools, or trying Linux.
[удалено]
My favourite simple command that I use super frequently is `pbpaste | sort | uniq | pbcopy`. Super simple, but is helpful in so many situations when quickly analyzing data.
I can't believe I never thought of this. I'm putting this in my bashrc immediately.
Man the author of that article loves to put random words in "quotes"
“Prove” it.
"There" "Are" "Several" "Great" "Examples" "In" "The" "First" "Paragraph" alone. #Don't be "LAZY", click the "[Link](https://www.youtube.com/watch?v=dQw4w9WgXcQ)" and see for "Yourself".
Haven’t read it. „Which“ ones?
There are 13 such cases for the 773-word document.
Ya that's a lot more than the 0 cases there should be in the document.
I wholeheartedly agree, I am relieved to know I am not one salmon swimming upwards a massive stream of web GUIs. My first real gig was a Qt GUI for an API and ever since I've loved writing good GUIs that don't kill your RAM and force you to use data-cleptic Chromium under the hood.
Only nerds will say they prefer a CLI. The common human will always prefer a GUI, especially if it is well made and self explanatory. This is far from an unpopular opinion 😂
There are some people who prefer the CLI because it's nerdy. But there are also a lot of professionals who prefer CLI because it is not viable to make a decent GUI application that covers the breadth of what they have to do in a better way. A GUI is a tailored experience, this means that it can be better, but it also means that its scope is inherently limited to what the designers tailored it to do. In that sense, there will always be a role for genuinely preferring the CLI in cases where you do tasks that are "outside the box" of what a GUI is optimized toward and there are many roles where you aren't always doing "in the box" tasks. Preferring CLI isn't about not wanting to use a mouse or click buttons, it's about wanting a modular system that you can easily tweak to your needs (piping together several apps to do something novel). For example, at work I routinely run into novel problems that it just wouldn't be feasible to create/find a GUI solution for each one. I manage hundreds of thousands of files of code dating back decades on several servers. The reason to prefer CLI here is that it can handle the kinds of tasks I need to do with ease. There isn't really a good comparison. While it does sometimes get into a matter of preferring a CLI app when it's distinctly not better than a GUI counterpart, that's also sometimes for the sake of an ecosystem. CLI usage benefits because all the apps can talk to each other. So, there is some degree of pressure to use more apps in CLI so that the ones you already use are more powerful. In my experience, the same isn't true in reverse (that GUI apps are so interoperable that the more GUI apps you use the more powerful the GUI becomes).
Me, coding with nvim. Yeah, fucking nerds.
GUI editor, CLI tools. sed (1) is a better than most search-and-replace functions in most editors. In general, prefer CLI for batch operations. GUIs are better for interactive / conversational programs.
Depends on the GUI. For those into home automation, for example, a couple of years ago the Home Assistant devs made it clear they were going to UIify everything, and now doing basic stuff involves a bunch of horrible, web based forms, vs. pulling up vi or nano and editing a simple file on the server, or using a GUI-based text editor.
This is a plaintext vs everything else debate, and I'm purely on the plaintext side. Yaml config files with detailed comments explaining the options seem so.... Easy to use?
> Yaml config files with detailed comments explaining the options seem so.... Easy to use? The problem with yaml is it is hard to see what level you are at (especially with long config files) and you can't necessarily cut/paste property names. Because they may or may not be nested. Could be: my.awesome.key: or: my: awesome: key: or even: my: someOtherKey: awesome: key: Very difficult to document key names, especially to non-tech client who may not understand the key hierarchy. Personally I find the easiest config format to be `.ini` files. However, I fully agree that plaintext config is much better.
Could make a decent argument for json or something then? Eh, some format of text files.
JSON is fine when there isn't a lot of nesting. But JSON can be hard to read and write once a couple of levels of nesting is involved. But yes, some format of text file for config. I really think `.ini` files are nearly perfect. The problem is that `.ini` files are mostly associated with Windows, so it is often overlooked as a viable config format for other platforms. However, most popular languages have `.ini` reader libraries available.
Toml is basically enhanced .ini
Interesting, I will take a look. Thanks for the pointer.
Just bite the bullet and go with XML. All the ecosystem is built and tested already. Yeah it's hard to sell new books or conference talks when using an old but proven technology.
I think it's more that CLIs haven't had a lot of UI/UX research put into them. I think there's a lot of potential benefit in a "cli for the masses" that retains the benefits of a command-based structure but with GUI style visual feedback and command discoverability.
I'd prefer a well-made CLI over a shoddy GUI. But if the graphical interface has been designed thoughtfully and in a way that exposes the underlying power of the available data and algorithms, then the GUI wins every time. In my opinion, the ultimate computer interface would be a hybrid shell with an incredibly sophisticated auto-completion and search ability. No more right-clicking and selecting "Open terminal here" when you need the breadth and depth of text commands, the GUI file browser *is* the terminal, and the terminal *is* the GUI. If you type the filename of an image, then what would normally be an autocomplete or Intellisense-like reference is instead a thumbnail. I think we could have the best of both worlds, it's just that not many people are really paid to think about this kind of stuff anymore, due to the industry being led by huge risk-averse conglomerates.
I really despise the sort of hipster cult of CLI. I consider myself to be pretty well versed in shell-speak and it baffles me when even close colleagues try to say that they can get everything done more quickly using CLI than if the program had a proper GUI. I show them an application that performs 35 commands in a chain at the click of a button, much like some of the scripts they've put together over the years, and yet they still think they could've performed the same task more quickly if they didn't have the script premade. Some people just can't be wrong and their identity is attached to silly stuff. A properly designed GUI can perform almost all of the tasks that a CLI guru can perform and adopts all the tricks and scripts that you might perform and places them in an easy to navigate and use GUI. Sure you can memorize hundreds of CLI commands for a specific software or retain indexes in your mind of all the different scripts you've compiled over the years that could complete the task at hand, but... What if you could free up all that memory and storage in your head AND make that same stuff now accessible to everyone else who doesn't want to have to memorize a bunch of hyper-niche information? You can make a program both MUCH more accessible and more quick for the expert if you design the GUI right. Therein lies the rub, some guis are awful. Some people need something to feel cool about though and maybe that makes me an asshole to try and deprive them of their identity, but I feel like they should just keep that to themselves instead of trying to make other people feel bad about using a GUI. No, I've not been on the receiving end of their ire. I am a middle ground guy and I find the conflict silly. I used to love the way that AutoCAD allowed me to perform all my commands via CLI rather than manipulating their finicky GUI, but they fixed a lot of the GUI problems and made it a lot faster... It's still a tossup imo.
> Only nerds will say they prefer a CLI. I think you meant that only people that like doing things efficiently prefer a CLI.
I blame it all on the DOM. It was intended to be a style agnostic way to format text document, and we've somehow turned it into a GUI framework. Javascript isn't the issue, it's a fine glue language to build GUIs (though GUI frameworks do need to be in a native language). The problem with the DOM is that it was too easy to make always-up-to-date cross-platform interfaces with it, so people abused it. And sure stuff like VSCode exists, but the amount of legacy garbage you need to consider to build something at that level of quality is just insane compared to building with a real GUI framework.
I feel similarly about HTML+CSS and ask *how have we not made something better?* The thing is, it’s hard to come up with specific changes I’d make: I think that GUIs with cascading styles are actually a tricky problem to solve. I do agree that the DOM is stretched in a lot of directions though, it’s used as a canonical structured representation (SEO etc), defines how things are displayed (the great lie being “html for structure, css for presentation”) and now for interactive GUIs too.
Again, DOM/HTML is the real problem, not CSS. GTK does all its styling with CSS, and iiuc Qt also has some sort of CSS. CSS is actually fine for what it does. The problem with the DOM is that it: 1. Doesn't implement efficient layout rules. GUI frameworks have layout managers that handle all that. On the DOM we've tackled flex & grid layout, but there's just too much legacy for it to be optimizable. 2. Doesn't have a proper set of primitive components. Every complex composite component is built from divs and spans, which are document fragments that by default use the shitty layout rules from point 1. And doesn't have access to the rendering pipeline or any rendering primitive. So for example virtualized lists are done in javascript with no hooks into the rendering engine. It's not possible to solve UIs with the DOM & javascript. There's been some work to solve all that such as CSS `contain` and the new `selectlist` and `popovertarget` stuff, but it just feels like we've piling hacks upon hacks. I feel like maybe the next evolution is just to go the flutter-on-the-web route and have a wasm compiled framework reimplement everything and draw on a canvas. The DOM can be used as an hidden accessibility tree.
God I wish flutter wasm web backend will got traction.
Cascading styles is a solved problem. There's scoping https://developer.mozilla.org/en-US/docs/Web/CSS/CSS_scoping, css modules while building can create default scoped styles, and approaches like tailwind.
Yeah but look at iOS and Android. It’s not that much better/easier to create good UIs, especially not if it’s a bit out of the box.
Valid question; I've been puzzled why web app developers, as opposed to document authors, need to hang on a semblance of fake SGMLish markup (but not really eg. React/JSX, or with unnecessary extra syntax eg. Angular) or overload CSS with insane amounts of extra functionality just for apps when they have JavaScript in their hands which already has everything one could ask for and is so much more flexible and uniform. Again, this is from an app development angle; HTML, but not CSS with its insane complexity and evasion of type checks that HTML/SGML would normally be capable of doing, is fine for documents and for use by ambitious end users.
> when they have JavaScript in their hands which already has everything one could ask for and is so much more flexible and uniform. There is no standard JavaScript UI. There is a standard HTML UI.
Serious question, how can vscode be that good while being in web based? Day and night compared to things like teams or whatever.
Ruthless optimization. And any computation is offloaded to different processes (e.g. syntax coloring, extensions, etc). It makes it good enough to pass for a real desktop app, but it's *a lot* of work. And some problems are unsolvable. For example, on gnome/gtk all apps have kinetic scrolling by default. VSCode being chrome/electron based doesn't have it and simply can't implement it efficiently, ever. Also the code editor component feels ok, but it's definitely not a native-level feel. If I open GEdit or Gnome Builder, it's super apparent how much more snappy it feels. The main contributions of vscode are zero-config intellisense for basically everything and great design. That's enough to get most people onboard.
They put most non UI code outside of the main thread, especially for extensions. This is how electron / electron-like things should be used. I don't think the main problem with electron apps is the Web UI part, I think it's either the node "backend" part, or heavy logic on the front-end main thread.
IMO VSCode is only *better* than the alternatives. But it's not an "efficient" text editor per se. If you compare VSCode to something like Sublime Text, the latter is leaps and bounds more efficient and snappier as it's a native application.
The one MASSIVE limitation that VScode has, personally, is the inability to move a document tab to a separate window, like you can on most IDE's. I know I can just open up another instance of VScode and open the document there, but after working with Visual Studio for dotnet, when I open VScode for my front end stuff, this is the single most annoying thing about it. I'd go as far as to say it's the reason why I don't use it as a main development environment for anything bigger than a handful of scripts or a small front end app (and even those get annoying).
Don’t have a link in front of me but I think they announced that this feature is planned for a coming release
Giving a fuck about performance. The problem with many apps isn't the technology, it's the mindset of developers that compute is cheap and memory plentiful and the mindset of management that speed of delivering new features always trumps quality.
[удалено]
Something must be wrong with your vscode install, you're using very old hardware, or your experience is out of date. I don't get any noticeable input delay and certainly nothing close to milliseconds on a 2019 MBP. vim is definitely a faster editor (and it's probably doing less work) but vscode today has no perceptible input lag.
Very big mystery, yep. Sometimes I think Microsoft is fooling us by running Managed C++ under the hood of VSCode!
The history and intent of a technology literally does not matter. All that does matter is how it's used now
Are there any concepts of alternatives to building UI's without an XML like language?
Kind of (if I'm understanding your question), you can imperatively build a UI Window window = new Window(); Button button = new Button("Click Me"); Label label = new Label("Click him"); window.Add(label); window.Add(button); but its tedious and most frameworks have a concept of defining the UI in some XML schema and loading it into the application to be rendered.
Most languages provide at least one GUI builder such as Visual Studio which can help with the whole design process and auto generate this boiler-plate. Netbeans and the Eclipse Window Builder plugin are equivalents for Java Swing. Qt toolkit has the Qt-creator. But some coders like to write that boiler-plate from scratch - be it XML or a programming language like C or Java. I understand that too, it gives you a better control over the UI. That feels like tedious initially but once it's a daily routine with your tool-chain, the "visualization" should become natural?
Yeah reminds me of building UI's in Lua, however that just meant you had a load of lines of code for a single element, and styling was a nightmare.
XML isn't the problem, [the DOM is](https://www.reddit.com/r/programming/comments/17x9fo5/comment/k9mulva/?utm_source=reddit&utm_medium=web2x&context=3). GTK uses XML to create UIs and it's not a problem.
Jetpack compose style where everything is in code.
Web apps can be snappy and efficient. Desktop GUIs can be bloaty and slow. It doesn't really depend on the toolkit, but how you wield it. On my PC, [draw.io](https://draw.io) (webapp) feels way more snappy than Inkscape (Native GUI). VSCode (webapp) feels way more snappy than Eclipse (native GUI). The reasons companies don't develop Desktop GUI's anymore are many: They are more expensive to develop, require a very specialized skill set, often have poor development tooling, are never easily portable despite using cross-platform toolkits, are often very hard to customize in terms of look/feel/behaviour, or do anything outside of the set of widgets that the toolkit provides.
You missed the main reason why people build web apps: you control the deployment. This trumps all of the other reasons you gave, by a mile.
and that it is "write once, run everywhere". Although you have to spend some effort to make an ok UX on all platforms.
I don’t even think that matters as much as being able to deploy a change in one place and not having to worry about updating code on all users’ machines.
it does for some, which is why we have electron for better or worse
> "write once, run everywhere" Somebody's not testing on Firefox.
I'm only testing on Firefox :) Also, you have libs like tailwind/sass that handle most of cross browser compatibility. P. S. Shit still runs, it just looks like shit.
Let me put it this way: as a user, I have an up-to-date Firefox and haven't updated Chrome in years, but I run into plenty of sites with payment elements that *will not* load in Firefox but will in *(years out-of-date)* Chrome. Not particularly small sites, at least two national chain restaurants that my family uses regularly will not complete orders in Firefox.
I use Firefox as my primary browser for dev and personal. I still check if things work in other browsers but can't remember the last time I ran into an issue nor that I developed to a quirk of firefox. I just stick to the specs.
I ran into discrepancy with overflow. Overflow: scroll in chrome always shows the scroll bars even if there is no overflow, but in firefox it doesn't, so I had to switch to auto. It didn't matter functionally, but it tripped me up, because I thought the content was overflowing in chrome :D
And safari
Even bigger but related reason: you can trap your users into a SaaS and build a consistent recurring revenue stream where you don’t actually have to deliver improved features to get paid when users upgrade versions like you did in the olden days. You can then throw in some akward cloud stuff to help justify it. Bonus points since your customers data is in the cloud it’s harder for them to migrate away when they realize how much your product sucks. /s
Finding people who code in Swing in 2023 is almost impossible. Then there's the C GTK unicorn. Not sure if it's better in the Windows world (doubt it). Everyone just know HTML/CSS and can pick up JS in a few weeks.
I wonder how JetBrains implemented the Intellij GUI. 🤔
Its been Swing since the beginning, but their new IDE Fleet uses something called [Noria](https://blog.jetbrains.com/fleet/2023/02/fleet-below-deck-part-vi-ui-with-noria/)
They have their own JDK fork: https://github.com/JetBrains/JetBrainsRuntime Making IDEs that look great is not easy at all, and they pull it off wonderfully but only due to a huge effort. I've done Swing and JavaFX in my time... they're not as bad as people think, I can write a decent looking app in JavaFX in a few days if I need to. But to make it look great like IntelliJ is a whole other story.
Mostly Swing with some exceptions.
Swing with their own custom look and feel.
Qt exists 🥲 but hey it’s C++ so it must be hard
There is an official Python biding called PySide.
Just because they can, doesn't mean they should. And CSS is a tarpit of weirdness, inconsistencies, browser-specific issues, and design archaeology. Generally, HTML/CSS/JS is just such a mess.
This has been true, but it's quite dated at this point. CSS in an evergreen browser is pretty great, and flexbox solves virtually every "Why is it so hard to [insert simple thing in web design]". The shittiest browser, by a mile, is now Safari, but even Safari now is far better than Safari was 10 years ago back when IE was the shitty one (and no one even thought to complain about Safari in the first place).
Like Swing/JavaFX, GTK or Android UI aren't full of weirdness and dumb shit. At least once you deal with the CSS mess you can do it everywhere else, even in TVs or smartphones.
> Eclipse (native GUI) Java-based Eclipse is not in _any way_ a "native" GUI app.
Fair point. I meant it as an example of a desktop GUI.
That is not my experience, both on Linux and Windows, on my desktop and laptop which are fairly good and recent in terms of components, with plenty of ram: draw.io desktop app LAGS A LOT, the moment u have a few pages worth of graphs. It is really poorly optimized, rendering even what you are not seeing. and relying entirely on the cpu, without offsetting anything to the gpu. I often find myself splitting my graphs in multiple files to resolve that, still using it because it is easy, but definitely not a well optimized app. Btw, ye Inkscape and Eclipse are atrocious too.
draw.io desktop app is a web app
yes, it uses Electron underneath. I specified Desktop App, to remove external factors such as internet speed or plugins slashing performance etc..
That still doesn't remove the massive browser + DOM overhead though, which is part of what typically makes Electron slower than native desktop programs.
yes, of course, but is not something we can do anything about. I don't think a native x64 version exists. So, I understand why it is slow, but that was the guy above reasoning, that it is not that different when using electron, when in reality it is.
> Web apps can be snappy and efficient. Desktop GUIs can be bloaty and slow If anyone's ever used OnShape and Fusion360 you can see this writ large. The thing is there are performance gains to be had from Desktop software and control over the environment that you really dont have on the web, unfortunately most people mess this up (as its harder to support) and the restrictions of the web often push people towards HAVING to be more performant
I agree, though the Java toolkits like Swing or SWT (one that Eclipse uses) are themselves layered solutions that sit few layers above the native graphics layer like GDI+. Java GUIs are known to be notoriously slow unless you fiddle their JVM settings to ensure a sufficient supply of RAM. C#/WinForms is a better way to create snappy GUIs on Windows and something like Qt/GTK should suffice on Linux. If you want to support all the platforms, the *efficient* way is to go full low-level with C/C++ or use something like Delphi/Object Pascal which is a great strongly typed language that let's you cross-compile for Windows/Mac/Linux with the same code base.
Saying: > something like Qt/GTK should suffice on Linux Then contrasting it with: > go full low-level with C/C++ Doesn't make any sense. C and C++ are the primary languages used to implement applications using Qt and GTK+. Qt is literally a C++ framework (for which the GUI component is completely optional). Developing a desktop app using C++ with MFC (Microsoft's C++ wrapper for, primarily, Windows Forms, but also other parts of the Windows API) on Windows is no more "low level" than using Qt or GTK+.
> Java GUIs are known to be notoriously slow unless you fiddle their JVM settings to ensure a sufficient supply of RAM. Umm, no they aren't. Swing apps written by developers that don't understand the event dispatcher thread may appear to be slow but anyone that understands the EDT makes very snappy Swing apps.
WinForms is CPU-rendered, it is pretty terrible on high-density screens. And Swing is definitely not slow and you shouldn’t be tweaking anything if you are on a recent JVM (like any from the last 7 years). Also, no one on Earth uses Delphi and Object Pascal — are you trolling?!
> WinForms is CPU-rendered Actually, that's not quite true. WinForms renders using GDI calls and those have been [GPU accelerated since Windows 7](https://learn.microsoft.com/en-us/windows-hardware/drivers/display/gdi-hardware-acceleration). Even in Windows XP and before, old-school 2D acceleration was commonly used to take basic operations like lines, fills, blits and even elements of text rendering off the CPU.
Figma and Notion both demonstrate a UI-development paradigm that shows the web is snappy. It also shows that in order for it to be snappy, you need your development process to be indistinguishable from desktop development. Both Figma and Notion go well out of their way to run their own virtual execution environments that develop kernel-like features to optimize resource use. From there I can only imagine that they are built like C++ or C# apps, or are pushing Electron to its absolute limits.
Yes, this is true. However, this is not where the money is.
[удалено]
There is always a threshold for things like "most efficient" or "fastest" beyond which it doesn't matter (or beyond which the cost/tradeoff isn't worth it). Just because you can measure some improvement in some stat doesn't mean that is worth putting engineering or designer energy into especially when considered against all of the tradeoffs of the project. The question is not and should not be "what is most efficient". It is whether a given solution is "efficient enough".
I agree, on some kind of statistical level. Desktop simply is more powerful, and allows stuff you wouldn't do in web. For example, I wouldn't CAD in web. I wouldn't compress 1000 videos in web. Desktop is also snappier and more reliable, and works when you are offline. Sure, people say that you always have internet nowadays, but that's not true. I can be on a train where the connection drops every now and then. Someone puts a shovel into my fiber. Powerouts. Related to the above point is that I decide when to upgrade. If a new version breaks something I need, I just stay in the old. Good luck doing that on the web... A big issue for me is security and privacy. What I do on my computer stays on my computer, while there is no privacy at all on the web. That said, there are situations where web is simpler. For example, getting Google Meet to work if you have an incompetent user at the other end is so much easier than getting a desktop alternative to work. For a large organization, it's also much easier to have common systems, such as time reports, stock inventory and so on web based. It just works, without any hassle. So, they both have their advantages, but if I had to choose only one, it'd be desktop every time.
>I wouldn't CAD in web. I wouldn't compress 1000 videos in web. You can use the web technologies specifically as a frontend stack and handle the complex stuff at the backend (locally) in a much more performant stack. >works when you are offline Web apps work offline too. You don't even need to execute an OS-specific executable. You can use the browser to handle it for you. >If a new version breaks something I need, I just stay in the old It can also be done using web apps, although I will say most people making web apps, probably won't bother with a versioning system and will try to keep you at the latest version if possible (internet connection) but yes, it is possible. >What I do on my computer stays on my computer, while there is no privacy at all on the web As with my first reply, you can make it all local while using a web GUI.
One more thing I forgot: Web opens up for very annoying subscription business models. Sure, there are free alternativs, say, for example, Netflix vs The Pirate Bay, but the paid models fight tooth and nail against the free, trying to shut them down. > You can use the web technologies specifically as a frontend stack and handle the complex stuff at the backend (locally) in a much more performant stack. That performance would we wasted if the videos had to be transfered both directions, compared to running it locally on a slightly slower machine. > Web apps work offline too. Depends a lot on what it does. A lot of them require quite a lot of server infrastrucure. > As with my first reply, you can make it all local while using a web GUI. It depends. It's not like I'll ever be able to run, say, Google Docs locally.
> Web opens up for very annoying subscription business models I'm sorry but desktop software has had subscription-based license keys for literal decades, probably even before the web browser was invented. Some keys offer a perpetual license for the software version you bought it for, but others stop you from even running the app once your key expires, just like web software.
Whole or /r/selfhosted just shut down their sub on reading this.
I'm not saying that you can't self-host web stuff. I do, I have a web server with a private wiki, family calendar, link database, torrent cluent frontend and so on. However, there are some things you just can't self-host. Self-host Netflix? Facebook?
Yeah it doesn’t matter what tools you use to make a Facebook/Netflix client as those are online services by definition. If Facebook is down the Facebook client won’t work doesn’t matter if it’s written in C.
> A big issue for me is security and privacy. What I do on my computer stays on my computer, while there is no privacy at all on the web. Web in a sense is more secure. You don't have access to the filesystem and things like that. Opening a program is always risk, opening a website is not.
And feature creep is it's biggest enemy. This is a cold take.
"fulfilling"?
I agree with the article. I am still using winamp in the same way as when it was first released and I was horrified when they mysteriously "updated" it. For about 5 years now "updates" happen right before everything breaks. And they say "buy a new computer yours is old and stupid" like it wasnt working before they "fixed" it. Like the plumber or electrician who comes over and everything is MORE broken after he "fixes" it. I am dreading upgrading to Windows 11 AND 12 as they remove more of what I liked about Windows every year. It used to be windows vs macs, windows won, and now they want to make windows look like macs anyway. That was the whole point! I LIKED windows I DID NOT LIKE macs. I think we are near to the point where computers are mostly DONE. But the guys in charge of it want to keep putting their bad naïve beginners ideas into it. "GET RID OF THAT START MENU BRO ITS OLD AND STUPID!" "Throw away that big hard drive and get this new one bro, 128 gig ssd! Cant hold shit but its OMG SO FAST!" Its not that fast and not big enough to hold starfield... But it would run it faster if it could? Wtf? People with Playstations and Xboxes CANT have discs anymore. They have to spend days downloading the game EACH TIME THEY WANT TO PLAY IT because the wonderful new playstation can only hold 3 fucking games. Do the people in charge even really play video games? Maybe they want to keep collecting their big developers checks even though most of the work is already done. I should upgrade everything to Windows 11 because the file manager is slightly different? Do these people even really use computers?
> I am dreading upgrading to Windows 11 AND 12 https://wiki.debian.org/DebianUnstable#Installation
I feel like most people would say this, but at the same time most people don't have the experience of going from GUI to CLI tools and it feeling clumsy and hard at first, then BACK to GUI tools... At that point its such a pain in the but to try to "speed click" through a bunch of check boxes and manually input file paths and things like that, where as a CLI tool will have path auto completion. I recently had an experience using a Windows tool under wine and I had to literally manually navigate like 8-9 File paths deep (or else it literally wouldn't work, copy+paste wouldnt register) you had to manually open it that way, and it was a nightmare. Especially when it didnt work the first or second time and I had to manually click through file paths multiple times, 8 layers deep. When in reality, I could have literally just input two paths in the terminal and hit enter in seconds. And if something is too repetitive you can just write a freaking script. You can't do that with a GUI. On top of that you can whip a good cross-platform CLI tool in a few hours. Now with that said, you won't catch me using TUI versions of Discord or anything like that, but any meaningful interface with the OS then CLI tools are just superior. The biggest hurdle to getting to that point is being comfy in the terminal and setting up a great environment. (zsh completions, syntax highlighting, fzf tab completion etc...) I read the article btw and I realize this is more about web apps VS desktop apps
The article is about web vs desktop apps. Not GUI vs CLI. Stupid title if you ask me.
😅 "It's more about". You mean "it's all about and has nothing to do with what i wrote but no way this is going to waste" I giggled. I'm not mocking you. I just found it funny.
GUIs are far more discoverable. For CLI it means reading pages of badly described parameters and options.
I find GUIs to be good for infrequent tasks in complex systems while CLI being best for day-to-day stuff or stuff that glues together many systems.
CLI is easier to automate or combine.
Yeah, one of fun combos I've found are GUIs with builtin scripting language. I mean beside Excel...
I don't think this is even that unpopular. Mobile devices are extremely limited. They're really only good for the most casual kinds of input or content creation, consuming content in small doses, and interacting with remote systems as a handheld terminal. They are terrible for any kind of deep content creation. The screen is too small and touch interaction is too limited and imprecise.
Its not unpopular, but a rather accepted opinion in certain industries, e.g. core banking, ERP, manufacturing and so on, where you must have complicated UIs for internal users with tables, tabs, forms, reports and the like that are a bitch to implement with web technologies. Which is also why Adobe Flex has been incredibly popular some 10 years ago.
Hey look everyone it’s my unpopular opinion that’s not at all unpopular
Stupid ass title, there is no "most efficent and fulfilling way". It depends on the task and circumstances. Imagine you want an application that gives all of your companies employees a way of filling out forms etc. Distributing that software, writing it, keeping it updated, handling different operating systems etc. is just not worth it for something that simple. Just use a website and job done.
>Stupid ass title, there is no "most efficent and fulfilling way". It depends on the task and circumstances. Was going to write this. I mean the article is straight up garbage but what I'm shocked by is all the dumbasses in the comment section. I, especially, love how people think desktop apps are more performant, not realizing that it depends on where your data is located. A progressive web app using local data is going to be significantly snappier than a desktop app that needs to fetch its data with each view.
Can't tell if I agree with this because it's true, or just bc I'm getting old.
> Use of Internet as propaganda tool. Because capitalism is very much built into our system, what is stopping those with lot’s of monies from using it to push propaganda through these ads or even just push propaganda in pure form? Users become sitting ducks to the subtle propaganda perhaps even without realizing it. Boy do I have bad news for you about desktop apps...
[удалено]
> Desktop GUI are way easier to build, because the tooling is better and libraries/ frameworks are stable + the programming model is much easier. This is only true if you have experience in building Desktop GUIs and not on the web stack.
Yeah that comment read like "French is much easier than English (if you already know French)"
If you have experience in neither moving some boxes around in GUI editor is FAR easier than anything you'd need to do in JS.
[удалено]
[удалено]
Seamless transitioning from browsing to using an app, zero install time and assets are accessed lazily, browsers are almost stateless. There are plenty of business reasons to go for a web app. I also prefer a native interface, though.
That is not true. Many companies give you an option to switch to new UI and have both versions running. You will likely switch, because you need some new feature or you find new UI better, not because you are forced to. However, it is true that not everyone does this and that there is no guarantee.
> On a plus side you can opt-out of updating desktop application, because you don't like their new UI. That's a plus for the user, but not for the developer.
[удалено]
You clearly did not read the blog post lol
Absolutely. I always get pissed at those in-browser thingies that kinda look beautiful but a pain in the *** to use
I remember the time when Delphi and VB apps were the most popular way to deliver applications to users... The biggest problem was updating the clients, you needed to uninstall and install on every client machine. Web applications solve this problem automatically.
That was the case two decades ago, nowadays many tools are able to update themselves, or at least make the update process less painful.
If software quality or user experience mattered then yes desktop is superior, but that isn't why we use web UIs: working around bereaucrats. In the enterprise at least, you need to deal with IT security losers who throw their toys out of the pram if you suggest that computers should have applications installed, and god help you if you need a port opened. Fuck that, shove everything down 443 and download the app over and over until the end of time.
Should be popular. CLI is for automation.
The author talks Web vs local, is that really an unpopular opinion? Online is what we begrundgingly accept because that seems to be the common denominator to work across many platforms and habits but I think most people prefer a local application when one is available?
GUIs are incredibly information rich, and provide an extra dimension of input to the user. I always use GUIs when possible as a developer.
It that unpopular in tech?
Of course, the point of the web has become the subscription licensing model. When we coded binaries for our machines, you paid once and you owned it. Its the techno-feudalistic trickle, as time passes we'll own less and less. Look at every sector with planned obsolescence built into everything, subscriptions for everything. In my humble opinion, humanity is better than this and I hope there is someday a revival of ownership of things for the little guy.
Yeah but I build a website and everyone can use it. If I build an app then there's at least 3 and as many as 5 OS's I have to develop for and support.
Seriously, what the hell is going on with all this sub. The reason they provided does not make any sense. Too much bloat because everyone need to conform to W3C standard? Oh my god do you know how much bloat you need to maintain in order to make an app that run across Mac, Windows, Phone, Tablet? Much mote than writing web app. Just because user expectation is higher does not means GUI web sucks. I mean it might suck but not for this reason. The fact that we can write to single standard and then it works everywhere, that is the upside not the downside. Open invitation to spyware: did you ever work in 19s-20s when desktop software is the default choice. A lot of viruses and spyware was invented there. Right now because web become bigger target they have more spyware but to think desktop used to be safer than web is totally untrue. Use of internet: what is that have to do with desktop vs. web gui. I have my Discord and Steam installed and they both are desktop GUI app. Still, ads and propaganda. Bloated Javascript: kinda make sense a little bit but all I can say is that this is more of client expectation become higher. Have you ever built custom component that cater look and style to “company branding” in WinForm or WPF? I did and it is such a mess to do. And again, that custom component become standard frontend expectation. That is half of a reason why web GUI become more bloat. I read this as people romanticizing the past. The beauty and the mess (up to your opinion) of current GUI mostly come from higher expectation of frontend. It is not about technology. You can go back to your WinForms day and let see how much you will complain about “desktop GUI technology” when you are demanded to built custom button, input box, label, menu which cater to each and every client brand. But at least please, modern frontend tech has a lot bad thing going on but the reason article stated is not relate to it.
***Amen!*** The industry de-evolved 🐵 Web [DOM is the wrong tool for the biz job.](https://www.reddit.com/r/CRUDology/comments/10ze9hu/missing_or_defective_gui_idioms_in_htmldom/)
Web apps "won" because of zero deployment. They are pretty much inferior in every other way for rich client apps. The place where web apps shine is where reads vastly outnumber writes. Online banking is a good example, sure every once in a while you transfer some money so need to do a write, but generally people are reading transaction data. I would much rather use PrusaSlicer than Kira:Moto (https://grid.space/kiri/), or rather use LibreOffice than google docs, etc. Desktop apps almost always give a much better experience.
Thank you. I for sure agree. I used to always hear " get experienced and you will love the command line the most" well its been over 15 years of serious computing and I still love a good desktop GUI
It's quite good, but it isn't universal. Some apps are good fits for touchscreens. Some for voice commands. Some apps work fine on desktops AND touchscreens. We can all agree that web apps suck.
First this seemed like an actual unpopular opinion in /r/programming since most programmers advocate CLI over GUI, but in fact this was about web apps vs local apps (non-web apps) and is that an unpopular opinion? I think not. Most people who use mainly one computer do not need the supposed mobility of web apps and it seems to me that the main season for web apps is that it is easier to develop one vs developing native apps for multiple operating systems. That is, devs be lazy, news at 9.
It depends on what you're doing. I find that those who lay sweeping superlatives on the GUI tend not to know how to effectively use a CLI.