Out of curiosity, why do you prefer a native app over an electron app?
The glut of new ones I use for work on macOS: VSCode, Slack, Notion and Height all have different keybindings than any other apps, some completely disable command+? which I use to find/learn commands for operations I don’t already know. Some just don’t use the menu bar at all. Layout is awful in them, like slack threads being a sliver of the right side of the window, or notion’s usable area maxing out at 800 pixels, or height’s window being fixed to a minimum of 800. Some don’t respect auto dark/light mode. Notion has completely upended many tried and true patterns from word processing. Links take you to the browser based version instead of deep linking to the app.
Of course there are some things I do like about each app, but for me they aren’t worth the tradeoff for the ramp up time on a new product coupled with the annoyances I encounter when using these new apps. I can get things done just fine in a github repo full of markdown, or apple notes, or email, or Xcode, or textedit or sublime text, and on and on. Not to forget the venerable command line. I think the one web app I legitimately enjoy using is trello.
I know that there are some Electron apps that behave well and perform well (responsiveness and RAM usage), but those are in the minority. One could always run a bloated Electron app as the only foreground app on the system and give it more resources, but the usability compromises are hard to get over if you’re someone who likes learning and using keyboard shortcuts and other OS specific interactions.
Vscode is pretty snappy and relatively light to the point it's not prohibitively expensive to run it, for example.
Native apps feel like they react an order of magnitude faster.
It's ok, but "snappy" really is the last description I would think of when using Vscode.
It's slow compared to Sublime Text 3, which is probably the closest alternative. And compared to vim, VSCode is positively glacial.
Theoretically that doesn't have to be trade off. Theoretically it's possible to build an editor like vscode with a native interface. In the actual world it doesn't exist for whatever reason, so I'm going to keep using vscode.
Your claim that "in the actual world it doesn't exist" is just not true. Thousands of lifetime vim/emacs users are scratching their heads.
I no longer consider vscode to be an electron app. You would need a ton of expertise and lots of c++ to have your electron apps perform anywhere close to vscode (and you would still be slower than native)
VSCode is handling a lot of the heavier stuff in C++, but it's still an Electron app, with the sluggishness that comes with it. Compared to things like nvim or sublime text 3, VSCode performance ranges from "meh" to "ugh".
It's true that VSCode is somewhat usable (unlike Atom). However, it is not impressive, despite so much effort being put into its performance (including a vast amount of core code being written in C++).
For this reason, I take VSCode as the perfect counter-argument to Electron: It shows you that the absolute best case is somewhere between poor and mediocre responsiveness with pretty high resource consumption for the task.
(Anyone who finds VSCode to be snappy is either too used to the sluggishness of web, unfamiliar with how a responsive application feels, or has just thrown so much hardware at the problem that it ends up being decent.)
Sublime is also pretty featureless compared to VSCode as well.
Which toolkits are you referring to, and do you truly just mean the renderer, or the entire engine?
Chromiums renderer is pretty fast. Not as fast as direct rendering like Sublime Text does, but for very complex scenes, it will beat Gtk and Qt.
However, it's expensive to build scenegraphs for it (needed on every change), and partial updates are far more expensive than they need to be.
The end result is that, for something like an editor, Gtk and Qt will beat Chromium for responsiveness by a large margin, despite having much less performant renderers for the time being.
(You can get around some of these costs by using WebGL of course, but if you're doing manual rendering you have already thrown most of the reason for Electron out of the window, so why not do it natively where it will be even faster?)
> The memory consumption doesn't bother me either or come anywhere close to bottlenecking me, because I'm a professional using professional hardware.
This is an awful argument. That I have beefy workstation machines doesn't really matter when I'm usually mobile on a low-power laptop.
The difference between using VSCode and sublime/vim is several hours of battery life, and the difference between a comfortable lap and a warm lap.
This idiocy of "it's fine, there's enough resources" is why my colleagues expensive MacBook Pro's are hyperventilating 24/7, and it's a problem for poorer individuals that might not afford a powerful machine.
> Sublime is also pretty featureless compared to VSCode as well.
Matter of taste.
Sublime Text still has a very long list of plugins, and certainly does everything I will ever need an editor to do. I see no reason to pay the penalty of Electron to get support for NyanCat cursor plugins.
VSCode is also pretty featureless if you compare it to vim, and if we pull Emacs into the discussion, VSCode ends up looking more like nano/Notepad.
So all I'll say is that I get a lot of value out of VS Code as a tool, and I don't think it's slow. I think every point you bring up comes from a lack of experience and knowledge of the tool/platform, and it's not worth arguing about online.
VSCode was a breath of fresh air compared to Atom and the extension support was even more impressive. But very recently when I found out about the Sublime LSP package, I decided to give Sublime another look. The snappiness difference between ST3 and VSCode is night and day. Even though by no means does VSCode feels "slow" for my day-to-day work, the small speed improvements of using ST3 compounds to make for a greater experience overall to me.
I used VS Code for about a year, and occasionally revisit to reevaluate. Hell, I even gave Atom a (rather unwarranted) fair shot.
What I am evaluating is just performance and resource consumption, which is much worse than it needs to be due to the design choice of using Electron, which has little to nothing to do with the functionality it provides.
For me, the performance makes it uncomfortable to use. Others less fortunate will be experiencing something much worse than I am.
FWIW, I use VSCode...
I have tried to adopt vs code multiple times and just end up going back to (n)vim, where opening a file is instantaneous and I never have latency when typing, etc.
However I do find Jetbrains' products like CLion/Goland are pretty nice.
it's objectively worse.
https://pavelfatin.com/images/typing/editor-latency-windows-...
https://pavelfatin.com/typing-with-pleasure/
atom (electron based editor) has the highest latency of all. VSCode isn't listed but here's a benchmark by a random github user: https://camo.githubusercontent.com/7a5b91ed14a0173f861b8478c...
it's definitely not. Just adding a `/*` at the top of a file takes a noticeable delay to update the whole text, while it's completely unnoticeable in e.g. QtCreator.
I just took this video on my screen, notice how everything lags in VS Code (left) in contrast with QtC (right) :
Just look at the scrolling : super smooth on QtC, all janky on VSCode (I let my scrollwheel in free wheel mode in both cases) :
What's worse, VS Code uses GPU for its rendering while QtCreator uses a software rasterizer, which should in theory perform less well (in practice, GPU font rendering is definitely not there yet). Both use the same backend for C++ syntax parsing (clang) so the problem is not there.
Conversely, Qt Creator is rather anemic and featureless when compared with vscode. I mean, it doesn't even support very basic features such as editing yaml or json files, it barely supports any form of refactoring at all, doesn't support any form of project other than the old hardcoded C++ support piggybacking clang, etc.
Heck, supposedly Qt Creator's main build system is cmake, and it doesn't even allow you to add files to a project without having to hand-tweak CMakeLists.txt files.
Perhaps if Qt Creator offered a fraction of the features already provided by a free text editor such as vscode then we could start to compare sub-milisecond differences in paint times. Until then, unnoticeable differences in performance coupled with far more functionalities make it a non-starter.
> and it doesn't even allow you to add files to a project without having to hand-tweak CMakeLists.txt files.
I don't know any IDE which does this well and don't think that this is a solveable problem at all. e.g. where would a source file be added there ?
set(COMMON_SOURCES a.cpp b.cpp ${SOME_OTHER_SOURCES})
if(SOMETHING)
add_executable(foo WIN32 main1.cpp ${COMMON_SOURCES})
else()
add_executable(foo main2.cpp xyz.cpp ${COMMON_SOURCES})
endif()
if(FOOBAR)
target_sources(foo PUBLIC foobar.cpp PRIVATE baz.cpp)
endif()
> , it barely supports any form of refactoring at all,
c'mon, here's my experience with Qt Creator when comparing with VS Code (with the C++ extension installed):
- vscode: https://vimeo.com/410950170
- qtc: https://vimeo.com/410950345
I'll agree that QtC (https://doc.qt.io/qtcreator/creator-editor-refactoring.html) has less than for instance CLion in the refactor department, but than VSC? Maybe with ten additional extensions or so ? But qtc works from the get-go without needing to go fetch plug-ins elsewhere.
Note also how QtC helpfully tells me bugs and issues in my code along me typing, without making typing slower.
In contrast, I really have trouble concentrating with VSC (and also JetBrains IDEs & VC++) operating latency (and that's on a 8c/16t top-end desktop i7).
That said, there are use cases for VSCode that don't really apply to ST3, etc
Seriously though, VSCode isn’t bad. I use it on my Surface Pro (dual core i5) without any issues. It’s a nice app.
I have this hope that they eventually will trigger VSCode's rewrite into React Native.
Compare these 3 screenshots of the same window (https://imgur.com/a/UNXtweJ) - and that's not a translucent or blurred window, it's just a solid background color. The only change I made between taking those was picking a different desktop image.
When I open Slack, it doesn't match any of the native apps because it doesn't use the native color blending. It's just drawing a different palette of colors.
In this case, I don't know if QT is going to be any better if it is just drawing all of its own controls. There's another native Git client that I use, and it looks amazing and blends right in with the rest of the apps I use everyday.
DOM-based frameworks make this sort of stuff trivially to implement, and some of them evem come with gesture and animation support out-of-the-box. Meanwhile, feel free to take a look at Guitar's source tree to figure out if that is trivial to work with, and at best it looks like an app from 1998.
How easily can you make a staggered fade and slide in animation? Responsively change layout? Apply complex styles?
In case it's not: great UI != any of those
The developer experience is vastly superior in electron and it's reach is massive. There's no denying. But the underlying problems are pretty serious and the people who complain are not just hating for random reasons.
I hope you get how insane it is when your cpu fan starts spinning because of an app that plays music in the background!
So far the pro electron arguments are concerned only about developer experience who generally have beefier specs in their machines.
The lowest common denominator in end user machines are very different and I request you please keep that in mind!
P.S: I'm a web developer and I fully understand how much valuable electron is for me.
Even vscode, which has a gigantic memory footprint due to its plugin system, requires 1GB to run comfortably.
Nowadays you get computers with 4GB of RAM for 60€.
Let's not bother ourselves with irrelevant details.
Regardless of what many people say, RAM usage still matters. If every app takes a giant chunk of RAM just to get started ( which many do ) eventually that's going to bite you.
Yes, we do have a ton more resources to work with than we used to, but I'm afraid far too many developers have just stopped caring about it at all -- and that's a very bad thing.
That's great, so that must mean you'll be happy to hear that right now I have two instances of vscodium open, each one running half a dozen plugins, and their total memory footprint is less than 300MB.
Do you have anything relevant to say regarding how much resources are used? Or are we supposed to keep debating if being able to run 40x instances of a text editor is not enough room to work with, or if whether having only 7.8GB of RAM free to run other programs is too restrictive?
> great UIs with them?
is completely opposite to these:
> staggered fade and slide in animation?
> Responsively change layout?
> Apply complex styles?
Looks pretty much the same as stitching DOM elements to me, and various runtime modifications in HTML-based frameworks remind me of the "put widget into container" code style of Tk. There's even a CSS-based styling support for Qt.
The main difference is that there is easy way to make a visual designer for the QT .ui files, so it's actually even easier to write GUI apps there.
And DOM based frameworks do nothing to ease of use, ease of navigation, or pretty much anything done by end user*. They make it easier on making portable GUI, yes, but that's on developer side, and with significant costs associated to everything, including reputation of the application and developer.
That said, if superfluous animations are a big part of the benefit, you can count me out in any case.
I don't know about other users, but I like good software with functional UIs that are easy to automate and extend. In my experience, that's definitely _not_ Electron-based UIs. It's also not most GUIs either for that matter.
I absolutely do _not_ want "gesture" and "animation" support. Gestures are a hack for a shitty touch-screen input with zero tactile feedback. Animation is just a power hog for, like you said, a pretty interface. I don't want a pretty interface if it costs performance, costs battery, costs usability.
As a Norwegian <div> makes perfect sense, as "div" is a common shorthand for "diverse" meaning "various" or "miscellaneous". At least that's what I always think of when writing <div>.
I use and occasionally contribute to a distro that's very strict about all dependencies of an application also being packaged in the distro. That's just infeasible for most JavaScript apps these days; most that I've seen have on the order of 500-1000 dependencies.