This article implies the differences matter. Nope, sorry, the conveniences of VSCode are worth the "cost" for me. I have 32 gigs of RAM and the time I spend opening files doesn't register compared to the time I spend writing or reading code.
I do wonder whether the measurements take the base overhead of each editor into account. Do the numbers represent the use per file or the total for the file plus the entire app?
>This article implies the differences matter[...]I have 32 gigs
I'm glad it works for you but not everyone is willing or has the budget to max out their system's memory in order to run text editors and chat applications. You can run multiple CADs and simulators side by side with half the amount of ram. The difference matters if ram is a precious commodity and for many people, especially on laptops, it is.
I understand the need for a hassle-free multi-platform experience, but there should be a better way to accomplish it than this wasteful approach.
I mean, sublime does it really well without the backing of behemoths like Microsoft.
I'm on a laptop. I'm half joking about the 32 gigs thing -- I do have 32 gigs but even with all the messengers (including multiple copies of Slack), a development server with a 4 gig database, a browser and two instances of
VSCode open I barely scratch 11 gigs in use.
I'm a web developer. 90% of my work happens either in an editor, a browser or the shell. So yeah, VSCode's memory use doesn't really matter.
If you think Sublime comes anywhere close to VSCode in terms of features you haven't really given it a try. The code intelligence alone was worth the switch and perf-wise I see no practical difference in day to day use.
> If you think Sublime comes anywhere close to VSCode in terms of features you haven't really given it a try.
Granted, but features have nothing to do with the issue here (wasting resources). Microsoft could have easily offered the same feature set with a different implementation. I have visual studio at work with 7 projects loaded and it sits at a comfortable 400 MB
If your laptop is your work system, it makes sense to have something powerful that costs a few grand. But then personally I'd pay a few extra and get a full featured IDE, why bother with text editors?
For me, VS Code doesn't hog memory anywhere near like Atom does in the linked article.
Electron apps are often slow, memory hogs, but VS Code is neither of those things - it's an example of a great Electron app that absolutely flies, despite being stuffed with features.
I am with you.. These almost daily redundant discussions about the resource usage of Electron Apps are truly a waste of keystrokes.
The people behind Atom and VSCode are putting this out for free.. How about we each use whatever we want and stop complaining about having too much choice.
When using an IDE, memory consumption can be tolerated. Indexers, analyzers, open files, sometimes other tools which run with the IDE.
However, to spend 800Mb to change a single file is too much. Atom is not a complete IDE as VSCode or Eclipse by any means. Yes Atom has IDE packages and capabilities are started to be rolled in, but it's too young.
God knows what will be the memory usage of Atom when it grows to a complete IDE with project-wide knowledge.
Also, having enough resources is never a good excuse for an application to use massive amounts of memory.
Slightly modified for a more probable representation of the future:
[...]
"Why the hell do you need so much RAM, what's the point?"
"It's a Chrome box running web-native apps."
"Oh..."
WASM is defining our future. It might not be chrome boxes, it could be Safari boxes, or Edge boxes, or Brave boxes, or... Why use MacOS/Windows/Linux when everything is available to a sufficiently powerful JS interpreter with built-in sandboxing?
As I said elsewhere, I could make do with 16 gigs but I sometimes need to run things like development databases or Windows VMs (plural) on this too and I like the breathing room.
I already said it's a trade-off. Even with multiple instances side by side, VSCode barely registers. A gig of RAM may matter to you but I'm going to guess your needs are very different from mine and VSCode helps me do my job better than the alternatives I've tried.
Also, as you might be unaware of that: you're being a bit of an ass.
I have 16GB of RAM. Although I normally don't use more than 2GB. But as you said, it's sometimes very useful. Especially in the case of running multiple VMs. I too like the breathing room.
> Also, as you might be unaware of that: you're being a bit of an ass.
If you are offended that your favorite text editor uses as much RAM as an entire web browser, then shooting the messenger isn't going to help.
I was a die-hard ST3 user. I looked at Atom and it was slow and sluggish at the time. I gave VSCode a try after it added support for restoring unsaved changes (i.e. being able to edit a file, close and reopen VSCode and not losing your unsaved changes).
The biggest advantage of VSCode over ST3 is its code intelligence. It's the kind of quality you'd expect from an IDE like WebStorm/IntelliJ but without the entire weight these IDEs usually bring to the table. VSCode still feels genuinely "fast enough". And if you work with JavaScript, the code intelligence even becomes better if you have dependencies that have community-provided TypeScript typings -- you don't even need to use TS to benefit from the built-in TS support.
Other than that, the extension ecosystem is very strong. I missed a few ST features initially (mostly specific keyboard shortcuts) but there are extensions that provide all of that (including an ST keymap) and more. It's also fairly easy to write an extension yourself if you know a little JS.
For me, the most awesome part is the debugging experience out of the box. If you're programming for NodeJs (or other supported languages, with a bit of configuration), you can click on the side to add a breakpoint and hit F5 to run, step over your code and hover variable names to see what they hold, evaluate expressions to change things and stuff like that.
Still in the JS world, VS Code uses the TypeScript engine to infer variable types and detect type errors, which by itself catches a lot of bugs.
These features aren't unique to the JS language though. Extentions do have access to the APIs that implement these features, so you already have them available for most languages (with different levels of quality/completeness).
I do wonder whether the measurements take the base overhead of each editor into account. Do the numbers represent the use per file or the total for the file plus the entire app?