Couldn't agree more.. People who say Electron (on which VSCode is running) is bloated and is slow probably haven't worked on full fledged IDEs using Java.. they consume memory in Gigabytes, are slower, at least appear to be slower, despite using native UI and takes a lot longer to open.
I switched form VSCode to PHPStorm half a year ago, and while it feels a bit slower, the improvements are so unbelievable worth it for me. It does have a taste for memory, but then again, it easily saves me a lot of time each month, so just throwing RAM at it was a no-brainer for me.
Depends... I'll open/close a few times a day as I touch several projects. I can use VS Code for everything from db/sql, react, node and c# (.net core) projects. I also have used it for a little rust and golang.
As to the RAM, it's using around 1.2gb between vs code and the connecting server (WSL2), multiple isntances vary... but with the number of containers and VMs I'm running, I'm generally well over 16gb of use, and I have 64gb on my desktop. So even without VS Code, I have trouble on a 16gb system.
Yeah, IntelliJ-based IDEs are hungry, but even if mobile, I figure I'd just spend the extra money to get plenty of RAM, it's that good (to me at least).
I usually run 3-5 instances for different projects and it'll hover around 3gb RAM, but it appears that they share a lot of memory, closing one or opening an additional project has no visible impact.
In my case, often several times an hour. I work across 6-10 dofferent repositories. Opening them all at once is impractical, so being able to open each of the them quickly is quite important.
The problem I have with this is it makes "Go to file" functionality a bit too broad. e.g. If I want to open `package.json` I now have to choose between 10 different files. As I often `Cmd-P`, type pa, `Enter` without even looking, this makes it considerably slower.
I also have to do a lot of context switching (e.g. to review someone else's code), and being able to have a separate set of tabs (even within the same repo) is super-useful for this.
At previous jobs with less separated out code, I have taken this approach (although with Sublime Text rather than VSCode).
Agreed... deeply nested directory structures are also pretty painful.
Even in the mono-repos I work with, I'll generally open an editor per inner repo. Mostly ./feature/featurename/filename is as far as I have to open. Some of the C# projects are deeper though.
It does something completely its own (and horrible/slow) on Windows (possibly one of the 6534 equally awful Java UI packages), so I can't imagine it does anything better with iOS.
Eclipse uses SWT, which actually piggybacks on native toolkits, though I don't know if it doesn't go through some ancient version of GTK in the process.
AWT/Swing based IntelliJ manages to be much, much faster in comparison.
That seems odd to me. I basically never close my IDE. Sure, I might put the laptop to sleep in between or disconnect from the remote desktop server, but I rarely need the 500 MB that my IDE consumes, so there's little point in every closing it.
To each their own. It always fascinates me to hear about Java/.NET environments that massive. Do you only work on 1 project for months at a time? Do you not ever need to reboot into another OS? Is your laptop power efficient? Do you have a separate machine just for Gaming?
I mostly program in languages like Ruby & Perl using Vim. Even with my decked out version that has 35 plugins, and some other bells and whistles, I'm on average using 20 MB of RAM. Open/Close is near instantaneous.
And if you need something even lighter, something like a better Notepad is enough. Lightweight text editors are a dime a dozen, but I'm personally a fan of notepad2 / notepad2-mod / notepad3; even if they don't have tabs.
Also shout out to LINQPad, for letting me test quick snippets of C# with better visualization than Visual Studio. It's also a better alternative to Sql Server Management Studio for running SQL.
+1 for VSCode for its configuration portability plugin, settings sync. It’s never been so easy to sync editor changes across my machines, and I’ve only had 1 dependency issue using it in 4 years. No longer having to maintain my vim config and dependencies has been great.
I believe Settings Sync is going to be included in the next release of VS Code. Yay!
The amount of work Microsoft is putting in this editor is amazing. Last month we got file history, that was the last thing I needed to ditch the Git GUI I had installed.
I use vscode but it's missing some basic code features for me. The biggest for me is probably keyboard macros, something that's been a basic feature of editors since at least the 80s. Keyboard macros in other editors has saved me 100s of hours.
As an emacs user, I view multi-cursor as suitable for only a subset of macro usage. Macros are inspectable, editable, savable, able to be applied across files, easily used a variable N times.
My typical pattern is something like: define it, try it, adjust it, then apply variable times (including “infinite until error”), maybe save 1% of them. That often takes less time to do than it just took me to describe.
I use macros probably 25x for every one time I reach for multi-cursors, though to be fair, if I came the other way, I’d probably use multi-cursor more often than currently. (I used macros for 30 years before getting multi-cursors, so if both can do the job, I’ll use a macro.)
> Macros are inspectable, editable, savable, able to be applied across files, easily used a variable N times.
In my experience with multicursor, I don't need to be able to "inspect" the operation as the act of typing it is inspection in and of itself. Sure they aren't saveable and thus aren't editable (but you admit this is a very rare use case - I can't recall needing that, ofc you often don't know when to want what you don't have).
As for applying across a number of files, I recently added an in-editor rendering of workspace search results to VS Code, and I've created an extension that can apply edits to those search results back to the original files. This allows for performing multicursor edits across many files.
As for using variable numbers of times, this is again quite trivial with multicursor. I simply select all the instances I need (either all in one go or iteratively), and go from there. I admit there is an art to selecting the right text such that iterative selection works with a single keypress, but once you get the hang of it it becomes pretty natural. (Unless you mean "apply this N times", which again I'm not sure I've ever been in want of)
The question might boil down to use case. If the use case is “in this file, change all spans with class foo to divs with class bar once ever”, probably both tools will work.
If the use case is “every day, download this file from a server and process it using pre-defined text editing commands”, multi-cursor doesn’t help you in any way that I can see.
I admit there’s a huge overlap in use, but when someone asks for macros and a product person says “how about multi-cursor instead?” I think it’s fair to raise the cases where someone asking for macros might actually want macros.
That's snappy but not informative at all. What do you miss in multicursor that macros give you?
I also prefer vim's macros to multicursors, but I think it ammounts to nothing more than habit and preference.
Macros in Vim are going to be much more powerful, with movement commands and selection commands giving yo a more flexible system... I think? Hard to be objective after so many years of Vim.
> What do you miss in multicursor that macros give you?
Not OP, but to take a recent example (although it was in Emacs, I'm pretty sure it would work in any advanced editor), I had a macro select the second half of the open file and pipe it through sort and uniq to replace it with each unique line and their number of occurences. That's not doable with multi-cursors; their use cases intersect but don't overlap with macros ones.
Honest question: when are loops not replacement for recursion?
My (admittedly naive) mental model of recursion is basically a loop where you bring your entire stack frame with you (or less, in the case of tail recursion).
Yeah, macros might be cool... I've gotten by with mostly using the regex options in string replace, etc... snippets have helped a little, but don't use them much, sometimes they annoy me when they pop in.
Killer features are directory view, integrated terminal, regexp for find/replace...
Lately, I'd add the remote ssh and wsl extensions have been insanely useful, but starting code from inside wsl has gotten sluggish since the last vs code update.
It is not fair to compare VSCode/Sublime Text with an IDE. They are very fast at opening, agreed, but they the features that an IDE provide (intelligent code completion, jump to definition, database-aware autocompletion, ANY sort of refactoring capability) easily save me hundreds and hundreds of hours.
