But it cannot just use native controls all the time as it generally supports more features than what is available on a given platform, so there has to be a kind of emulation.
Also, I would vastly prefer electron apps instead of using a native toolkit that's not following the interface guideline of the OS that looks to be using free icon set from the 90s instead of using Font Awesome or similar.
This is the most annoying thing with developers: many of them believe that a normal laptop from around 2010 is "underpowered" and everybody's using the latest macbook pro or some high-end device. But the majority of people use average computers with 4-8GB RAM and some random CPU. Most machines don't run on high-quality fast SSDs.
Also, the app is perfectly following the user guidelines of usable OSes: pre Win8 Windows and pre Gnome3 Linux. Those icons from the "90s" make sense and communicate their functionality well, because they adhere to some convention and are not pure fluff like FontAwesome et al. are. The sheer ignorance of dev community wrt. usability both in design and in performance is sad. Desktop is where people get work done and the bastardized mobile interfaces Win8, Gnome 3, and Electron brought there are nothing but an obstacle. Macs seem to not have gone to that direction yet, but slowly "advancing".
It's telling that none of the widely used IDEs---Even Android Studio or XCode---don't adhere to these bullshit "interface guidelines".
My blood pressure decreased by a huge amount the day I replaced discord & slack by ripcord... and it's also much better in term of UX when you are on a ton of different instances.
e.g. the difference in responsivity is huge : https://streamable.com/ori2yg
and ripcord does so in 87 megabytes of RAM with while slack does it in 758 : https://i.imgur.com/xivK3gr.png
and that's not counting that I would also need discord next to it. I had to buy 64gb on that machine because of all this fuckery - add a few additional work workspaces and a 16gb machine which is already more than what the general public have and it's unuseable. Just checked in the website of the biggest french retailer, and 7 out of the 10 most currently sold laptops have 8 gigs of ram for instance.
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.
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.
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.
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.
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).
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...
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.
FWIW, I use VSCode...
That said, there are use cases for VSCode that don't really apply to ST3, etc
I have this hope that they eventually will trigger VSCode's rewrite into React Native.
Seriously though, VSCode isn’t bad. I use it on my Surface Pro (dual core i5) without any issues. It’s a nice app.
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)
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.
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.
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.
How easily can you make a staggered fade and slide in animation? Responsively change layout? Apply complex styles?
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?
In case it's not: great UI != any of those
> great UIs with them?
is completely opposite to these:
> staggered fade and slide in animation?
> Responsively change layout?
> Apply complex styles?
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.
That said, if superfluous animations are a big part of the benefit, you can count me out in any case.
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.