No, it's not only that.
I've been programming GUI apps for 30 years, going through TurboVision, Delphi, MFC, WinForms, wxWidgets, Qt, WPF, native Android/iPhone, and probably 2 more I forgot about.
They all suck terribly when compared to React/Vue/HTML/CSS.
Creating a GUI app with web tech it's just so much more productive. It's like comparing the productivity of Python to C++. Sure, you can't write an audio editor in Python/Electron, but for 90% of GUI apps it makes no sense to use native frameworks. They are as productive and expressive as writing in assembly.
I've written apps in Python and regret it. The pain of packaging to end users, the 20-30 megabytes of OpenBLAS to get NumPy to get vectorized operations on the same order of magnitude as fast as a C++ loop, the dependence on prebuilt wheels and inability to write fast C/C++ code without foisting a dependency on a C++ compiler on your users (unless you have a Windows, Linux, and Mac machine to build wheels yourself), the lack of multithreaded parallelism... From observing a JS audio app being developed, they're also struggling with the inability to write C/C++ code without foisting a dependency on a C++ compiler on your users (unless the developers build native packages themselves), dependence on upstream fixing bugs rather than being able to fix the bugs themselves, and download sizes of over 50 megabytes zipped, plus recurring packaging issues where the native libraries don't run properly on user machines.
Sure there are libraries of the season to handle most of it, but selecting the best of multiple libs has a cost.
Libraries like Delphi/Lazarus and wxPython, Qt, et al are incredibly productive.
For the record, I've also used Delphi, MFC, WinForms, Qt, native Android and iOS, but not TurboVision and very little wxWidgets. I didn't use React, nor Vue, but I am familiar with web development and web technologies in general.
If I look at https://reactjs.org/tutorial/tutorial.html, I find it really really hard to believe that's in any way better than at least Delphi or Qt, to pick just two of the technologies I'm familiar with. There are functions which return HTML code which contain JavaScript code in there. How can one return an <h1> from a function with a straight face? :-)
You really need to try React/Vue. Vue is actually much simple to get started with and understand if you just want to try it out.
Once you use a reactive GUI, there is no going back to manually managing controls state like in Qt.
> How can one return an <h1> from a function with a straight face?
People used to say that about Python, that no serious programmer would use a language with significant white space.
I then ran over to Windows, because I recall having done similar things with WPF. I instantly recalled why I hated it though, as doing any custom styling on components is a miserable mess of boilerplate XML and overriding values I have little knowledge of and seem not related or tangentially related to what I was styling.
I was able to create what I wanted relatively easily with a mix of HTML and CSS though. I think something like WPF but with CSS-like styling would be nice.
So, if I have, say, Python as my scripting language for that tool, how do I alter the UI?
The only program that gets this right is Blender. And they had to build their own UI toolkit from scratch to do it.
I am really surprised there are no projects that extract the essence of the HTML/JS/CSS UI system (declarative UI with on the fly control) and use that to render to any surface.
JavaFX has done what you ask, actually. There's FXML which is an XML UI description language (actually it can describe any object graph) and you can style it with a dialect of CSS2 tuned for desktop apps.
But React/Vue etc aren't quite the same thing are they. React actually throws out normal HTML and replaces it with some sort of HTML-esque simulation that they then try to performantly map to the real thing.
Also the web has a superior distribution and sandboxing model
I haven't used native script but my casual research is that it's in an even worst state.
Compare to a browser, which just fixes most of these issues, the wins provided are not worth the costs IMHO.
The web is a bit rough around the edges in some spots but for the wide target base and productivity of the tools and frameworks nothing I've used previously comes close.
As a user, I don’t care about the dev’s challenge of supporting multiple OS’s. These best experience comes when I load up a new application and can intuitively navigate it without the mental overload required trying to decipher a GUI layout which doesn’t adhere to any standard.
Web frameworks are great, but have their limitations.
The blame is not so much with the new generations of devs, but with the likes of Microsoft and Apple who have ditched standards and are encouraging the Desktop to turn into the wild-west. Or something like that.
It works in a very different - and very keyboard-centric - way. Having to touch a mouse slows users down dramatically, and so they keep closing our "pretty" app and opening up another terminal session. Can you imagine using web apps without touching the mouse at all? Or even most GUI apps?
And the speed... the time it takes to navigate from one screen to the next is milliseconds. They'll be typing three or four screens in advance. And they'll have four to six terminal sessions open. There's no GUI app that comes close, and I'm not sure it's even possible.
So yes. Web as desktop is bad. Really bad. Backwards. Unusable. Broken. And the people who work on it can't even understand the problem - that user efficiency and speed are REALLY IMPORTANT. Until "modern" devs understand that sometimes the front-end of choice is "ncurses", we're going to continue to have lots and lots of problems.
Also when it comes to usability, users prefer having a consistent UI over a "native" UI, especially as the number of devices have exploded between laptops, phones and tablets. Slack looks and works the same everywhere, and that's one of it's advantages.
I may be wrong in this but I feel that lot of the push for Electron and the like is for the styling capabilities it brings compared to native toolkits. In the case of many Electron apps, especially simpler ones, maintaining something in Qt or even WPF/AppKit/etc wouldn't be a challenge, as long as the dev is willing to use standard widgets. An inordinate amount of energy and resources has been spent on turning apps into an arm of branding/marketing.
> Also when it comes to usability, users prefer having a consistent UI over a "native" UI, especially as the number of devices have exploded between laptops, phones and tablets. Slack looks and works the same everywhere, and that's one of it's advantages.
Slack is a bit of a funny example, that's one app where I'd greatly prefer to run the iOS app on desktop if I could. The web/electron version is a mess.
I see few people use the same apps on more than 1 desktop and 1 mobile OS. They use Windows and couldn't care less what the macOS app looks like. Or vice versa.
It's about branding usually in my experience. Not what users want.
Overall, it seems like the success of the web and apps has mostly overturned the design principles that so many hold dear, and the world isn’t burning because of it.
I've seen inconsistency, churn, and simplistic design turn people who used to be power users into helpless feeling novices. We can say something has been lost even if the world isn't literally on fire.
- "Instant on" apps without having to manage the computers resources via installation and uninstallation.
- Hassle-free updates that don't bug them all the time due to perverse/skewed value systems amongst developers, who think users deeply care about whether to accept an update or not.
- Not having to worry about malware
- Not having to worry about backups
- Not having to worry about your lethargic and incompetent IT department to roll things out
etc etc. Lots of advantages to web apps, none of which are really intrinsic to the web platform itself and all of which could be implemented also in desktop apps. As in fact, Chrome tries hard to do.
But I don't think the proliferation of web apps is actually due to end-user focused arguments. I think it's mostly about developer convenience and a lot of cultural/ideological assumptions. Web apps are piracy free and naturally justify a subscription model. People have to learn HTML+JS at some point to make websites, so at that point it makes sense to double down on those skills and keep iterating them to learn to make apps as well. You can write cross platform software with Qt or Java but for the longest time (not any more?) people associated the web with openness, being free-as-in-beer, decentralisation, not being controlled by any one company etc. A lot of wholesome stuff. On mobile that's probably still true. On the desktop it's no longer quite so true, if it ever was, but lots of developers really wanted to make a web apps for social reasons as much as technical reasons.
It's not remotely worth it to me carefully to build a desktop app for a platform that I can't count on staying the same for more than a year.
Actually, it's not even a question of whether it's worth it; in some cases, it's physically impossible for a solo-developer to develop a large app on the shifting sand that is MacOS.
Was there ever really a time when this was de rigeur? I certainly feel it should be, but I've always felt alone having an intense interest in this as a dev.
I can't really speak to the first question, but I know of a small handful of people (who are developers or software-adjacent) who are deeply familiar with nuanced GUI details and can consciously talk about them. Plausibly, many people have historically not noticed many of these details, but got them for free when most software was built with native controls … and because they were rarely noticed, they rarely get explicitly specced for UIs built on less-robust primitives.
[^0]: https://www.reddit.com/r/OutOfTheLoop/comments/36twsr/what_i...
https://developer.apple.com/design/human-interface-guideline...
The web is where you really get that kind of grab-bag of mismatching (or absent) UX affordances. Remember when clickable links were all blue underline text? I do. Those days are gone, and for way too many pages the only way to tell if something is clickable or not is to move the mouse over it and see if it gives you the finger.
As a user I do care about that. A big selling point of vscode versus emacs for me is that it works "natively" on both Windows and Linux. Finally, I don't need to run a VM just to run emacs. I tried all the other alternatives like Msys2 and cygwin, but they're like their own circle of hell as soon as you need to run executables and all the extensions assume you're on Linux.
The VS Code developers worked to make it what it is. Sublime Text shows it isn't about the technology. Emacs is just from a culture where non Unix and proprietary operating systems are 2nd class.
Our UI vocabulary is shrinking. Undo support used to be table stakes, but now I'm surprised when it works. The web is not only eating the desktop: it's eating what it means to be an expert computer user.
Nailed it. Instability is the enemy of mastery. In order to fully grok things, they need to be stable long enough to be grokked. Software has stopped being stable long enough to become an expert.
Brains learn. And then a brain that is forced to unlearn and relearn enough times eventually learns to not bother learning. So no one even bothers to become an expert anymore.
If you don't like the trend toward web-ification of the desktop, don't blame developers or Electron. Blame OS vendors for refusing to field a portable API for the large common core of desktop app functionality, something for 2D GUIs analogous to OpenGL. Why do we have standard 3D libraries, standard APIs for files and I/O, standard networking APIs, but no standard GUI API?
... because OS vendors still want to try to herd developers into building apps for only their platform. Developers (myself included) respond with "fuck you" and use web technologies.
There is also Qt, but it's fairly antiquated. It doesn't use or support the reactive UI paradigm, and after using React I can't go back. Every other GUI coding paradigm I've seen degenerates into spaghetti code.
All the other options (other than Qt or web technologies) falls down in the area of accessibility, making it not usable for serious work.
That's typically avoided by decoupling model and view and/or similar functional patterns. What else is the paradigm providing?
I doubt the framework you want them to create would change much. Many Electron fans talk about how apps should look and feel exactly the same on every OS. They say web technologies are the best UI layer by far. And it isn't like Slack or Microsoft don't have the resources to make native apps.
The above arguments would not be taken seriously on another topic, but here their weakness can be overlooked (by some) since folks are already committed to the the stance they support.
Look at the argument more closely: they're naming several random bugs. You can name several random bugs related to any UI framework on the planet with a sufficient user count. It's meaningless.
I'd urge people to look a little closer at arguments being put forward by the anti-Electron faction here if you don't yet have data yourself.
For myself, whenever I read these kinds of comments (or the tiresome refrain about absurd memory usage) it feels to me like there must be two Electrons: the first being the Electron which is the foundation of nearly every app I actually find useful these days (which do not exhibit e.g. exorbitant memory consumption issues [it's a marginal, non-issue increase in my experience] or higher bug-rates than native apps)—and then there's the second Electron, which afaict is a conceptual construction supporting a particular perspective on the 'correct' way of writing software (hint: anything using web tech isn't it).
Edit: something that would help move legitimate analysis of this topic forward: comparisons to other frameworks should be made after normalizing with respect to feature count/complexity, i.e. how much higher is memory usage vs. a competing app that actually offers similar features—e.g. comparing Discord to an IRC client would not be particularly informative (but that kind of mismatched comparison seems to be a common source of misconceptions here)
There's a virtuous cycle when apps use a platform's native components: apps get the standard UI behaviors for free, users can bring their knowledge from one app to another, and the platform owner can enhance the UI frameworks, improving all the apps on the platform. At least that's the hope.
I can see a future dominated by Electron apps. But Electron is not converging on a new set of UI behaviors that I can bring from one app to another. In any given Electron app, gestures like arrow keys work differently not only from native apps, but from other Electron apps. So I don't use the arrow keys: one less word in my UI vocabulary.
It’s also very tiresome to see such weak defenses when one looks around at the experience of people who have only 8GB RAM and are running Windows 10. If it’s just a war of anecdotes, I have several to share on why Electron is bad (or is badly used) by apps like MS Teams and others. Long ago, people used to complain about Java apps (mainly due to startup time). Electron apps make those seem like nothing to complain about. It’s not just high memory usage or the UX being poor, it’s also about being a poor citizen on the computer and making things worse for all the other applications running at the same time.
The points they brought up are not meaningless and more people than what it seems you imagine are affected by the shortcomings outlined by the points made prior.
Random examples of bad behaviour in commonly used parts that would affect just about every user:
If you try to search & replace, it'll refuse to remember "replace in selection". It'll reset every time, destroying your entire file instead of replacing just in the selected block.
If you do enable this feature, it'll change what you've selected, because... why?
Even with the feature enabled, the "search preview" will highlight matches outside the selection block! WTF?
There's no memory for recent searches, so if you've just spent ten minutes carefully crafting a regex and you accidentally click the wrong thing, then it is gone forever.
The recent files list isn't a list of recent files.
The console overwrites itself sometimes, resulting in gibberish output. It's particularly bad with PowerShell that uses Write-Progress. I've sat around for nearly an hour waiting for a process to complete, when in fact it was prompting me to continue. I couldn't see the prompt because it had overwritten it (incorrectly).
Someone thought that manually editing JSON files is a suitable GUI for configuring basic settings.
Ctrl scroll up/down doesn't change the zoom (or font size).
Unlike most Microsoft editors like the PowerShell ISE or Visual Studio, MS Word, and most third party text editors, block select isn't alt-drag but middle-button-drag instead. No middle button on your mouse? No block select for you!
It's unfortunate that many new Microsoft languages are supported in VS Code only. It feels like a huge step backwards that's being forced onto an enormous community.
VSCode does not indicate to the user when the save is complete. I've had saves require 15+ seconds, and they are not atomic, so you must be careful to not use the file (compile, git, etc) until the save is finished, which is hard to know. I've personally lost data this way.
I agree that command palette is great and is clearly a point of convergence among new apps. I wish Apple would embrace it!
Not sure what you program in, but that has not been my experience at all. C# (Unity), Golang, Python have pretty mediocre support at best in VS Code. What JetBrains' products do there is miles ahead, and tacking on countless extensions doesn't get you close to the out of the box experience, so I fail to see the point.
If I'm quickly editing a single file, sure I might fire up VS Code or Micro. For actual work though, the JetBrains products can't be beat (for me at least).
If everyone is willing to throw that away, say goodbye to general purpose computing, and say welcome to your new App Store Overlords.
The last GUI program I wrote in Lazarus worked out to a 24 megabyte executable, because I left the debug information in. It used MySQL and did a lot of computing with gear information. I didn't have to sign the code, or ask ANYONE's permission to deploy it.
I'm not giving up general purpose computing, neither should you.
I agree with this in some context, I bought the device, I own it and I should be able to use it as I see fit.
However not all uses are equal. Take my elderly mother, her needs are much different and in fact centralized distribution channels, app reviews, signing etc are all mechanisms which benefit her.
Electron apps are slow, but eventually MS or Apple will decide to launch some sort of "integrated web desktop API" that plays well with Electron (and eventually eats its lunch). Seeing the speed boost, the other desktop OSes will do the same and suddenly we are all coding for the web for everything while the guts are rearranged dramatically beneath us.
This happens over and over in tech - like setting up a soundcard in 1995. First we had to futz with config files and IRQ conflicts and then things were Made Nice with "Plug and Play" - this is the step we are at now: Electron makes stuff work without all the futzing. It doesn't matter if it is slower or worse, it is winning and things will move underneath to make it make sense.
The step that next is the not caring: now sound cards just come baked in to the motherboard, hardware conflicts can be managed in software, dynamically resolved or who knows - I don't have to think about it any more. Soon you won't have to worry about performance on desktops because it will be an OS problem to make arbitrary web code run faster on desktops, not developers.
Also, what does R, J, and M mean in your library spreadsheet?
Once the executives learn that they can deliver binary blobs through the browser, that's the end game for the current distribution model. Piracy will be crippled at the knees and everything will become SaaS.
Microsoft has signaled towards this direction when they talked about 10 being the last version of the OS, and the Office suite slowly porting more features to Office 365. Have you seen how aggressive the OneDrive nags have become recently?
I fear for a world where PC's more closely resemble Chromebooks than the traditional offline first binary model of today. I can see the benefits this could bring to an end user, but I personally feel the price of freedom and privacy is too high.
Apparently they never said this, though didn't deny it either. Now with Windows 11 it would seem they are back to selling new OS software.
The advantages are that you don't need bloated software to do stuff, you have the full power of the OS, because you have a local webserver running, you have access to the file system, etc, you have the choice to use any programming language and framework (not be limited to JS), etc.
I keep thinking why people don't go this way. Are there any glaring mistakes to this approach I am unable to see?
Or, even a full web browser view embedded inside a custom window. (If users expect a non-browser UI)
The only argument for native is if resources are such that make a web app impractical for most people (high performance GPU intensive stiff). Otherwise, sure, Electron isn't that efficient and takes up relatively a lot of space, but we are at the point where space and RAM are abundant, so it is not a limiting factor for most people.
> The last five applications I installed are Electron apps.
The last few companies I've worked at made their mobile apps using React Native[1].
> In ten years nearly every desktop app that isn't over ten years old will be a progressive web app or a containerized (e.g. Electron) web app.
Some of the apps I have installed on my phone are progressive apps, one of those decided to promote their PWA over App Store / Play Store because they didn't want to share revenue with Apple/Google, the revenue issues with mobile stores have been in the news a lot recently, I wouldn't be surprised if this became more common in the future.
[1] worth noting I'm not a mobile dev so my own skillset doesn't have anything to do with how those companies make their apps.
Just worth noting that it's not just JavaScript that makes it web-developer-friendly though, it's also its HTML-like templating system and its CSS-like styling system.
Anal sex is "cross platform" too. It doesn't make it the superior choice in a large majority of cases.
I actually find myself a lot more productive (i.e. can build a given feature faster) with Xcode+Swift+AppKit than VSCode+Typescript+React+Electron[0], and the near-unanimous disdain for Electron-based apps here gives me a lot of confidence that being a truly native app might actually be its own selling point.
[^0]: I learned to program in the early iOS days, spending 3–4 years tinkering around before moving to web dev for the past ~7 years. This is my first project using Swift.
That's fine, though. My plan for retirement is to make millions supporting desktop apps that can't be replaced because the "web for desktop" programmers have a ceiling on the level of app complexity they can handle. Line of business apps require 1 to 2 orders of magnitude more effort and so the things written before that paradigm are not economically feasible to replace.
If you thought knowing COBOL in 1999 was profitable, just wait 20 years until only a few old-timers know how to maintain the millions of custom WinForms or VB apps that make businesses work.
In the same vein as the Dark Matter Developer post that occasionally pops up on here, most of the world's software is Dark Matter Software. Mountains of native software quietly runs the world, completely oblivious to the churn we're discussing. Replacing their functionality with a webapp is either impossible or just not worth it.
With novel means of deploying sandboxed apps the line will continue to blur.
Instead, cross platform development is "eating" the desktop.
OP, if you’re reading this, I’m sorry you had to go through that.
EDIT: misread. Still doesn’t justify any of the hate.
The other option is what Google is doing. No native apps at all. Have a chrome tab open for everything. Chat, Gmail, calender, meet, YouTube music. Evrything in its own tab, no apps for any platform. Fuck that.
The piece is from 2017 but it's pretty prescient when it recommends web based interfaces as a way for linux to leapfrog into that world. Reminds me of Flutter being adopted by Ubuntu recently which does very well as a web/desktop/mobile platform.
What proportion of desktop apps are computer games?
Right now I am working on a side project in Flutter, it is in the very early stages but the ability to target multiple platforms, web, multiple desktop environments, multiple mobile platforms from a fairly singular code base is rather interesting. This makes good commercial sense, in practical thinking speeds up development and release. Yep issues may arise.
I would not hesitate to say that for many users the average users that web based apps, either browser based or electron or whatever are suitable in a lot of cases. There are some cases where this does not make sense currently, like computational (although), video/audio editing, etc. However look at tools like Google Colab where machine learning is being pushed server side because of the power of 3rd party infrastructure.
The web just makes sense in a lot of cases. Ease of development, maintainability, cost, UI, accessibility (availability).
