Admittedly I am by profession a web developer, so I am biased here, but I don't think this article supports the claims made by the title. I agree that there are lots of reasons to critique the...
Admittedly I am by profession a web developer, so I am biased here, but I don't think this article supports the claims made by the title.
I agree that there are lots of reasons to critique the modern web. But I think it's important to do two things when we do that.
Firstly, we need to separate out the things that are specific to the web, and aren't just modern design trends. For example, a lot of people complain that the web is covered in flat buttons that hurt accessibility by not providing the proper affordances to indicate that they are buttons. This is (probably) true, but it's not web specific. The flat style dominates in all sorts of places, from desktop environments to standalone kiosks. The trend may also be visible on the web, but it is not specific to the web, and isn't driven by the web per se. In this case, the author cites a variety of things like DRM, ad-tech, propaganda -- all of which is worth criticising -- that doesn't directly have anything to do with the web at all. At best, we could argue that the web has popularised some of these ideas (such as ubiquitous advertising), but they have all existed long before the web, and they are all implemented in non-web environments.
So for me, the criticisms in the article along this axis don't really hold up very well. I can come up with a big list of things that are bad and connected to the web, but at the end of the day, that doesn't demonstrate that the web itself is bad unless I can demonstrate that these things are intrinsically linked to the web, which I don't think the article does.
Although even then, I think we've got to be careful, which brings me to my second point, which is that we need to understand to what extent our criticisms represent valid trade-offs. If I give you a choice between two cars, both of those cars will have aspects that are worse than the other. A sports car will have less storage space than a family saloon or estate, but it will probably go faster. That doesn't make one car better or worse than the other, but it means there are tradeoffs involved, where we need to understand the tradeoffs.
Publishing web applications means making a lot of tradeoffs against native applications. With a web application, you can push updates out much more efficiently and regularly, which has a big advantage with a lot of internal or B2B interfaces. Browsers also provide a much more sandboxed and secure environment, which is great for users who want to try out some tool without having to install something locally. Browsers are also great at accessibility -- unless you go out of your way to break things, all text in a web application is readable by screen readers, and with the proper use of HTML elements and aria tags, it is very easy to create accessible web applications, which is something that desktop applications have typically struggled with.
Not all of these are the best tradeoffs to make in every situation. As the author points out, there can be performance issues when using web applications*. But if we're critiquing the modern web, we need to understand why these tradeoffs were made. Sandboxing in particular is an example of something that works so much better on the web than on most other platforms, and is something that is being adopted more by other systems. Both Flatpak and Snaps are attempts to bring this sort of sandboxing capability to Linux systems, where typically an installed application has full access to anything that the user has.
I don't think the critiques in the article do recognise those tradeoffs properly. For example, the point about software bloat criticises browsers for not implementing "time-tested" best practices like C or C++, without recognising that C and C++ are a significant part of the security issues that permeate the non-web application environment. Having full, unrestricted access to a user's environment, and then running a non-memory-safe language causes issues. The browser's ability to provide a significantly safer environment for running software is critical to its success. (And this is also a key part of the WASM proposal: being able to run C/C++ code still, but now in a more sandboxed way that allows for better isolation.)
I think to better back up the headline's claim, the author needs to more clearly focus on the elements of modern applications that are specific to the web (and are not just general trends applied regardless of platform), and they need to focus on what tradeoffs have been made, and why those tradeoffs are the wrong ones. For example, they could explain why they think performance and efficiency is more important than security (or potentially argue that there are better ways to achieve the security that browsers provide).
* I find this point a bit overused though: in my experience, the fastest native application will beat out the fastest web application, but performance issues in the median native and web applications typically come from a variety of other issues, and have less to do with the platform, and more to do with the complexities of reactivity and state management at scale. VSCode is pretty fast for what it does (i.e. most of the significant parts of a full-fledged IDE), but is written in JS and electron.
I really appreciate the points you make, especially from the web development perspective. I agree that the author did not argue his points well, and you raise some really good critiques here that...
I really appreciate the points you make, especially from the web development perspective. I agree that the author did not argue his points well, and you raise some really good critiques here that I hadn't considered.
I think the fundamental issue is, "What is the internet best used for in 2023?" We really do have to consider that the idea of the internet only came to the mainstream in 1995, and wasn't ubiquitous until 2015 or so. (these are my personal dates, they are obviously fuzzy, and specific to industry, interest, field, etc.) The original internet was just HTML pages, forms, and file transferring. Now, given network speeds, we can literally run entire computers in the cloud.
From my personal perspective, having worked with both Excel as an application and as a web service I really prefer having it as an application. Word on the other hand, really doesn't lose too much when run out of a browser, in my opinion. (Taken anecdotally from my work computer)
With services like Google Stadia, a user didn't even need to download large pieces of software like games. However, the service ultimately did not gain traction with consumers.
Given that these are the capabilities of the technology we have today, I think we're at the point where it's really uncharted waters here. Many users aren't capable of really understanding the technologies they're utilizing daily, even on a base level. Thus, we're in this weird period where a majority of services seem to have been moved to the web for the user base, despite all of the underlying issues of bloat, poor coding, data tracking, and authoritarianism.
A few nitpicks… While it’s true flat style is everywhere, the web was probably the first place where I saw mass adoption of it, which may be where the author is drawing a connection. Accessibility...
A few nitpicks…
While it’s true flat style is everywhere, the web was probably the first place where I saw mass adoption of it, which may be where the author is drawing a connection.
Accessibility in native apps varies between platforms/toolkits, for example it’s not too bad and mostly “free” with macOS/iOS native (AppKit/UIKit).
macOS has had app sandboxing for around a decade at this point, which includes mobile-OS-like permissions to give apps access to only what they need. It’s really just Windows that’s doing nothing in this space.
In regards to performance and efficiency, the author’s frustrations with web apps in particular might have to do with how even though all software increases resources usage to counteract hardware improvements, web apps are often far worse about it. It’s not just that they’re a little heavier than native apps, their resource creep is generally much faster too. This isn’t necessarily inherent to web technologies, but has more to do with how web apps are often chosen as a cost-saving option, which means they’re also often subject to other types of corner cutting like sloppy engineering (see disasters like MS Teams for an example). That’s a lot more common than well oiled machines like VS Code (which as an aside, to my knowledge uses a fair chunk of native code under its Electron exterior to speed things up).
Why would software need to increase resource usage to counteract hardware improvements? Shouldn't software be designed to be usable by as many users as possible and offer a range of performance...
Why would software need to increase resource usage to counteract hardware improvements?
Shouldn't software be designed to be usable by as many users as possible and offer a range of performance options. Typically most general applications don't offer this, however gaming software do practice implementing performance options for this reason.
It doesn’t need to, but it happens anyway because it’s cheap and convenient to let increased computing power eat the costs of developers being more lackadaisical about quality and companies...
Why would software need to increase resource usage to counteract hardware improvements?
It doesn’t need to, but it happens anyway because it’s cheap and convenient to let increased computing power eat the costs of developers being more lackadaisical about quality and companies shipping faster.
Interesting, I just read the book, I wasn’t aware of the origins of the terms. still, I think affordances and signifiers are a useful distinction. Button styling is definitely a signifier imho.
Interesting, I just read the book, I wasn’t aware of the origins of the terms. still, I think affordances and signifiers are a useful distinction. Button styling is definitely a signifier imho.
I fundamentally agree with the author's main point, that we've offloaded too many tools to browser based, and it would be worth using more application based services for tasks. It's less then well...
Exemplary
I fundamentally agree with the author's main point, that we've offloaded too many tools to browser based, and it would be worth using more application based services for tasks. It's less then well written and argued article however. I actually went into reading this thinking that this would be some sort of article based on how command line interfaces are overhyped. I'm ignoring the tone, phrasing, and style in my critique here. (Which should not be held as accountable as the substance.) The article just doesn't really argue well.
There's some really valid points to be made about traditional program based applications being consistently moved to web browsers. Additionally, I agree with all points the author raises. I agree that web design as a whole is bloated, is open to 'authoritarian' monitoring, spreads propaganda, and uses poor, inefficient programming paradigms.
However, none of these points are well argued. There's a lack of references, and we're essentially supposed to take these points at face value. Really, even a quick hyperlink to Wikipedia can really add a lot of context to even a simple opinion post. Additionally, it doesn't go into the nuances of each issue. Like, are we sure that W3 is catering to enterprise over consumer? Or is that also just the author's opinion. (If someone has an article, please link it here, I'd love to know.) I'd say more, but the article just doesn't have enough to latch onto.
I'm very unimpressed with the title of this work as well. "Unpopular Opinion: Desktop GUI is the most efficient and fulfilling way of Human-Computer Interaction" does not provide adequate description of the issue. It's a poor description of the issue, which is, "I feel that the move of services to browser based rather than OS based is not a good trend in computer science."
Furthermore, the author fully neglects to realize why this change happened, despite tripping on it in the article. "Circa 2008-10" was the exact moment in CS history that smart phones and mobile browsing became widely accessible to consumers. Thus, we see this huge shift to the web, since the broad majority of people literarily start carrying around a device capable of accessing it in their pockets. Additionally, applications are more tailored for mobile currently. A quick search reported that roughly half of all web traffic comes from mobile devices in 2023, whereas desktops made up about a third .
I fundamentally agree with everything this author brings up, but it really does not do justice to the issue. I would also posit that this author is posting this publicly enough that they aren't interested in saying anything especially controversial. Regardless, it could be better written. I do appreciate their attention to the issue, however, and they're definitely onto a very major and contemporary issue.
I think you hit the nail square on the head. With mobile devices, making native apps for everything is much harder than making a website that works well on a mobile screen, then use one of the...
I think you hit the nail square on the head.
With mobile devices, making native apps for everything is much harder than making a website that works well on a mobile screen, then use one of the wrapper frameworks to deploy to all the app stores.
This is my recollection of the mobile development frenzy. I tried to find sources from that time period that could confirm, but link rot plagues the web these days. I did find some funny and...
making native apps for everything is much harder than making a website that works well on a mobile screen, then use one of the wrapper frameworks to deploy to all the app stores.
This is my recollection of the mobile development frenzy. I tried to find sources from that time period that could confirm, but link rot plagues the web these days.
I did find some funny and relevant articles, like this archived copy of New York Time’s Top 10 Mobile Web Products of 2009 which includes Facebook 3.0 (iPhone), Tweetie 2 (iPhone), and Twidroid.
I think the “cloud” frenzy back then - which when I think about it reminds of a lot of the “AI” frenzy today - and the quickening shift from software as a product to SaaS contributed as well. And netbooks and social media. Peppermint is, and Joli OS was, a cloud-centric distro. And both existed before Chromebooks.
I think I'd take issue with the idea this is a web specific issue. Most desktop apps, even silly little CMD line ones, that I've ever looked at are pretty shit code under the hood. And they work...
uses poor, inefficient programming paradigms.
I think I'd take issue with the idea this is a web specific issue. Most desktop apps, even silly little CMD line ones, that I've ever looked at are pretty shit code under the hood. And they work fine. I've been debugging a lot of C# this week that just uses crazy unsafe features built directly into the language by design. The python scripts I find people writing are not inherently any better written thaj most of the Js out there either.
Im not really a believer in giving a shit about optimizing high level code (low level shit, please do), but error prone or unreadable code irks me and it's pretty prevalent everywhere.
And that is why the author is wrong. :) If the choice is between Web App and Desktop GUI, I vote for API with CLI wrapper. What I wouldn't give to be able to run showmethemoney and get a summary...
And that is why the author is wrong. :)
If the choice is between Web App and Desktop GUI, I vote for API with CLI wrapper.
What I wouldn't give to be able to run showmethemoney and get a summary of my finances for the month, including bill due dates. This is a thing that would be easily doable if API access for customers was mandatory.
It would have a --pay <bill> --amount <amount> flag.
I suppose this is true for me and most people in tech-centric environments like Tildes, but my mom has been using computers since the 1990s and I'm pretty sure she doesn't really know what a...
I suppose this is true for me and most people in tech-centric environments like Tildes, but my mom has been using computers since the 1990s and I'm pretty sure she doesn't really know what a "folder" is.
I just banged out a PR for the vial-qmk project and used Github Desktop to manage the PR/git side and... Damn it was fast. I'd like to find a native GUI for it, rather than an electron app, but it...
I just banged out a PR for the vial-qmk project and used Github Desktop to manage the PR/git side and... Damn it was fast. I'd like to find a native GUI for it, rather than an electron app, but it was fast as heck because I didn't have to worry about squashing my commits properly. I'm tempted to take up a couple other things if I can ignore the mountain of learning Git requires to contribute effectively, I can't visualize repos easily enough to work with it, I think.
I was never a computer science type but I did partake of the Linux tiling wm/ricer culture for a bit. I stepped away from Linux as a hobby for a year or two, came back and realized I didn't like the idea of building and iterating my system, so now I let the KDE and OpenSUSE projects do that part for me, same as Microsoft and Windows but I can actually submit bug reports easily.
You have a shallow touch on this part, but I agree that we can't use efficiency to justify bloat. Part of my preference for lighter environments was lighter resources, but when XFCE and Plasma reached resource parity (XFCE going up and Plasma coming down), I switched to Plasma. I also try to emphasize doing the stuff I want to and letting GUI apps, where reasonable, handle that part, hence my exploration for a GIT GUI.
Even professionally I do a lot of Windows admin via the GUI, but I can query files, GPO results, network info via CLI because it makes sense.
KDE's windowing rules were the gamechanger for me. I have two Activities: Work and Default. When I switch to work, every window opens exactly where and how I want it every time. It's the benefits...
KDE's windowing rules were the gamechanger for me.
I have two Activities: Work and Default.
When I switch to work, every window opens exactly where and how I want it every time. It's the benefits of a tiling manager without the restrictions.
I was terribly biased against KDE - if anyone wants to try to convince me KDE 3.x wasn’t terrible I’d love to hear about positive experiences with it - and terribly biased towards...
I was terribly biased against KDE - if anyone wants to try to convince me KDE 3.x wasn’t terrible I’d love to hear about positive experiences with it - and terribly biased towards openbox/lxde/xfce back in the day but at some point the KDE 5.x environment was just too polished and easy to be ignored.
Even on a low spec Chromebook that would’ve gotten the openbox or xfce treatment back in the day now gets KDE.
100% agree KDE has been killing it with their push to squash bugs. Every now and then I hit a showstopper on bleeding edge but it rarely persists for more than a few days.
100% agree KDE has been killing it with their push to squash bugs. Every now and then I hit a showstopper on bleeding edge but it rarely persists for more than a few days.
Indeed, I'll never understand corenomial's "just use Windows" justification for discontinuing his distro. At least we have cb++ carrying the torch. (Though sounds like you've moved on. )
RIP crunchbang linux
Indeed, I'll never understand corenomial's "just use Windows" justification for discontinuing his distro. At least we have cb++ carrying the torch. (Though sounds like you've moved on. )
Post-ricer I was a huge fan of Openbox because of Crunchbang, and it was just so easy. I also think Plasma 5 is simply better, 4 had a lot of jank to it, and I came on at the end of 3 when I was...
Post-ricer I was a huge fan of Openbox because of Crunchbang, and it was just so easy. I also think Plasma 5 is simply better, 4 had a lot of jank to it, and I came on at the end of 3 when I was still in VMs and live images.
I know I’m not in the loop like I was back in the day - I haven’t noticed a Debian mailing list / LUG mailing list email in years didn’t pay much attention after than systemd wars of the early...
I know I’m not in the loop like I was back in the day - I haven’t noticed a Debian mailing list / LUG mailing list email in years didn’t pay much attention after than systemd wars of the early 2010s - but I feel like there was more…innovation in the mid to late 2000s.
Joli and Peppermint weren’t necessarily my cup of tea but were neat and we had oddballs like crunchbang, watt, aptosid, chakra, etc. that were “small” but had communities. And SUSE launched that weird cloud build system that seemed cool.
I won’t try to convince you differently, but I have always liked KDE’s design sensibilities: KDE applications just always seemed more friendly and easy to use for most of my time using it, without...
I won’t try to convince you differently, but I have always liked KDE’s design sensibilities: KDE applications just always seemed more friendly and easy to use for most of my time using it, without being overly “dumbed down” like some of the more popular options. But on the other hand it was also one of the least stable desktop environments and was constantly crashing on me. For a long time I preferred more lightweight DEs like LXDE and Enlightenment. At one point I was daily driving BlackBox.
I find it interesting that you use the (arguably potentially offensive) term "ricing" to describe your experience. I use i3wm configured entirely for productivity not appearance (no gaps, no fancy...
but I did partake of the Linux tiling wm/ricer culture for a bit. I stepped away from Linux as a hobby for a year or two, came back and realized I didn't like the idea of building and iterating my system, so now I let the KDE and OpenSUSE projects do that part for me
I find it interesting that you use the (arguably potentially offensive) term "ricing" to describe your experience. I use i3wm configured entirely for productivity not appearance (no gaps, no fancy status bars, no background colors, no floating system status, etc) and find that I cannot even come close to the productivity on any mouse based environment -- after the initial learning curve and configuring a few keystrokes to my liking it has been a matter of very minor tweaks whenever I feel like something is hurting my productivity and I've migrated my configuration from system to system for a number of years now and few can match my speed of operating my computer.
I suspect that the bigger issue wasn't the tiling WM, but the focus on aesthetics.
Whatever it’s worth, I’ve generally found tiling WMs to be more trouble than they’re worth too. In automatic tiling mode, without fail they tile windows into awkward sizes that clip content and...
Whatever it’s worth, I’ve generally found tiling WMs to be more trouble than they’re worth too.
In automatic tiling mode, without fail they tile windows into awkward sizes that clip content and make for unnecessary scrolling, which means I need to use them in manual mode (in which case, the tiles need constant care and feeding to stay useful), run every window in a fullscreen tile, and/or put troublesome windows in floating mode.
In short tiling WMs leave me micromanaging or making the tiling feature moot with fullscreen or floating. Boring old floating WMs make for less friction for me, even with all of the key-based control tiling WMs are famous for. Once windows have been sized they just stay that size and are allowed to overlap as needed, reducing required mental effort to nothing.
It might have something to do with the types of programs one uses. While I keep a few terminal windows open I don’t live in them, and more of my work is done in chrome-heavy apps like IDEs and graphics editors than in minimal ones like text editors.
Perhaps. I "grew up" programming on 12" CRT dumb terminals in a pure unix environment, so I tend to do most of my work in vim and terminals as I feel quite comfortable in that kind of environment....
It might have something to do with the types of programs one uses. While I keep a few terminal windows open I don’t live in them, and more of my work is done in chrome-heavy apps like IDEs and graphics editors than in minimal ones like text editors.
Perhaps. I "grew up" programming on 12" CRT dumb terminals in a pure unix environment, so I tend to do most of my work in vim and terminals as I feel quite comfortable in that kind of environment. I don't use an IDE, preferring vim/gdb/make.
I use virtual desktops extensively though, allowing me to quickly jump around to exactly what I want. My work setup (automated via WM class rules) is:
desktop 1: vim, by itself for editing
desktop 2: 2 to 3 terminals, one w/ the PWD in my source directory, one in my build directory to run make (when I don't just run it from vim) -- a third terminal running gdb if I need to do any debugging.
desktop 3: My browser, full window
desktop 4: free, on demand
desktop 5: Matlab, configured to float since Matlab is steaming garbage that doesn't work correctly, luckily I don't need it much.
desktop 6, 7: free, on demand
desktop 8: email/calendar
desktop 9: work chat program
desktop 0: devdocs browser window in app mode
Scratchpad: KeepassXC
I keep my chat program or devdocs open on my laptop internal monitor, and whatever I'm actively working on on my external primary monitor. Since my daily tasks revolve around a lot of the same tools, most of these open up at startup (browser, email, chat, devdocs, keepass).
I seldom find myself managing windows manually, I typically just jump between desktops as each one has its own purpose. I sometimes full-screen the window I'm working on and then quickly put it back into its tile, it's one keystroke to toggle it each way. I can also move an entire virtual desktop to the opposite monitor with one quick keystroke.
I've mostly cut "ricing" out of my vocabulary but tbh I don't know of another word to use. I bowed out of heavy customization while still using tiling WMs, and was a regular i3 user for a few...
I've mostly cut "ricing" out of my vocabulary but tbh I don't know of another word to use. I bowed out of heavy customization while still using tiling WMs, and was a regular i3 user for a few years, with just enough work to match an easy to configure GUI color scheme. In fact, i3 is the Plasma of tilers: straightforward, easy, and easy to tweak if needed.
I still have a solid i3 setup but it is very much "in development" because I keep finding things to fix, and I wind up fixing things more than I am doing things. I'll swap over to it, hit a snag, amd spend two hours correcting the snag.
I mean, this is a backronym, but the description fits, and it's where the modern use of the term was most applied. See also the wikipedia page. While definitely not culturally sensitive, it's...
Ricer stands for ‘Race Inspired Cosmetic Enhancements’.
I mean, this is a backronym, but the description fits, and it's where the modern use of the term was most applied. See also the wikipedia page. While definitely not culturally sensitive, it's nowhere near as bad as many other terms that were socially acceptable in the 90's to early 00's. Like, you could say ***got on the radio for fuck's sake. It was often used as an insult given that these cosmetic enhancements were almost always antithical to actual racing. It was then used to describe tricking out Linux DE's way back in the mid 2000's, likely inspired by the Tmobile ad, and usage ramped up further circa Fast and Furious 3:Tokyo Drift.
It might be a slur in some contexts, but not others. I'd agree it was definitely moreso back when it was used before the 1990s, but I'm not deep enough into car culture to know if it's been "taken back" so to speak.
Each of Prahlad Yeri's points could and should be applied to software like Adobe, which seems to be, like their "evangelist" events, trying to become an everything company for a creatives wet...
Each of Prahlad Yeri's points could and should be applied to software like Adobe, which seems to be, like their "evangelist" events, trying to become an everything company for a creatives wet dreams. In that context, these programs are huge and overburdened with UI.
Too much bloat as one software must cater to everyone’s needs.
Developers ignore significant problems, because they are tasked with developing new features.
Open invitation to authoritarian software like DRMs, Adware, blobs, etc.
Integrated software becomes a conflict, where companies like Pantone (a monopoly in itself) pull out over monetary disputes; however, independent software creators that make Photoshop exponentially more useful for professionals have trouble keeping up with the reams of standards and updates that make their custom products useless. Adobe Cloud is in and of itself an example of authoritarian software.
Use of Internet as propaganda tool.
The event was literally propaganda, so I'll leave that right there.
Inefficient and bloated JavaScript.
Legacy code. Change the language to C++ or C# and, badabingbadaboom it's the result of monopolistic behaviours, see my point for 1..
There's no real reason this should be a thing, but this enshittification from either low computer literacy is or a disregard for societal implications seems to not matter to bodies making reigning in these companies.
To my mind this is the big issue in software development, even though ironically enough it’s entirely non-technical in nature. I’ve been an end user as well as a programmer for 40 years, and I...
Developers ignore significant problems, because they are tasked with developing new features.
To my mind this is the big issue in software development, even though ironically enough it’s entirely non-technical in nature.
I’ve been an end user as well as a programmer for 40 years, and I have seen the same story play out over and over: users clamoring for a bug to be fixed go completely ignored, and the next release of the software contains a slew of new features no one asked for.
The web has a huge advantage in that there is no deployment and installation which means you don’t need engineers and testers to work on installers, packaging and such (a moderate sized team can...
The web has a huge advantage in that there is no deployment and installation which means you don’t need engineers and testers to work on installers, packaging and such (a moderate sized team can have 2 FTE dedicated to that per platform)
I looked at a lot of cross-platform GUI toolkits (Tk, GTK, FLTK, Qt, JavaFx, etc.) and came to the conclusion that they all sucked. The point of the exercise was to discover an Electron alternative because I was sick and tired of installing crapplet after crapplet that were all 30 MB downloads, but really the HTML + JS platform has features for graphics and layout and text that are so refined.
Sure you can build a native app for Windows and a native app for MacOS and a native app for Linux. Or you can make a “write once run anywhere” app that runs on all of those as well as tablets and VR headsets and game consoles, and…
This is true, but for a not-insignificant portion of Tildes users, the article itself is like arguing which gas-guzzling SUV is the most efficient at guzzling gas. :)
This is true, but for a not-insignificant portion of Tildes users, the article itself is like arguing which gas-guzzling SUV is the most efficient at guzzling gas. :)
The problem is that most CLI apps require you to read a manual and memorize the correct incantations to be proficient at all. I've been doing this shit for 20 years and for many common CLI tools I...
The problem is that most CLI apps require you to read a manual and memorize the correct incantations to be proficient at all. I've been doing this shit for 20 years and for many common CLI tools I still find myself looking up the argument format all the time, which slows me down and annoys me. CLI tools also do not scale well, for this same reason. I feel bad for anyone who tries to get something complex done with ffmpeg instead of using one of the many guis out there for it. The argument list for my average ffmpeg job ends up looking like an incomprehensible soup of acronyms and other nonsense. Typing that out manually and then "debugging" it when I inevitably get an argument in the wrong order or mistype something is slower than just ticking some checkboxes and making some dropdown selections in something like handbrake.
A well designed GUI can let a user be immediately productive. And good design patterns (like menu bars that communicate keyboard shortcuts) let power users be faster and more productive.
The trend of TUI for CLI seems to combine the best of both worlds: https://github.com/Textualize/trogon#how-it-works You get the benefit of being able to see all the options and then you get the...
Cli and TUIs are definitely my most efficient means of interacting. I would argue it takes practice to be efficient at a GUI too, watching some people try and navigate the menus or toolbar of...
Cli and TUIs are definitely my most efficient means of interacting.
I would argue it takes practice to be efficient at a GUI too, watching some people try and navigate the menus or toolbar of their preferred GUIs when a keyboard chord could do what they need is extremely painful.
Admittedly I am by profession a web developer, so I am biased here, but I don't think this article supports the claims made by the title.
I agree that there are lots of reasons to critique the modern web. But I think it's important to do two things when we do that.
Firstly, we need to separate out the things that are specific to the web, and aren't just modern design trends. For example, a lot of people complain that the web is covered in flat buttons that hurt accessibility by not providing the proper affordances to indicate that they are buttons. This is (probably) true, but it's not web specific. The flat style dominates in all sorts of places, from desktop environments to standalone kiosks. The trend may also be visible on the web, but it is not specific to the web, and isn't driven by the web per se. In this case, the author cites a variety of things like DRM, ad-tech, propaganda -- all of which is worth criticising -- that doesn't directly have anything to do with the web at all. At best, we could argue that the web has popularised some of these ideas (such as ubiquitous advertising), but they have all existed long before the web, and they are all implemented in non-web environments.
So for me, the criticisms in the article along this axis don't really hold up very well. I can come up with a big list of things that are bad and connected to the web, but at the end of the day, that doesn't demonstrate that the web itself is bad unless I can demonstrate that these things are intrinsically linked to the web, which I don't think the article does.
Although even then, I think we've got to be careful, which brings me to my second point, which is that we need to understand to what extent our criticisms represent valid trade-offs. If I give you a choice between two cars, both of those cars will have aspects that are worse than the other. A sports car will have less storage space than a family saloon or estate, but it will probably go faster. That doesn't make one car better or worse than the other, but it means there are tradeoffs involved, where we need to understand the tradeoffs.
Publishing web applications means making a lot of tradeoffs against native applications. With a web application, you can push updates out much more efficiently and regularly, which has a big advantage with a lot of internal or B2B interfaces. Browsers also provide a much more sandboxed and secure environment, which is great for users who want to try out some tool without having to install something locally. Browsers are also great at accessibility -- unless you go out of your way to break things, all text in a web application is readable by screen readers, and with the proper use of HTML elements and aria tags, it is very easy to create accessible web applications, which is something that desktop applications have typically struggled with.
Not all of these are the best tradeoffs to make in every situation. As the author points out, there can be performance issues when using web applications*. But if we're critiquing the modern web, we need to understand why these tradeoffs were made. Sandboxing in particular is an example of something that works so much better on the web than on most other platforms, and is something that is being adopted more by other systems. Both Flatpak and Snaps are attempts to bring this sort of sandboxing capability to Linux systems, where typically an installed application has full access to anything that the user has.
I don't think the critiques in the article do recognise those tradeoffs properly. For example, the point about software bloat criticises browsers for not implementing "time-tested" best practices like C or C++, without recognising that C and C++ are a significant part of the security issues that permeate the non-web application environment. Having full, unrestricted access to a user's environment, and then running a non-memory-safe language causes issues. The browser's ability to provide a significantly safer environment for running software is critical to its success. (And this is also a key part of the WASM proposal: being able to run C/C++ code still, but now in a more sandboxed way that allows for better isolation.)
I think to better back up the headline's claim, the author needs to more clearly focus on the elements of modern applications that are specific to the web (and are not just general trends applied regardless of platform), and they need to focus on what tradeoffs have been made, and why those tradeoffs are the wrong ones. For example, they could explain why they think performance and efficiency is more important than security (or potentially argue that there are better ways to achieve the security that browsers provide).
* I find this point a bit overused though: in my experience, the fastest native application will beat out the fastest web application, but performance issues in the median native and web applications typically come from a variety of other issues, and have less to do with the platform, and more to do with the complexities of reactivity and state management at scale. VSCode is pretty fast for what it does (i.e. most of the significant parts of a full-fledged IDE), but is written in JS and electron.
I really appreciate the points you make, especially from the web development perspective. I agree that the author did not argue his points well, and you raise some really good critiques here that I hadn't considered.
I think the fundamental issue is, "What is the internet best used for in 2023?" We really do have to consider that the idea of the internet only came to the mainstream in 1995, and wasn't ubiquitous until 2015 or so. (these are my personal dates, they are obviously fuzzy, and specific to industry, interest, field, etc.) The original internet was just HTML pages, forms, and file transferring. Now, given network speeds, we can literally run entire computers in the cloud.
From my personal perspective, having worked with both Excel as an application and as a web service I really prefer having it as an application. Word on the other hand, really doesn't lose too much when run out of a browser, in my opinion. (Taken anecdotally from my work computer)
With services like Google Stadia, a user didn't even need to download large pieces of software like games. However, the service ultimately did not gain traction with consumers.
Given that these are the capabilities of the technology we have today, I think we're at the point where it's really uncharted waters here. Many users aren't capable of really understanding the technologies they're utilizing daily, even on a base level. Thus, we're in this weird period where a majority of services seem to have been moved to the web for the user base, despite all of the underlying issues of bloat, poor coding, data tracking, and authoritarianism.
A few nitpicks…
In regards to performance and efficiency, the author’s frustrations with web apps in particular might have to do with how even though all software increases resources usage to counteract hardware improvements, web apps are often far worse about it. It’s not just that they’re a little heavier than native apps, their resource creep is generally much faster too. This isn’t necessarily inherent to web technologies, but has more to do with how web apps are often chosen as a cost-saving option, which means they’re also often subject to other types of corner cutting like sloppy engineering (see disasters like MS Teams for an example). That’s a lot more common than well oiled machines like VS Code (which as an aside, to my knowledge uses a fair chunk of native code under its Electron exterior to speed things up).
Why would software need to increase resource usage to counteract hardware improvements?
Shouldn't software be designed to be usable by as many users as possible and offer a range of performance options. Typically most general applications don't offer this, however gaming software do practice implementing performance options for this reason.
It doesn’t need to, but it happens anyway because it’s cheap and convenient to let increased computing power eat the costs of developers being more lackadaisical about quality and companies shipping faster.
Nit: signifier not affordance
Interesting, I just read the book, I wasn’t aware of the origins of the terms. still, I think affordances and signifiers are a useful distinction. Button styling is definitely a signifier imho.
I fundamentally agree with the author's main point, that we've offloaded too many tools to browser based, and it would be worth using more application based services for tasks. It's less then well written and argued article however. I actually went into reading this thinking that this would be some sort of article based on how command line interfaces are overhyped. I'm ignoring the tone, phrasing, and style in my critique here. (Which should not be held as accountable as the substance.) The article just doesn't really argue well.
There's some really valid points to be made about traditional program based applications being consistently moved to web browsers. Additionally, I agree with all points the author raises. I agree that web design as a whole is bloated, is open to 'authoritarian' monitoring, spreads propaganda, and uses poor, inefficient programming paradigms.
However, none of these points are well argued. There's a lack of references, and we're essentially supposed to take these points at face value. Really, even a quick hyperlink to Wikipedia can really add a lot of context to even a simple opinion post. Additionally, it doesn't go into the nuances of each issue. Like, are we sure that W3 is catering to enterprise over consumer? Or is that also just the author's opinion. (If someone has an article, please link it here, I'd love to know.) I'd say more, but the article just doesn't have enough to latch onto.
I'm very unimpressed with the title of this work as well. "Unpopular Opinion: Desktop GUI is the most efficient and fulfilling way of Human-Computer Interaction" does not provide adequate description of the issue. It's a poor description of the issue, which is, "I feel that the move of services to browser based rather than OS based is not a good trend in computer science."
Furthermore, the author fully neglects to realize why this change happened, despite tripping on it in the article. "Circa 2008-10" was the exact moment in CS history that smart phones and mobile browsing became widely accessible to consumers. Thus, we see this huge shift to the web, since the broad majority of people literarily start carrying around a device capable of accessing it in their pockets. Additionally, applications are more tailored for mobile currently. A quick search reported that roughly half of all web traffic comes from mobile devices in 2023, whereas desktops made up about a third .
I fundamentally agree with everything this author brings up, but it really does not do justice to the issue. I would also posit that this author is posting this publicly enough that they aren't interested in saying anything especially controversial. Regardless, it could be better written. I do appreciate their attention to the issue, however, and they're definitely onto a very major and contemporary issue.
I think you hit the nail square on the head.
With mobile devices, making native apps for everything is much harder than making a website that works well on a mobile screen, then use one of the wrapper frameworks to deploy to all the app stores.
This is my recollection of the mobile development frenzy. I tried to find sources from that time period that could confirm, but link rot plagues the web these days.
I did find some funny and relevant articles, like this archived copy of New York Time’s Top 10 Mobile Web Products of 2009 which includes Facebook 3.0 (iPhone), Tweetie 2 (iPhone), and Twidroid.
I think the “cloud” frenzy back then - which when I think about it reminds of a lot of the “AI” frenzy today - and the quickening shift from software as a product to SaaS contributed as well. And netbooks and social media. Peppermint is, and Joli OS was, a cloud-centric distro. And both existed before Chromebooks.
I think I'd take issue with the idea this is a web specific issue. Most desktop apps, even silly little CMD line ones, that I've ever looked at are pretty shit code under the hood. And they work fine. I've been debugging a lot of C# this week that just uses crazy unsafe features built directly into the language by design. The python scripts I find people writing are not inherently any better written thaj most of the Js out there either.
Im not really a believer in giving a shit about optimizing high level code (low level shit, please do), but error prone or unreadable code irks me and it's pretty prevalent everywhere.
A desktop GUI is merely an efficient way to multiplex multiple terminal windows.
I love your comment, but the article actually has nothing to do with command line vs. GUI based programs.
And that is why the author is wrong. :)
If the choice is between Web App and Desktop GUI, I vote for API with CLI wrapper.
What I wouldn't give to be able to run
showmethemoneyand get a summary of my finances for the month, including bill due dates. This is a thing that would be easily doable if API access for customers was mandatory.It would have a
--pay <bill> --amount <amount>flag.Lol. I remember mozillas build system does have a Google search command built in (or did 8 years ago).
I suppose this is true for me and most people in tech-centric environments like Tildes, but my mom has been using computers since the 1990s and I'm pretty sure she doesn't really know what a "folder" is.
I just banged out a PR for the vial-qmk project and used Github Desktop to manage the PR/git side and... Damn it was fast. I'd like to find a native GUI for it, rather than an electron app, but it was fast as heck because I didn't have to worry about squashing my commits properly. I'm tempted to take up a couple other things if I can ignore the mountain of learning Git requires to contribute effectively, I can't visualize repos easily enough to work with it, I think.
I was never a computer science type but I did partake of the Linux tiling wm/ricer culture for a bit. I stepped away from Linux as a hobby for a year or two, came back and realized I didn't like the idea of building and iterating my system, so now I let the KDE and OpenSUSE projects do that part for me, same as Microsoft and Windows but I can actually submit bug reports easily.
You have a shallow touch on this part, but I agree that we can't use efficiency to justify bloat. Part of my preference for lighter environments was lighter resources, but when XFCE and Plasma reached resource parity (XFCE going up and Plasma coming down), I switched to Plasma. I also try to emphasize doing the stuff I want to and letting GUI apps, where reasonable, handle that part, hence my exploration for a GIT GUI.
Even professionally I do a lot of Windows admin via the GUI, but I can query files, GPO results, network info via CLI because it makes sense.
KDE's windowing rules were the gamechanger for me.
I have two Activities: Work and Default.
When I switch to work, every window opens exactly where and how I want it every time. It's the benefits of a tiling manager without the restrictions.
I was terribly biased against KDE - if anyone wants to try to convince me KDE 3.x wasn’t terrible I’d love to hear about positive experiences with it - and terribly biased towards openbox/lxde/xfce back in the day but at some point the KDE 5.x environment was just too polished and easy to be ignored.
Even on a low spec Chromebook that would’ve gotten the openbox or xfce treatment back in the day now gets KDE.
RIP crunchbang linux
100% agree KDE has been killing it with their push to squash bugs. Every now and then I hit a showstopper on bleeding edge but it rarely persists for more than a few days.
Indeed, I'll never understand corenomial's "just use Windows" justification for discontinuing his distro. At least we have cb++ carrying the torch. (Though sounds like you've moved on. )
Post-ricer I was a huge fan of Openbox because of Crunchbang, and it was just so easy. I also think Plasma 5 is simply better, 4 had a lot of jank to it, and I came on at the end of 3 when I was still in VMs and live images.
I know I’m not in the loop like I was back in the day - I haven’t noticed a Debian mailing list / LUG mailing list email in years didn’t pay much attention after than systemd wars of the early 2010s - but I feel like there was more…innovation in the mid to late 2000s.
Joli and Peppermint weren’t necessarily my cup of tea but were neat and we had oddballs like crunchbang, watt, aptosid, chakra, etc. that were “small” but had communities. And SUSE launched that weird cloud build system that seemed cool.
I won’t try to convince you differently, but I have always liked KDE’s design sensibilities: KDE applications just always seemed more friendly and easy to use for most of my time using it, without being overly “dumbed down” like some of the more popular options. But on the other hand it was also one of the least stable desktop environments and was constantly crashing on me. For a long time I preferred more lightweight DEs like LXDE and Enlightenment. At one point I was daily driving BlackBox.
I find it interesting that you use the (arguably potentially offensive) term "ricing" to describe your experience. I use i3wm configured entirely for productivity not appearance (no gaps, no fancy status bars, no background colors, no floating system status, etc) and find that I cannot even come close to the productivity on any mouse based environment -- after the initial learning curve and configuring a few keystrokes to my liking it has been a matter of very minor tweaks whenever I feel like something is hurting my productivity and I've migrated my configuration from system to system for a number of years now and few can match my speed of operating my computer.
I suspect that the bigger issue wasn't the tiling WM, but the focus on aesthetics.
Whatever it’s worth, I’ve generally found tiling WMs to be more trouble than they’re worth too.
In automatic tiling mode, without fail they tile windows into awkward sizes that clip content and make for unnecessary scrolling, which means I need to use them in manual mode (in which case, the tiles need constant care and feeding to stay useful), run every window in a fullscreen tile, and/or put troublesome windows in floating mode.
In short tiling WMs leave me micromanaging or making the tiling feature moot with fullscreen or floating. Boring old floating WMs make for less friction for me, even with all of the key-based control tiling WMs are famous for. Once windows have been sized they just stay that size and are allowed to overlap as needed, reducing required mental effort to nothing.
It might have something to do with the types of programs one uses. While I keep a few terminal windows open I don’t live in them, and more of my work is done in chrome-heavy apps like IDEs and graphics editors than in minimal ones like text editors.
Perhaps. I "grew up" programming on 12" CRT dumb terminals in a pure unix environment, so I tend to do most of my work in vim and terminals as I feel quite comfortable in that kind of environment. I don't use an IDE, preferring vim/gdb/make.
I use virtual desktops extensively though, allowing me to quickly jump around to exactly what I want. My work setup (automated via WM class rules) is:
desktop 1: vim, by itself for editing
desktop 2: 2 to 3 terminals, one w/ the PWD in my source directory, one in my build directory to run make (when I don't just run it from vim) -- a third terminal running gdb if I need to do any debugging.
desktop 3: My browser, full window
desktop 4: free, on demand
desktop 5: Matlab, configured to float since Matlab is steaming garbage that doesn't work correctly, luckily I don't need it much.
desktop 6, 7: free, on demand
desktop 8: email/calendar
desktop 9: work chat program
desktop 0: devdocs browser window in app mode
Scratchpad: KeepassXC
I keep my chat program or devdocs open on my laptop internal monitor, and whatever I'm actively working on on my external primary monitor. Since my daily tasks revolve around a lot of the same tools, most of these open up at startup (browser, email, chat, devdocs, keepass).
I seldom find myself managing windows manually, I typically just jump between desktops as each one has its own purpose. I sometimes full-screen the window I'm working on and then quickly put it back into its tile, it's one keystroke to toggle it each way. I can also move an entire virtual desktop to the opposite monitor with one quick keystroke.
I've mostly cut "ricing" out of my vocabulary but tbh I don't know of another word to use. I bowed out of heavy customization while still using tiling WMs, and was a regular i3 user for a few years, with just enough work to match an easy to configure GUI color scheme. In fact, i3 is the Plasma of tilers: straightforward, easy, and easy to tweak if needed.
I still have a solid i3 setup but it is very much "in development" because I keep finding things to fix, and I wind up fixing things more than I am doing things. I'll swap over to it, hit a snag, amd spend two hours correcting the snag.
I mean, this is a backronym, but the description fits, and it's where the modern use of the term was most applied. See also the wikipedia page. While definitely not culturally sensitive, it's nowhere near as bad as many other terms that were socially acceptable in the 90's to early 00's. Like, you could say ***got on the radio for fuck's sake. It was often used as an insult given that these cosmetic enhancements were almost always antithical to actual racing. It was then used to describe tricking out Linux DE's way back in the mid 2000's, likely inspired by the Tmobile ad, and usage ramped up further circa Fast and Furious 3:Tokyo Drift.
It might be a slur in some contexts, but not others. I'd agree it was definitely moreso back when it was used before the 1990s, but I'm not deep enough into car culture to know if it's been "taken back" so to speak.
Each of Prahlad Yeri's points could and should be applied to software like Adobe, which seems to be, like their "evangelist" events, trying to become an everything company for a creatives wet dreams. In that context, these programs are huge and overburdened with UI.
Developers ignore significant problems, because they are tasked with developing new features.
Integrated software becomes a conflict, where companies like Pantone (a monopoly in itself) pull out over monetary disputes; however, independent software creators that make Photoshop exponentially more useful for professionals have trouble keeping up with the reams of standards and updates that make their custom products useless. Adobe Cloud is in and of itself an example of authoritarian software.
The event was literally propaganda, so I'll leave that right there.
Legacy code. Change the language to C++ or C# and, badabingbadaboom it's the result of monopolistic behaviours, see my point for 1..
There's no real reason this should be a thing, but this enshittification from either low computer literacy is or a disregard for societal implications seems to not matter to bodies making reigning in these companies.
To my mind this is the big issue in software development, even though ironically enough it’s entirely non-technical in nature.
I’ve been an end user as well as a programmer for 40 years, and I have seen the same story play out over and over: users clamoring for a bug to be fixed go completely ignored, and the next release of the software contains a slew of new features no one asked for.
The web has a huge advantage in that there is no deployment and installation which means you don’t need engineers and testers to work on installers, packaging and such (a moderate sized team can have 2 FTE dedicated to that per platform)
I looked at a lot of cross-platform GUI toolkits (Tk, GTK, FLTK, Qt, JavaFx, etc.) and came to the conclusion that they all sucked. The point of the exercise was to discover an Electron alternative because I was sick and tired of installing crapplet after crapplet that were all 30 MB downloads, but really the HTML + JS platform has features for graphics and layout and text that are so refined.
Sure you can build a native app for Windows and a native app for MacOS and a native app for Linux. Or you can make a “write once run anywhere” app that runs on all of those as well as tablets and VR headsets and game consoles, and…
I can do everything so much faster through CLI, it just takes practice
Please read the article. It's not about CLI, it's about the shift to web services. The title is aggressively misleading.
This is true, but for a not-insignificant portion of Tildes users, the article itself is like arguing which gas-guzzling SUV is the most efficient at guzzling gas. :)
The problem is that most CLI apps require you to read a manual and memorize the correct incantations to be proficient at all. I've been doing this shit for 20 years and for many common CLI tools I still find myself looking up the argument format all the time, which slows me down and annoys me. CLI tools also do not scale well, for this same reason. I feel bad for anyone who tries to get something complex done with ffmpeg instead of using one of the many guis out there for it. The argument list for my average ffmpeg job ends up looking like an incomprehensible soup of acronyms and other nonsense. Typing that out manually and then "debugging" it when I inevitably get an argument in the wrong order or mistype something is slower than just ticking some checkboxes and making some dropdown selections in something like handbrake.
A well designed GUI can let a user be immediately productive. And good design patterns (like menu bars that communicate keyboard shortcuts) let power users be faster and more productive.
The trend of TUI for CLI seems to combine the best of both worlds: https://github.com/Textualize/trogon#how-it-works
You get the benefit of being able to see all the options and then you get the automation and composability of CLI commands
Cli and TUIs are definitely my most efficient means of interacting.
I would argue it takes practice to be efficient at a GUI too, watching some people try and navigate the menus or toolbar of their preferred GUIs when a keyboard chord could do what they need is extremely painful.