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.
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.
Can’t imagine them each having a desktop app. I would just get lost switching tabs.
(Nice and related is that you can do Super+<n> for window switching in at least Windows and Ubuntu.)
I make SSB apps for my most used websites, for me it's much faster than:
- switch to chrome
- switch to chrome window with pinned tab
- switch to pinned tab
Basically a very thin wrapper over the systems web view.
- 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:
https://github.com/dmarmor/epichrome
Other solutions that I know of don't save passwords, or don't keep password/cookie stores separated between the browser instances.
(I think Chrome can do this by itself on other platforms.)
And yes, Chrome, at least on windows, has an `--app` switch.
FluidApp can't save passwords.
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.
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 :)
Since when is Electron running a web view a native application?
By the way checkout GitLens on VS Code.
(joking but also serious)
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.
Its the main reason I'm excited about Rider.
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 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)
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.
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.
I tried asking them on Twitter and the reply was ‘magic’.
I don't see why it shouldn't be. Just make sure you're reading the right column. In this case I think you want to look at "Commit Size".
I wrote up an explanation for some of the other columns a few years back: https://stackoverflow.com/a/2031886/3712
Here's another article with more recent details: http://blogs.microsoft.co.il/sasha/2016/01/05/windows-proces...
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 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.
https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-...
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.
>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.
>It's the rolling coal of computers.