As much as I wanted to like and use VS Code, Electron base still ruined it for me. If it was some other app where I do not expect instant snappiness and lower memory usage, for example, Slack (also Electron app), I would swallow it, but for an editor, I can`t.
I upvoted you to try to offset the misguided downvotes. That is indeed the worst thing about VS Code.
I have my computer configured so that most file types open in Sublime Text for that reason. For projects with a lot of TypeScript I'll open a project folder in VSCode, and then just leave it open indefinitely. Because that part is annoyingly slow, as you say.
I find it less annoying than Slack, though — seems to me that once VSCode is open and focused on what you want, it is a lot faster than Slack at all the basic operations (switching files/channels, searching, etc). Slack feels more like most other Electron apps I have tried — slow enough at just about every little thing to be constantly annoying.
Don't it get lost or closed by mistake all the time?
To me much of the value of a separate app is being able to cmd+tab between application and I frequently just close my browser be get remove all windows and tabs.
I like the compartmentalisation of separate apps, but I doesn't really care if it's written as an Electron app, as long as reacts fast enough.
Next lesson: you can switch to the n'th tab using Alt+<n> (or perhaps a different modifier key depending on browser and OS). Since pinned tabs appear on the left-hand side, that means you'll always have e.g. Alt+1 for email, Alt+2 for calendar, etc.
(Nice and related is that you can do Super+<n> for window switching in at least Windows and Ubuntu.)
Me, too. For instance, I use a site-specific browser for:
- CircleCI
- GitHub
- JIRA (blecch, but I have to use it...)
- AWS
- Google Docs (for work, and the rare personal use of Google stuff can just happen in one of the general browsers I am using)
...and others.
The OS does a much better job of partitioning windows and groups of windows than a browser typically does. You can easily keep switch between groups of windows, or keep them in their own workspace/desktop, etc.
Plus you can keep your cookies and saved passwords isolated between the environments... the browser handling AWS doesn't need to store or have access to the pasword for my Google account, and so on. For production type apps you can disable saved passwords entirely.
It is incredibly useful, and the only thing I worry about is that on macOS (my main workstation OS) there is only one good solution for this I know of: Epichrome, which seems to be a one-man side project:
MacPin looks interesting! Thanks, will check it out. However, Safari-based browsers have a horrible show-stopping flaw; they don't (yet) support pasting images into web applications. This is why I love Safari for browsing and reading, but can't bear to use it for JIRA, GitHub, etc.
In Chrome (and thus Epichrome), you just hit your screen capture shortcut (Cmd-Shift-Ctrl-4 by default on macOS), select a rect of the screen to copy, and paste. Boom! Your bug report or GitHub comment now has an image pasted into it.
In Safari, you have to hit your screen capture shortcut, open Preview or similar app, create a new image, save it as a file, then go back to the web app and upload the image.
There's something deeply, horrifically wrong with that workflow.
Uh, I believe Cmd-Shift-4 saves the image directly to the desktop, then I usually hit one of my hot corners that shows the desktop, grab it, hit the corner again and drop in the image. It's usually pretty quick. I did not know about holding Ctrl copies the file, I'll probably use that more often now because it probably is a little faster. But if you want to save an image you don't have to open up preview to save it or anything.
For me it's just saving me from minor inconveniences. Things like having an app I can easily switch to instead of flicking through many browser windows/tabs to dig it out.
I try to offload as much stuff from the web and into the desktop because it means I can do all my window management with cmd+tab and Spectacle. If something lives in the browser I have a second layer to manage with ctrl+tab, slowing me and increasing mental load.
My full setup is cmd+tab for application switching, Spectacle for window ordering, and ctrl+arrows for switching Spaces. Space 1 is my 'grab-bag' desktop, Space 2 is my browser windows, Space 3 is all my code editing stuff, Space 4 is messaging (Telegram/IRC/Slack) Space 5 is Spotify and Space 6 is Mail and Calendar. All applications are 'pinned' to only open in their respective Space, but can be dragged to another one manually. I like to think of it as a best-of-both worlds hybrid between stacking window management and tiling window management :)
We have a solution with around 30 projects in it - this solution consumes around 1.25gb of RAM in Visual Studio. In contrast, the same solution in VS Code open along with two other windows open to other solutions are using a total less than around 300mb.
Yet I have 32 GB of RAM on my machine, and rather than use any of that, VS2017 will just use < 2GB, and swap constantly on large solutions. The 32-bit restriction is getting ridiculous.
I use VSCode to work on medium-sized VueJS+TypeScript projects (maybe a grand total of 200 code files), and it regularly consumes around 800mb - VS territory. Perhaps it's very sensitive to how it's configured/what plugins are installed.
I assume you use ReSharper? I have a 1M+ LOC C++ application that I work on regularly and have never had a performance issue. There was definitely slow down when I moved from VC6 to VS2005, but man, that was so long ago.
It works just fine for me. It's just as usable as any other editor. It slightly less snappy that vim in a terminal, but it doesn't make much of a difference most of the time. I still use vim occasionally though in some contexts (single file editing, constraint environment...).
I think there are a lot of people who open and close their editors pretty regularly, I can imagine that the start-up time for VSCode can become quite significant to those people.
I don’t think Electron is entirely to blame e.g. I tried the Discord app and it was amazingly snappy (just install both Slack and Discord and you can feel the difference).
Just compare VSCode with Atom - both Electron apps, both text editors, both extensible in JS.
I can't realistically measure input lag and stuff, but for example... With both having lots of extensions doing approximately the same, startup time is order of magnitude different. (And once upon a time I thought Emacs was bad in this regard, huh)
I actually really want to know how Discord does it. Do they actually use the DOM, or just draw everything themselves?
Honestly, anyone who hasn't used Discord, I'd recommend installing it just to try it, especially if you're a SPA web developer or you work with Electron. The performance beats native apps, even dealing with very long sections of text that need to be swapped in and out as you scroll.
However they're doing it is probably the way we should be building Electron applications industry-wide.
> Do they actually use the DOM, or just draw everything themselves?
The DOM is fast — what's slow are toolkits or poorly structured code which issues many redundant or poorly timed updates which forces the browser engine to do unnecessary updates.
How much memory does it use? My emacs instance uses ~200M with a moderate amount of files(along with other processes mostly repls). I would imagine VSCode to be in the same ballpark, and 200M is not that of a big deal imo.
But an even better test is when using these editors on large projects with hundreds or thousands of files. Atom is a disaster. I tried to like VSCode and except Electron part and baggage it is great.
For this reason, I am switching to vim for everything except Java/Kotlin. There is nothing even remotely close to IntelliJ for Java or Kotlin and you can use very nice vim bindings in IntelliJ. I also keep Sublime installed for quick file edits when browsing the filesystem with GUI apps.
Task manager shows working set by default. Working set is affected by things like minimizing the application, it'll also usually shrink if the application has been left idle for some time and other applications are being used. Whether it's the right column or not depends; it's more of an indication of how much the OS feels that it needs to hand over to the process, than how memory-hungry the process is. Private bytes might be a better number for that; OTOH if many of the bytes aren't touched, then they don't count for much.
Commit size isn't the most important number either. You can commit large chunks of memory and if you don't touch it, Windows won't allocate it; not in physical memory nor in page file.
> Commit size isn't the most important number either. You can commit large chunks of memory and if you don't touch it, Windows won't allocate it; not in physical memory nor in page file.
No.
Short response: Try committing 1 TiB of memory without touching it and tell me how successful you are.
Long response: Unlike Linux, Windows doesn't overcommit. It is completely irrelevant whether physical pages have been actually allocated to back the the virtual pages that are committed. The fact that the virtual pages are committed means that there are guaranteed to be physical pages available somewhere when the need arises for them to be allocated (whether they are in the page file or in physical memory is irrelevant; what matters is that the storage space exists one-to-one), i.e. the fact that some virtual pages are committed means you have lost that much physical memory from the system already... which is exactly the number you want to look at when you're trying to figure out how much memory a program is using (since the entire point is to see how much memory it'll leave you for other programs).
(And shared memory is pretty much irrelevant for VSCode so let's not go on an irrelevant tangent.)
> It is completely irrelevant whether physical pages have been actually allocated to back the the virtual pages that are committed
It is in fact the only relevant thing with memory; physical memory is the constrained resource. If you're constrained on swap space, you're going to spend the rest of the year swapping.
Overcommitting is neither here nor there; a failure to have a backing store for memory (whether in physical memory or page file) will result in OOM, but nobody is actually worried about OOM. Editors and systems lose responsiveness long before then. The failure mode from apps using too much memory is swapping, not OOM.
Part of the reason measuring memory usage from a process stats perspective is so hard is because some memory is more important than others; in particular, access patterns matter. If a process is starting to swap, whether you see a cliff edge in performance, or a more gradual decline, comes down to the access pattern. The working set concept approximates the "frequently used" quantity of memory, which is why Task Manager uses it by default, but it's subtle since it's not a simple function of allocation.
I'm a little bit philosophically opposed to Electron based apps but VSCode has been nothing but snappy for me on all matter of low-end machines and virtual machines I've used it on.
>If there were no other way to code a text editor I could accept the idea of Atom. But with faster alternatives, it is just an exercise in consumerism. Wasting computing power for the sake of wasting computing power.
More tolerable in a scence that I could live with 1-3s occasional actions in it (switching organisations for example). Not saying that it is good. But I will tolerate that more than the editor hanging on large files or taking to long to process actions which should be instantanious.
