Nailed it. Instability is the enemy of mastery. In order to fully grok things, they need to be stable long enough to be grokked. Software has stopped being stable long enough to become an expert.
Brains learn. And then a brain that is forced to unlearn and relearn enough times eventually learns to not bother learning. So no one even bothers to become an expert anymore.
If you don't like the trend toward web-ification of the desktop, don't blame developers or Electron. Blame OS vendors for refusing to field a portable API for the large common core of desktop app functionality, something for 2D GUIs analogous to OpenGL. Why do we have standard 3D libraries, standard APIs for files and I/O, standard networking APIs, but no standard GUI API?
... because OS vendors still want to try to herd developers into building apps for only their platform. Developers (myself included) respond with "fuck you" and use web technologies.
There is also Qt, but it's fairly antiquated. It doesn't use or support the reactive UI paradigm, and after using React I can't go back. Every other GUI coding paradigm I've seen degenerates into spaghetti code.
All the other options (other than Qt or web technologies) falls down in the area of accessibility, making it not usable for serious work.
That's typically avoided by decoupling model and view and/or similar functional patterns. What else is the paradigm providing?
I doubt the framework you want them to create would change much. Many Electron fans talk about how apps should look and feel exactly the same on every OS. They say web technologies are the best UI layer by far. And it isn't like Slack or Microsoft don't have the resources to make native apps.
The 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.
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 above arguments would not be taken seriously on another topic, but here their weakness can be overlooked (by some) since folks are already committed to the the stance they support.
Look at the argument more closely: they're naming several random bugs. You can name several random bugs related to any UI framework on the planet with a sufficient user count. It's meaningless.
I'd urge people to look a little closer at arguments being put forward by the anti-Electron faction here if you don't yet have data yourself.
For myself, whenever I read these kinds of comments (or the tiresome refrain about absurd memory usage) it feels to me like there must be two Electrons: the first being the Electron which is the foundation of nearly every app I actually find useful these days (which do not exhibit e.g. exorbitant memory consumption issues [it's a marginal, non-issue increase in my experience] or higher bug-rates than native apps)—and then there's the second Electron, which afaict is a conceptual construction supporting a particular perspective on the 'correct' way of writing software (hint: anything using web tech isn't it).
Edit: something that would help move legitimate analysis of this topic forward: comparisons to other frameworks should be made after normalizing with respect to feature count/complexity, i.e. how much higher is memory usage vs. a competing app that actually offers similar features—e.g. comparing Discord to an IRC client would not be particularly informative (but that kind of mismatched comparison seems to be a common source of misconceptions here)
There's a virtuous cycle when apps use a platform's native components: apps get the standard UI behaviors for free, users can bring their knowledge from one app to another, and the platform owner can enhance the UI frameworks, improving all the apps on the platform. At least that's the hope.
I can see a future dominated by Electron apps. But Electron is not converging on a new set of UI behaviors that I can bring from one app to another. In any given Electron app, gestures like arrow keys work differently not only from native apps, but from other Electron apps. So I don't use the arrow keys: one less word in my UI vocabulary.
> ... 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.)
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.
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.
> 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.
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 )
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...
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.
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:
VS Code: UP
Visual Studio: DOWN
Notepad++: DOWN
TextPAD: DOWN
IntelliJ: ALT+DOWN
MS Word: DOWN
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.
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.
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#.
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.