This intrigues me, mostly because my mom works for Google and that's all she has for work and it looks painful to me. Granted, I've not used a Chrome OS laptop, but I greatly prefer a desktop app to a web app. And I don't think I could get by having to use Google Docs instead of Microsoft Office. I've tried to do that on my computer and really disliked the experience.
Also, what does R, J, and M mean in your library spreadsheet?
I think it's valid to like desktop apps, not saying it should be the only option, just that it can be done quite painlessly. It's family names in our family :)
I don't know how well thought this article is, due to a number of use-cases where desktop apps dominate (high performance, GPU, extreme latency sensitivity), and I don't see that changing. I think we are more likely to see some stratification between different types of apps.
I think this is probably true, but I kind of hate it. It's such a staggering waste of computing resources. I don't know, maybe we can get to the point where these apps that include an entire browser are highly optimized but it's still kinda nuts.
Recognize this is a stepping stone toward a better experience.
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.
Arguably this exists right now, at least I know Microsoft kind of has it, but a lot of the web is always going to inherently be more expensive (much higher RAM usage, 3 stage JITs, etc)
OTOH, JavaScript is a poster child for what optimization can do on a language level.
If one were to propose Node.js to a developer 10 years ago, it probably would’ve been seen as a fantasy, but today many production apps run in Node and actually work.
I suspect that with WASM and further development of the Java/Typescript ecosystem, we’ll see highly performant web apps running complex loads in the next 5 years (for better or worse).
> 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.
React Native is much more native than Electron, though. There’s no “web” involved in React Native. It just happens that the language (JavaScript) is also used by the web platform.
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.
FWIW, the styling system mainly talks to the parameterized native components that the build system pulls down from GitHub. You can do the same kind of thing in SwiftUI using View Modifiers.
When there was a single platform (Windows), native made sense as either way it was one codebase. You now need to support at least two desktop platforms and some computers now only support web stuff (Chromebooks).
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.
But what cross-platform native toolkits really work and are easy to get started with? I would love to see some sort of CSS -> native GUI UI kit, or maybe something like what Sublime Text has if it were open-sourced.
I may be biased, but I think Qt is pretty great :)
It's C++ though. Some people use PyQt. It's popular in some niches, e.g high end VFX packages, especially plugins.
Maybe I've just lived in the webdev world too long and been spoiled by CSS, but making layouts work and fit together is so horribly confounding in Qt and other such frameworks that it makes me want to bash my head against the wall (and I do that enough with CSS).
> I took the post offline after about a week because I received among other things DDOS attacks and frothing at the mouth e-mails including one sent from a throwaway e-mail that actually made threats of physical violence against myself and my family.
What is wrong with people? It’s not like he wants crappy Electron w/Javascript to replace desktop with all its flaws! He acknowledges the main issues for webapps and proposes solutions.
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.
I’m not sure one will eat the other. The two will converge. The technologies typical of desktop apps like GPU acceleration, type safe languages, AoT compilation, multithreading etc - all of those things have rather recently moved from being somewhat or entirely desktop exclusive, to being on the web.
With novel means of deploying sandboxed apps the line will continue to blur.
Should have a [2017] appended to the title. When I first saw the title I thought "You're a bit late", but when I clicked on the article and saw it was from Dec. 2017 I thought this is just around the time I felt like that tipping point was reached.
very likely, if you take a sort of long historical view then it's I think intuitive to predict that the ark of computing bends towards greater and greater connectivity, and the web is the basic infrastructure for that. Hardware and operating systems just become details and everyone hooks into the matrix pretty much.
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.
The usual retort is "people use Electron because they only know web technologies".
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.
Completely agree. I'm developing a desktop app with Qt and while the API is pretty nice for most of the logic, there's just so much friction when it comes to the GUI design, I feel like it's working against me. Compared to designing in HTML/CSS, it's night and day.
I wanted to do a mockup of a UI a few moth back. It was moderately complex, I suppose. And I was just trying to find something that would let me build out a shell. I started on Linux and I found most of the UI frameworks to be quite disappointed and a bit involved for what I was wanting to do. I think I was splaying with Glade and then QT creator and realizing just how much boilerplate code I'd have to write to get things to look how I wanted.
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.
Lazarus is still pretty nice for putting together an app: the Cocoa port is still a bit unstable, but the app it self captures a lot of what was great about Delphi in the 90s
I unabashedly love WPF but I 100% agree on the need for a CSS-like interface for styling. It's a blind spot that was forgivable ten+ years ago but nowadays there's really no excuse for it.
JavaFX + Scene Builder gives you that. FX CSS isn't exactly the same as HTML CSS but it's quite close. When I've used it I've felt that the limits on the styling of my app are mostly my own lack of design skills.
React native locks you into react. Their debugging tools are sub par, especially using two different JavaScript engines for production and debugging is a source of frustration. The platform has historically been unstable, requiring heavy investment to update the system with every new release.
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.
> It's like comparing the productivity of Python to C++.
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.
For comparison the best UI building experience I ever has was with Motif. There was a high degree of orthogonality, each dialog box could have Rows or Columns, and those could both contain either Rows or Columns. You go down the tree until you have your foundation elements, buttons and the like. It was so easy. And after that it was just filling in the callback functions for the events.
Yeah, This I agree. Even WPF is too complicated, in spite of including XML based UI and binding paradigms.
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.
This is how I think of QML. I don’t think C++ and Qt as accessible as JavaScript, but QML will get you pretty far before you have to wiring the business logic.
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.
Odd take, given that with web we end up doing a lot of implementing and styling widgets that are free in desktop toolkits. In three or more languages, scouring docs from every corner of the web at that.
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.
As someone with a similar background that only applies if we are speaking about CRUD forms, anything else Web is a joke versus native tooling for GUI design.
Disagree with you, I find the grandparents observations to be right on. Especially for layout, I haven't seen a layout system that can match html/css for all screen sizes.
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.
Since you haven't provided any actual arguments, one would have to rely on your reputation to evaluate the claims you made, but since this is a new account with only one post, that's not providing any support either.
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? :-)
I didn't provide arguments because there are other articles explaining why reactive/declarative programming is superior. I just wanted to point out that there are experienced GUI programmers who find web tech better for this purpose, it's not just kids who only know JavaScript.
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.
Since the gui-fication of everything, nothing has made making a gui easier than web apps. The reason I like it is because of the cross platform capabilities. I don't have to worry about compiling for different platforms. I don't need to worry about platform specific issues. It's the ultimate form of portable code honestly nowadays.
Right. Web for UI is fine for a lot of things. The bigger concern to me is losing offline support and control of the data as it all moves into the cloud.
Electron is a large step backwards in usability and software quality. Spotify has its own context menus which don't support arrow keys or type select. GitHub Desktop has a "Select All" which doesn't actually Select All, only what's been paged in. VSCode doesn't confirm key equivalents by highlighting the menu bar. All of them blink the cursor even without typing focus. All of them steal focus at launch.
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.
Even just "what elements on the screen are clickable" would be a huge improvement, not to mention visual feedback that you've clicked/touched such an element. At least loading indicators are back in fashion, the brief period where it was assumed everything would be instant and so they binned visual feedback that the user is awaiting something is over.
VS Code is my favourite software of all time, no need to use the menu bar with the command pallete and the excellent custom keybinds. It completely gets out of the way it is still more feature rich than any IDE through extensions. A blinking cursor is a small price to pay, I haven't even noticed that. I know it's not meant to be good being written in mostly TypeScript, but it just is.
An example of why it matters: hit command-S to save your file. Native apps confirm the save by highlighting the menu bar until the save is complete.
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!
Speaking of which, it also changed the decades old symbol for unsaved files (an asterisk) for no discernable reason. Given that it also doesn't save on loss of focus it led to my many WTFs when I first started using it.
VS Code has some of the worst product quality I've seen from Microsoft in quite a while. It doesn't hold a candle to IntelliJ or Visual Studio. Even directly comparable "lightweight" editors like ISE are far superior.
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.
> 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.
It has this now, although the click target is some teensy text.
(I also find the search very frustrating, like it replacing the search with your current selection sometimes)
This function is handled by the DOWN arrow in other text editors!
I just tested a bunch:
VS Code: UP
Visual Studio: DOWN
Notepad++: DOWN
TextPAD: DOWN
IntelliJ: ALT+DOWN
MS Word: DOWN
Sigh... I have no words. It's just so sad that I expected this. I literally pressed "DOWN", it didn't work, there's no drop-down GUI indicator, so I just assumed it was a missing feature.
Instead, it's yet another feaure where the VS Code team picked something at random without apparently ever having used any other text editor or IDE in their lives. Ever. Ever before. Of any type, from any platform. Certainly not Microsoft products on Windows.
It boggles the mind. Are they all JavaScript front-end developers with no previous IDE experience other than notepad.exe or something?
What I love about VI and vim is that every time it comes up, I can't help but bring up this little bit of history:
"Joy used a Lear Siegler ADM-3A terminal. On this terminal, the Escape key was at the location now occupied by the Tab key on the widely used IBM PC keyboard (on the left side of the alphabetic part of the keyboard, one row above the middle row). This made it a convenient choice for switching vi modes. Also, the keys h,j,k,l served double duty as cursor movement keys and were inscribed with arrows, which is why vi uses them in that way. The ADM-3A had no other cursor keys. Joy explained that the terse, single character commands and the ability to type ahead of the display were a result of the slow 300 baud modem he used when developing the software and that he wanted to be productive when the screen was painting slower than he could think."
Yeah. Let's copy what a specific terminal did in 1976. That doesn't actually fit any modern keyboard layout. Brilliant. That's the standard to aim for! Not the most popular computer system on earth, by any metric. Nope. That's not the standard. The standard is the ADM-3A terminal, which probably fell into disuse before any of the Windows Terminal developers were born...
Did I mention the 300 bits per second terminal being the key design constraint? Oh, I forgot to mention that while entering this text on my gigabit fibre connection.
You're reading this on a phone? Is it 5G? Then it's faster than my fibre.
the fact that it was built under certain constraints, which are no longer applicable, does not mean that the design is no longer valid -- it just means it may no longer be valid.
"constraints breed creativity" is the idea that you can end up with a better, more versatile solution -- rather than copping out at the first "good enough" solution. Of course, it's not guaranteed, but still. It's certainly possible that arrow keys are a mistake for total performance (arrows are trivially more visible, but also trivially greater motion from your other work). It's also certainly possible that modal editing is simply more effective than mouse & hotkeys, even if they were only designed because the mouse wasn't available.
Now, escape vs caps-lock-position, I'll give you freely, but generally its fair to judge a design based on current constraints, but not to judge (& discard) a design because it was designed other alternative constraints.
Every time this assertion is brought up I can't help but bring up this counterpoint:
People continue choosing to use vi-keys (via vim, nvim, or even the many vim-emulation layers all over the place), even on modern high-speed connections, precisely because they still find "single character commands and the ability to type ahead of the display" valuable.
"The display" does not have to be a terminal display. In fact, a significant number of places vi-emulation is used don't even support terminal displays. "The display" can be anything the human waits for to reflect the actions of keys pressed. Once you consider this, the efficiency benefit of vi-keys becomes as clear as that of touch-typing.
The ADM-3A no longer matters. Vim does not use vi-keys because it ever targeted the ADM-3A. Similarly for Neovim, Evil, Tridactyl, Vimium, GMail (and so on). When I wrote a new vi-keys layer for a toy terminal multiplexer, I didn't use h-j-k-l for navigation because I wanted to target the ADM-3A — I didn't even know about the ADM-3A! I did it because I knew of the benefit of using those keys, even on the modern 100+-keys QWERTY-layout that I grew up on and still use.
----
> .... my gigabit fibre connection.
> You're reading this on a phone? Is it 5G? Then it's faster than my fibre.
I cannot describe enough how much I hate this discriminatory excuse, and I live in the top two cities with the best internet connectivity in my country (for four years of my life in Mumbai, till 2020, I was one hop away from the Mumbai IXP). It is downright shameful how far people will stoop while using this excuse. An absolute minority of the population thinks it absolutely okay to build software that excludes users who don't have the absolute best hardware, just because they live in cities like SF or Seoul and are blind to the conditions of other humans. Most of these people aren't even aware how they are excluding people; that's how little they care. I can only wonder what the overlap is between this set of people and those that ignore accessibility.
You are fortunate enough to have a gigabit fibre connection (and possibly 5G) connecting you to servers from your continent, most of your time. But that is not a right you can expect others to have, and that fortune is far from universal. I am fortunate enough to have the access I do have when I have it, but I can only sympathise with the plight of those in Australia.
To be honest, I have nothing to compare it to. Most servers I connect to are outside Australia, so I guess everything has added latency and I must be used to it. I'm talking about websites here. Maybe 2-3 seconds total to load an "average" site with a fair few images?
I'm not a fan of cloud anything anyway. We have these supercomputers in our pocket and on our desks, but we're meant to use them only as dumb terminals now?
I certainly don't find things unusable, but I can still remember the heady days of 300 baud modems and reading the text as it was generated on the screen.
So everything is amazing now and 300ms latency wouldn't bother me.
Even if it was 10 seconds, I'd just open a new tab and continue what I was doing and switch back to the original one when it eventually loaded.
I think VS Code in this case is just trying to emulate the behavior of terminal history. Another commenter mentioned that Vim was the same. Up and down arrow navigating history seems to be a more common thing in the Unix-y world, which VS Code is trying to appeal to.
Every tools takes getting used to and learning it's quirks. Where there are problems within VS Code, there will be different problems in IntelliJ. I quite like VS Code while disliking IntelliJ. Same old story of differing preferences.
> Someone thought that manually editing JSON files is a suitable GUI for configuring basic settings.
There has been a GUI editor for settings for a while now, as well as the JSON editor.
VS Code has improved so much in such a short period of time, if people are comparing to a 6 months ago there has been endless improvements. I really like Intellij, think it's great as well, but it makes you do things in certain way depending on what language you're using. After learning how VS Code works you can use it however you want with whatever language you want.
I'm on the absolute latest build. All of those issues are from this release.
The previous releases were markedly worse, and absolutely unusable for PowerShell. I've never seen anyone switch from ISE to VS Code willingly. I'm forced, because I'm using some modules that are core-only and required PS 7.0, which works with VS Code only.
It doesn't matter if it has "improved" a lot if it is still by far the worst text editor slash IDE on my computer. I have five others, including two free editors that are better. And faster...
> Every tools takes getting used to and learning it's quirks.
There's necessary differences and quirks, and there's just... unfathomable hubris by the developers, to the level that it's almost an insult to their user base.
Why not alt-drag? EVERY Microsoft tool uses that shortcut EXCEPT for VS Code!
Was it not written by Microsoft developers? Is it conforming to a standard I've never heard of, a standard that nobody else at Microsoft has ever heard of either?
Why didn't they most simply and most trivially just copy the default keyboard shortcuts from Visual Studio? Wouldn't that have been easier for everyone?
Writing something "new" doesn't meant that you're forced at gunpoint to change standards, ignore commonalities, or just do a bad job. It takes the same coding effort to configure "alt-drag" as it takes to configure "middle-drag"! There is no time saved by being sloppy, or lazy. This isn't a corner being cut to save time, this is a reversing of the direction that the steering wheel has to be turned. That doesn't help you manufacture the car faster or cheaper, and it doesn't help drivers.
> VS Code ... is still more feature rich than any IDE through extensions.
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).
I program mainly in Go, Python, TypeScript and some C/C++. A year ago I would have agreed with you, but one extension for each language now gives you almost everything you need. I bounce back to Goland, Webstorm, CLion and PyCharm occasionally as they have much more reliable refactoring, and have some really nice features missing from VS Code, but being a Polyglot VS Code makes it so much easier to use similar keybindings and processes across languages, I don't have to fight the IDE to get it to do what I want. Both great tools but my daily driver became VS Code a few months ago, it's pulled ahead in my opinion despite being free.
You could always install additional language support in your main JB IDE too. I could see some point if you're constantly working in 3+ unrelated languages for sure, but I don't think that's the typical day to day workflow of most people.
The refactoring, intellisense, and bonus features are hard to give up once you get used to them. A good Go debugger, actual Unity integration that inspects the scenes, references, usages, etc, or Python type hinting actually helping the development effort, are just some things that come to mind.
It's cool there's an open source editor that does most things quite well for sure, but a hundred dollars or so is extremely worth it, if you're even 1% more productive. I'd estimate the real boost I got from JB products is much higher, particularly when it came to Go and C#.
I'm the author of this, and I don't completely disagree. I don't think the web engine is that bad of a UI layer, but it's nowhere near the best.
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.
Operating systems have different features and conventions. And why would vendors care what cross platform technologies you use?
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.
> Many Electron fans talk about how apps should look and feel exactly the same on every OS
Don't you think it's a good idea to have consistent UI and UX cross platform? If a user switches between the mobile/mac/Windows/web version, everything should change?
> And it isn't like Slack or Microsoft don't have the resources to make native apps.
Considering Microsoft seemingly don't have the resources to make a functional Electron app for Teams, and the Linux and macOS versions are always late and buggy, apparently they can't.
> Don't you think it's a good idea to have consistent UI and UX cross platform?
No. Users don't typically switch platforms often. End users expect applications to be consistent with other applications on their platform. If every other application on my system uses ⌘Q to quit, and yours doesn't because you're trying to be consistent with some other platform I've never used, then yours is going to seem like it has the broken UI.
> No. Users don't typically switch platforms often
Users don't switch between mobile, PC? By far the most common mobile and PC OSes, Android and Windows, look nothing alike. Using something as simple as a chat app on both in "native" modes can be a burden. I
1. Users definitely don't want consistency across mobile and desktop. Mobile interfaces displayed on a desktop look like ultra-simplified toys and desktop interfaces displayed on mobile are too dense.
2. The article/thread is about native vs. web UIs on desktop platforms so not sure how mobile is even relevant.
> Mobile interfaces displayed on a desktop look like ultra-simplified toys and desktop interfaces displayed on mobile are too dense
I'm talking about consistency, not copy pasting. Google's Material Design is sufficiently consistent that switching between mobile and desktop ( web) is fine
> The article/thread is about native vs. web UIs on desktop platforms so not sure how mobile is even relevant
Indeed, but one of the main points for native UI on desktop is for native OS UX consistency, and my point is that i prefer app consistency cross platform over OS consistency. Especially when the most popular desktop OS changes its UX paradigm half-heartedly every few years.
Are you an Apple user per chance? Most people who seem to prefer "native" UX seem to prefer Apple's different way of doing UX, which i understand can be difficult when switching to a cross platform UI which is consistent between platforms and is closer to Windows and Linux UX than it is to Apple's.
Web technologies have become the most productive UI layer due to a lot of developer work on abstracting them via things like React and the many React-based view libraries.
The same kind of paradigm could be done with native-mode libraries but nobody has done it because all the momentum is behind web technology now.
My real argument was that fighting this trend may be pissing into a hurricane. All the momentum may be behind web tech, so maybe we should just focus on making it better as a UI layer and fixing its problems instead of developing native mode UI layers that nobody will use.
WASM may eventually liberate us from JavaScript. Another way to do that would be to add C/C++ level API hooks to web renderers like Chromium and WebKit to allow the DOM to be manipulated from native code. Then we could write a native UI toolkit using web view renderers with no JavaScript at all.
> 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.
Electron seems to have reached the status of being a political topic. For many people it's something to rally around or (more frequently here) against. You're either for it or against it.
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)
Of course any point is meaningless when you define it as such for yourself. Your differing perspective and casual dismissal doesn't make their points any less relevant.
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.
But... I didn't dismiss them, I specifically addressed the flawed structure of their argument.
They made some more assertions in the second paragraph but didn't offer any support for them so I haven't addressed them separately.
With something like:
"Undo support used to be table stakes, but now I'm surprised when it works" —I have to go back to the "two Electrons" I mentioned previously: not sure what world this is where software and business interests have so radically altered as to no longer support e.g. undo. It sounds like they ran into a bug related to undo somewhere and now are weaponizing the fact (as in their first paragraph) as a general argument against the framework.
These are not "random bugs" but deeply established Mac UI conventions. My point is not "Electron apps are buggy," it's that they are undermining an established set of UI conventions, without advancing a replacement.
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.
Okay I think I see what you're saying here. The terminology of reducing "UI vocabulary" threw me off some, since you could alternately describe it as an expansion of UI vocabulary: so many things don't have a convention yet that every developer is free to define their own (similar situation in e.g. video game UI where there's constant invention since a fixed widget set isn't getting re-used).
> ... they are undermining an established set of UI conventions, without advancing a replacement.
> There's a virtuous cycle when apps use a platform's native components
There's certainly an advantage there, but it basically comes down to whether you more highly value cross-platform capabilities or specialization for a specific platform. So why not acknowledge it as the tradeoff it is? Instead the common stance here is to frame it as some kind of cataclysmic regression in software development.
Anecdotally, as someone using mostly Electron-based software, I've yet to run into any kind of issue related to platform integration—but I wouldn't be surprised if people ran into an occasional glitch or inconvenience there. It makes sense given what the software is.
> whether you more highly value cross-platform capabilities or specialization for a specific platform.
I'd argue that very few, if any, end users care that an application works and looks exactly the same on Windows vs. Mac vs. Linux. The typical end user has one platform they use, and they expect their applications to behave consistently with each other on that platform.
The people who tend to care about being consistent across platforms are 1. developers who don't want to write platform-specific code to properly support each platform, and 2. designers for whom platform conventions are inconvenient constraints and get in the way of the great vision they drew in Photoshop. In other words, not end users, who are usually the actual target market.
I agree with your analysis, but there's a little more to it. Indirectly, there are two important ways in which end users benefit significantly:
1. Higher likelihood that the app will be available at all on their platform.
2. Companies/developers are able to direct resources more to features end users are actually interested in, vs spending on rebuilding for multiple platforms.
I think both Discord and VS Code are pretty solid examples of this. The rate at which they delivered their extensive feature sets to mac/win/linux felt like something totally new: I don't recall any other case of seeing such high quality, complex software show up for multiple platforms so suddenly in that way. (Of course I'm very intentionally saying 'felt' here—I have no objective measure)
> 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)
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.
I only upgraded from my 8GB laptop a couple months ago. And I did run into issues with memory frequently—but here's the thing: I would be running 4 or 5 Electron apps at the same time and they were fine; the memory issues were always from Chrome, so I had to be careful not to keep too many open Youtube, Github, Amazon, etc. tabs open.
A heavier Electron App, e.g. Slack, would be equivalent to maybe two Youtube tabs, out of the ~50 tabs I would have open.
It's not ideal, but it's nowhere near as egregious as comments on HN would leave you to believe.
> 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
I'm not familiar with this argument. How is it a poor citizen aside the dubious claims about excess memory usage? Or is this just a repetition of that argument?
(Incidentally I've also had the misfortune of using MS Teams recently, and I would fully support anyone's complaints about it.)
I dunno. The trouble with web apps is that they keep changing, usually to the detriment of the user. The first one is always free. Then they start charging. Or they add ads. Or they use your info for marketing.
How does security factor into this? Seems like we keep exposing more and more data to networks while at the same time collecting more and more data on everyone. It doesn't seem like a great combination for those who have to protect this data nor for those who will be the most harmed if it gets out (the folks the data is about, not the companies that leaked it).
In theory, though many Electron apps end up serving as an isolated browser window to serve a web view or PWA, behavior which is discouraged/harder in true native app development.
The webification of Desktop app GUI’s is the result of a total disregard for usability .. from a user’s point-of-view (not a developer’s point-of-view of what users >should< want). Most young devs I speak to stare blankly at me when I enquire about GUI standards and usability best-practices. They are now foreign concepts to a lot of developers.
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.
I agree that there's a lot of form-over-function and bad usability decisions in apps but that's completely separate from the underlying frameworks and distribution technology. You can have great webapps and terrible native apps.
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.
True, the user doesn’t necessarily know a ‘native’ UI from a familiar/consistent UI. The two major OS’s used to be the promoters of well thought-out standards and consistency. The two went hand-in-hand.
> I agree that there's a lot of form-over-function and bad usability decisions in apps but that's completely separate from the underlying frameworks and distribution technology. You can have great webapps and terrible native apps.
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.
Desktop, phone, and tablet apps don't really work the same anyway. Except when they're just scaled up. But everyone agrees that's bad.
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.
It's not always the same user but a team or entire organization using the same tools, and it helps to unify the experience.
Contrast that with something like Outlook which has a dozen different UIs depending on app or device or website. It causes way more friction than just having the same workflow everywhere.
You make it sound like users are switching among Windows, Linux, macOS, Android and iOS all the time so the app UI has to have the lowest common denominator. By and large they're not and as such the native UI is the consistent UI: the apps launch the same way, you know how to get to settings or the trash can and the gestures all do pretty much the same thing to get the same result.
Most of that is true (well, except for web frameworks bring great; I don't think anything about web development achieves greatness) but, where Apple is concerned, much of the problem is the short release cycle they moved to about a decade ago.
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.
Yes, I understand that. The applications I’m thinking of are those that either have a longer shelf-life and/or are business applications. In Finance, for example, many important vendors have been rolling-out trading front-ends based on web frameworks (maybe Electron for all I know). They are absolutely terrible, again, because of the lack of standard UI usability rules. Combine that with very poor documentation, and non-existent training and it’s a disaster.
I emphatically agree with that. My complaint is that it feels like a hopeless battle to try and write good native desktop software today. Every year the OS's APIs and UI change... that means weeks or months tweaking your project every year until you end-of-life your app.
The ability to launch an old Mac binary is different than the Xcode project you used to build it being healthy. A developer can't open a ten year project and just submit it to the app store. Most likely it won't even build.
> Most young devs I speak to stare blankly at me when I enquire about GUI standards and usability best-practices. They are now foreign concepts to a lot of developers.
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.
True but the old toolkits did most of that kind of thing for free. You had to do work to break conventions. With web you and your chosen set of libs have to work to meet them. One model is better. ;-)
> As a user, I don’t care about the dev’s challenge of supporting multiple OS’s
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.
I would argue using Electron encourages a culture of making your software cross-platform. I am a firm believer in making good things easy and bad things hard.
On principle I agree that GUI consistency is something that should be striven for, however when I look at the success of the web and apps, all of which have extremely non-uniform designs, it seems like the users really just don’t care and seem to be able to adapt to anything. That’s not to say they are power users; most users seem to be interested only in the bare minimum needed to do what they want, which doesn’t require mastery.
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.
Users can adapt to anything because they're flexible and smart. Humans can put up with a lot of problematic things and find their way through anyway, but that's not a great justification for doing so. I think if you want to make a user-centric argument about this, it's that users like web apps because although the UIs end up primitive and inconsistent, the benefits are worth it, benefits like:
- "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 kind of odd that you mention Apple as a company that has "ditched standards", considering it's got very public, detailed design standards and has had them for a very long time.
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.
This may be beyond some people's comprehension, but where I work we're receiving huge amounts of push-back trying to move from green screen to Windows GUI apps. Yes, really. We tried explaining this to a "modern" developer and it's like we were speaking a different language. They couldn't get it, at all.
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.
The benefits of web based apps in the majority of cases I would say far outweigh any other issues.
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).
I've been saying a a version of this (the browser will eat the OS) for a few years now, really as soon as I heard about WASM.
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.
The main advantage of writing a program instead of an app is that you can utilize all of the power of the underlying operating system to give the user an experience that is fast, user friendly, and efficient.
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.
> 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 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.
My limited experience with App stores is that there are usually a large number of "fake" apps that are indistinguishable from the real thing. Has this been addressed on the platforms you're familiar with?
That's a fair comment. But I believe the number of these is probably a small percentage given the size of the stores (at least for Apple). At least in the case of my mother, she has somewhere to go to when there is a problem.
I am not discounting the personal computer as a utility, but app stores and restrictions for some are not a hinderance either. With a mac (I am not sure about windows, I gather with ARM it is not possible), the ability to be in a hybrid mode suits most cases.
A mobile device at least from an Apple perspective is not a general computing device. Android on the other hand is more general purpose. But even with Apple's case there are ways to deploy your own app to your own device.
At least in the desktop space there is a choice, and it's not bad thing.
I have seen most fakes in Apple store, especially targeting apps that weren't available in App Store by itself - so if you were searching, you wouldn't get any good result out.
Who said anything about giving up? But if you need a UI that's cross-platform compatible with literally zero effort, good luck beating something like React/Vue running in a webview that works both online, offline, and happily on android and ios to boot.
You can do that with JavaFX as well actually. Not many people know about it or do it but you can compile the same codebase to Windows, Mac, Linux, Android and iOS. It's not particularly high effort. You can get native binaries without JIT compilation out the other end.
Having created JavaFX apps in the past: that's comparing mopeds to racecars, because the actual code writing part in JavaFX is so much more tedious. The upside of moving fast and breaking things (which you're absolutely going to with a webview app) is that you move REALLY fast, and breaking things is almost trivially fixed because everything lets you either look at the dev console directly, or attach a dev console in seconds, and off you go setting your breakpoints and var watchers.
(and as always, how bad you break things and how quickly you can determine where and how to fix it has nothing to do with the choice in tech, and everything to do with your experience as a software engineer, or "dev" as we apparently call folks these days)
More tedious than HTML? That's a surprise. Java is more verbose than JavaScript it's true, but I've been using Kotlin for years and Kotlin is more concise than both. HTML doesn't even have much of a widget library beyond a few basics, so to get even close to the basics JavaFX provides you need to import a whole pile of libraries.
I'm curious to learn more about the dev console thing. The dev console is a nice thing but you're talking about breakpoints and watches. Any IDE has a great integrated debugger, and with JavaFX you can step into the entire GUI framework right now to where it issues draw calls to Direct3D or OpenGL, so it's far more debuggable than a webview. I would understand more if you were talking about things like the network explorer views, but debugging? Java debuggers are great!
I'm early in the tinkering/prototyping phase of a developer tool (not a text editor) that is native AppKit, and it'll stay that way if/when I release it.
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.
162 comments
[ 5.1 ms ] story [ 221 ms ] threadAlso, what does R, J, and M mean in your library spreadsheet?
I think "Linux Container Thing" is actually a better name than "Windows Subsystem for Linux."
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.
If one were to propose Node.js to a developer 10 years ago, it probably would’ve been seen as a fantasy, but today many production apps run in Node and actually work.
I suspect that with WASM and further development of the Java/Typescript ecosystem, we’ll see highly performant web apps running complex loads in the next 5 years (for better or worse).
> 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.
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.
Also, Qt's licensing model is sub-optimal IMO.
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.
With novel means of deploying sandboxed apps the line will continue to blur.
Instead, cross platform development is "eating" the desktop.
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.
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 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.
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.
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.
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.
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.
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.
Now you have seen one.
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.
Anal sex is "cross platform" too. It doesn't make it the superior choice in a large majority of cases.
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.
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!
If a save is complete, that dot will go away. If there is no dot, the file is unmodified.
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.
It has this now, although the click target is some teensy text.
(I also find the search very frustrating, like it replacing the search with your current selection sometimes)
I just tested a bunch:
Sigh... I have no words. It's just so sad that I expected this. I literally pressed "DOWN", it didn't work, there's no drop-down GUI indicator, so I just assumed it was a missing feature.Instead, it's yet another feaure where the VS Code team picked something at random without apparently ever having used any other text editor or IDE in their lives. Ever. Ever before. Of any type, from any platform. Certainly not Microsoft products on Windows.
It boggles the mind. Are they all JavaScript front-end developers with no previous IDE experience other than notepad.exe or something?
Wait... Electron. Ah. They probably are.
"Joy used a Lear Siegler ADM-3A terminal. On this terminal, the Escape key was at the location now occupied by the Tab key on the widely used IBM PC keyboard (on the left side of the alphabetic part of the keyboard, one row above the middle row). This made it a convenient choice for switching vi modes. Also, the keys h,j,k,l served double duty as cursor movement keys and were inscribed with arrows, which is why vi uses them in that way. The ADM-3A had no other cursor keys. Joy explained that the terse, single character commands and the ability to type ahead of the display were a result of the slow 300 baud modem he used when developing the software and that he wanted to be productive when the screen was painting slower than he could think."
Yeah. Let's copy what a specific terminal did in 1976. That doesn't actually fit any modern keyboard layout. Brilliant. That's the standard to aim for! Not the most popular computer system on earth, by any metric. Nope. That's not the standard. The standard is the ADM-3A terminal, which probably fell into disuse before any of the Windows Terminal developers were born...
Did I mention the 300 bits per second terminal being the key design constraint? Oh, I forgot to mention that while entering this text on my gigabit fibre connection.
You're reading this on a phone? Is it 5G? Then it's faster than my fibre.
"constraints breed creativity" is the idea that you can end up with a better, more versatile solution -- rather than copping out at the first "good enough" solution. Of course, it's not guaranteed, but still. It's certainly possible that arrow keys are a mistake for total performance (arrows are trivially more visible, but also trivially greater motion from your other work). It's also certainly possible that modal editing is simply more effective than mouse & hotkeys, even if they were only designed because the mouse wasn't available.
Now, escape vs caps-lock-position, I'll give you freely, but generally its fair to judge a design based on current constraints, but not to judge (& discard) a design because it was designed other alternative constraints.
People continue choosing to use vi-keys (via vim, nvim, or even the many vim-emulation layers all over the place), even on modern high-speed connections, precisely because they still find "single character commands and the ability to type ahead of the display" valuable.
"The display" does not have to be a terminal display. In fact, a significant number of places vi-emulation is used don't even support terminal displays. "The display" can be anything the human waits for to reflect the actions of keys pressed. Once you consider this, the efficiency benefit of vi-keys becomes as clear as that of touch-typing.
The ADM-3A no longer matters. Vim does not use vi-keys because it ever targeted the ADM-3A. Similarly for Neovim, Evil, Tridactyl, Vimium, GMail (and so on). When I wrote a new vi-keys layer for a toy terminal multiplexer, I didn't use h-j-k-l for navigation because I wanted to target the ADM-3A — I didn't even know about the ADM-3A! I did it because I knew of the benefit of using those keys, even on the modern 100+-keys QWERTY-layout that I grew up on and still use.
----
> .... my gigabit fibre connection.
> You're reading this on a phone? Is it 5G? Then it's faster than my fibre.
I cannot describe enough how much I hate this discriminatory excuse, and I live in the top two cities with the best internet connectivity in my country (for four years of my life in Mumbai, till 2020, I was one hop away from the Mumbai IXP). It is downright shameful how far people will stoop while using this excuse. An absolute minority of the population thinks it absolutely okay to build software that excludes users who don't have the absolute best hardware, just because they live in cities like SF or Seoul and are blind to the conditions of other humans. Most of these people aren't even aware how they are excluding people; that's how little they care. I can only wonder what the overlap is between this set of people and those that ignore accessibility.
You are fortunate enough to have a gigabit fibre connection (and possibly 5G) connecting you to servers from your continent, most of your time. But that is not a right you can expect others to have, and that fortune is far from universal. I am fortunate enough to have the access I do have when I have it, but I can only sympathise with the plight of those in Australia.
Australian here with 250mbit at home and 5G on my phone.
I still hate Electron apps though.
– Someone who has to work on servers in America & Europe from India, with 300+ ms latency via GCP's Premium Network
I'm not a fan of cloud anything anyway. We have these supercomputers in our pocket and on our desks, but we're meant to use them only as dumb terminals now?
I certainly don't find things unusable, but I can still remember the heady days of 300 baud modems and reading the text as it was generated on the screen.
So everything is amazing now and 300ms latency wouldn't bother me.
Even if it was 10 seconds, I'd just open a new tab and continue what I was doing and switch back to the original one when it eventually loaded.
> Someone thought that manually editing JSON files is a suitable GUI for configuring basic settings.
There has been a GUI editor for settings for a while now, as well as the JSON editor.
The previous releases were markedly worse, and absolutely unusable for PowerShell. I've never seen anyone switch from ISE to VS Code willingly. I'm forced, because I'm using some modules that are core-only and required PS 7.0, which works with VS Code only.
It doesn't matter if it has "improved" a lot if it is still by far the worst text editor slash IDE on my computer. I have five others, including two free editors that are better. And faster...
There's necessary differences and quirks, and there's just... unfathomable hubris by the developers, to the level that it's almost an insult to their user base.
Why not alt-drag? EVERY Microsoft tool uses that shortcut EXCEPT for VS Code!
Was it not written by Microsoft developers? Is it conforming to a standard I've never heard of, a standard that nobody else at Microsoft has ever heard of either?
Why didn't they most simply and most trivially just copy the default keyboard shortcuts from Visual Studio? Wouldn't that have been easier for everyone?
Writing something "new" doesn't meant that you're forced at gunpoint to change standards, ignore commonalities, or just do a bad job. It takes the same coding effort to configure "alt-drag" as it takes to configure "middle-drag"! There is no time saved by being sloppy, or lazy. This isn't a corner being cut to save time, this is a reversing of the direction that the steering wheel has to be turned. That doesn't help you manufacture the car faster or cheaper, and it doesn't help drivers.
( I'm not being flippant, the VS Code team literally flips things for no reason. See: https://news.ycombinator.com/item?id=27807085 )
Comparing VS Code to ISE is next level of wrong.
You mention mostly few search and replace bugs as a proof, but those are just bugs. There also is search history just behind a hotkeys.
While I agree that search needs some love, its hardly a show stopper.
My experience is exactly the opposite - VSCode has some of the best product quality I've seen from Microsoft ever, period.
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).
The refactoring, intellisense, and bonus features are hard to give up once you get used to them. A good Go debugger, actual Unity integration that inspects the scenes, references, usages, etc, or Python type hinting actually helping the development effort, are just some things that come to mind.
It's cool there's an open source editor that does most things quite well for sure, but a hundred dollars or so is extremely worth it, if you're even 1% more productive. I'd estimate the real boost I got from JB products is much higher, particularly when it came to Go and C#.
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.
Don't you think it's a good idea to have consistent UI and UX cross platform? If a user switches between the mobile/mac/Windows/web version, everything should change?
> And it isn't like Slack or Microsoft don't have the resources to make native apps.
Considering Microsoft seemingly don't have the resources to make a functional Electron app for Teams, and the Linux and macOS versions are always late and buggy, apparently they can't.
No. Users don't typically switch platforms often. End users expect applications to be consistent with other applications on their platform. If every other application on my system uses ⌘Q to quit, and yours doesn't because you're trying to be consistent with some other platform I've never used, then yours is going to seem like it has the broken UI.
Users don't switch between mobile, PC? By far the most common mobile and PC OSes, Android and Windows, look nothing alike. Using something as simple as a chat app on both in "native" modes can be a burden. I
2. The article/thread is about native vs. web UIs on desktop platforms so not sure how mobile is even relevant.
I'm talking about consistency, not copy pasting. Google's Material Design is sufficiently consistent that switching between mobile and desktop ( web) is fine
> The article/thread is about native vs. web UIs on desktop platforms so not sure how mobile is even relevant
Indeed, but one of the main points for native UI on desktop is for native OS UX consistency, and my point is that i prefer app consistency cross platform over OS consistency. Especially when the most popular desktop OS changes its UX paradigm half-heartedly every few years.
Are you an Apple user per chance? Most people who seem to prefer "native" UX seem to prefer Apple's different way of doing UX, which i understand can be difficult when switching to a cross platform UI which is consistent between platforms and is closer to Windows and Linux UX than it is to Apple's.
The same kind of paradigm could be done with native-mode libraries but nobody has done it because all the momentum is behind web technology now.
My real argument was that fighting this trend may be pissing into a hurricane. All the momentum may be behind web tech, so maybe we should just focus on making it better as a UI layer and fixing its problems instead of developing native mode UI layers that nobody will use.
WASM may eventually liberate us from JavaScript. Another way to do that would be to add C/C++ level API hooks to web renderers like Chromium and WebKit to allow the DOM to be manipulated from native code. Then we could write a native UI toolkit using web view renderers with no JavaScript at all.
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.
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)
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.
They made some more assertions in the second paragraph but didn't offer any support for them so I haven't addressed them separately.
With something like: "Undo support used to be table stakes, but now I'm surprised when it works" —I have to go back to the "two Electrons" I mentioned previously: not sure what world this is where software and business interests have so radically altered as to no longer support e.g. undo. It sounds like they ran into a bug related to undo somewhere and now are weaponizing the fact (as in their first paragraph) as a general argument against the framework.
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.
> ... they are undermining an established set of UI conventions, without advancing a replacement.
> There's a virtuous cycle when apps use a platform's native components
There's certainly an advantage there, but it basically comes down to whether you more highly value cross-platform capabilities or specialization for a specific platform. So why not acknowledge it as the tradeoff it is? Instead the common stance here is to frame it as some kind of cataclysmic regression in software development.
Anecdotally, as someone using mostly Electron-based software, I've yet to run into any kind of issue related to platform integration—but I wouldn't be surprised if people ran into an occasional glitch or inconvenience there. It makes sense given what the software is.
I'd argue that very few, if any, end users care that an application works and looks exactly the same on Windows vs. Mac vs. Linux. The typical end user has one platform they use, and they expect their applications to behave consistently with each other on that platform.
The people who tend to care about being consistent across platforms are 1. developers who don't want to write platform-specific code to properly support each platform, and 2. designers for whom platform conventions are inconvenient constraints and get in the way of the great vision they drew in Photoshop. In other words, not end users, who are usually the actual target market.
1. Higher likelihood that the app will be available at all on their platform.
2. Companies/developers are able to direct resources more to features end users are actually interested in, vs spending on rebuilding for multiple platforms.
I think both Discord and VS Code are pretty solid examples of this. The rate at which they delivered their extensive feature sets to mac/win/linux felt like something totally new: I don't recall any other case of seeing such high quality, complex software show up for multiple platforms so suddenly in that way. (Of course I'm very intentionally saying 'felt' here—I have no objective measure)
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.
A heavier Electron App, e.g. Slack, would be equivalent to maybe two Youtube tabs, out of the ~50 tabs I would have open.
It's not ideal, but it's nowhere near as egregious as comments on HN would leave you to believe.
> 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
I'm not familiar with this argument. How is it a poor citizen aside the dubious claims about excess memory usage? Or is this just a repetition of that argument?
(Incidentally I've also had the misfortune of using MS Teams recently, and I would fully support anyone's complaints about it.)
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.
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.
Contrast that with something like Outlook which has a dozen different UIs depending on app or device or website. It causes way more friction than just having the same workflow everywhere.
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...
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.
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.
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.
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.
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).
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.
What proportion of desktop apps are computer games?
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.
I am not discounting the personal computer as a utility, but app stores and restrictions for some are not a hinderance either. With a mac (I am not sure about windows, I gather with ARM it is not possible), the ability to be in a hybrid mode suits most cases.
A mobile device at least from an Apple perspective is not a general computing device. Android on the other hand is more general purpose. But even with Apple's case there are ways to deploy your own app to your own device.
At least in the desktop space there is a choice, and it's not bad thing.
(and as always, how bad you break things and how quickly you can determine where and how to fix it has nothing to do with the choice in tech, and everything to do with your experience as a software engineer, or "dev" as we apparently call folks these days)
I'm curious to learn more about the dev console thing. The dev console is a nice thing but you're talking about breakpoints and watches. Any IDE has a great integrated debugger, and with JavaFX you can step into the entire GUI framework right now to where it issues draw calls to Direct3D or OpenGL, so it's far more debuggable than a webview. I would understand more if you were talking about things like the network explorer views, but debugging? Java debuggers are great!
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.