Outside of using VSCode for JS and Typescript, I use it as a catch-all. If I don't have a better preference, then VSCode usually handles it well enough.
I moved from WebStorm to VS Code and haven't looked back. Code is generally faster than any IDE I've used (at least for JS work). My understanding is the Go support is very good. No idea on Python. There should be extensions for both that should be easy to install.
Code has become hands down my favorite editor. I don't use the debug often, but it's passable. Just depends on your needs and use. I'd suggest giving it a try for a couple weeks (just to get past any initial pain points).
I use IntelliJ on all languages I use on Mac but VSCode's font rendering is more natural and better. There's something weird about Java's rendering implementation for not being crisp.
I have been using VSCode with the Golang extension for around 2 years now and have been exceptionally satisfied with it.
I did use the JetBrains Goland for around 3 months since I heard some praise from my co-workers but found that it'd didn't contribute much.
The debugging works as well in VSCode as it does in Goland but yes, delve (the debugger backend) crashes sometimes when debugging goroutine heavy code.
Completions, refactorings, renames, linting and goimports all work flawlessly.
Would seriously recommend VSCode + Golang.
For JavaScript and family VSCode is the best from what the Frontend team in my organisation tells me.
Are there specific features of Atom that aren't in Code? It seems that Code could likely add some of the features missing that are in Atom easier than trying to merge them, or go the other direction.
I'm using Sublime Text 3 but these two text editors have many more extensions/packages than ST3 and while I don't want to move to a slower text editor, the packages seem to good too pass up.
The thing that sucks, in my experience, is that the "fastness" of a text editor doesn't translate into productivity the way the abundance of plugins and support and popularity will. But the slower ones just manifestly feel so irritating once you're used to the speed.
On specifically startup time for large files (narrow use case, but thats what we got), there's this comment from user jakear from a while back on an Atom 1.28 thread [1]:
1.1GB file, 10M lines.
Code: ~10s, smooth scrolling, instant jumping.
Sublime: ~50s, smooth scrolling, instant jumping.
Atom: ~10s, smooth scrolling, very choppy jumping: ~5s loads per jump (also got some error messages about text too large for buffer)
Sublime: Application not responding after ~60s, waitied another 60s, no change. Same behavior each of the two times I attempted.
Atom: ~8s, smooth scroll, ~30s per jump, occasional "Editor is taking too long to load" messages.
Note: Atom enforces a maximum line length of ~500 chars before it wraps regardless of word wrap setting. This means the 8s load was only showing a couple lines worth of content. I find this restriction not acceptible for the long-line test case, but including anyways for completeness)
Full "report": https://pastebin.com/wUv8PSgp
At home, I'm on an i7-4790K, my work laptop is an i7-8650U, so ymmv.
I've never found Code to be particularly slow, and will generally load in a couple seconds. I tend to have it open most of the day on the project(s) I'm actively working on. The benefits of the integrated terminal alone probably saves me more time than I ever spend waiting for it to load. It's always been very responsive in the application, and worst case scenario I've had is on occassion the syntax highlighting or context auto-complete may have a delay. But that doesn't stop me from being able to continue typing by hand and is generally as good or better than Sublime.
The extensions are all around REALLY nice to have. Being able to add support for more languages via extension has been great, what little I've used of that. And the integrated debugger has been very usable when I've used it. Git integration and Diffing could use a bit more work, but that's true of even dedicated Git applications.
I've really been beyond appreciative of the iterative improvements as well. Every release I notice something that I like in the release notes. I will say I did like the old open-docs layout more than the Tabs once I had gotten used to it. It still works okay, but I didn't appreciate that one regression in behavior. But most were more used to tabs, and I understand the resistance.
I used to love VSCode, but over the past few months it has become unusably slow.
I'm talking freezes for multiple seconds while typing kind of slow. This is with less than 5 plugins. Vim has become my default editor now, and I only use VSCode if I want to move a lot of files around.
This isn't just something where you should go "oh, well, guess I'll switch". Please report such issues, and try to debug what is going on because it sounds like it might be a problem with your computer in general.
I don't work for Microsoft, I'm not locked in, and I'm just trying to get my own work done. I am equally productive with Vim, and it doesn't lag, so I switch over.
The very first thing you wrote was, "I used to love VSCode". That you used the phrase 'love' and it was your opening thought implies you were at least somewhat invested in VS Code and might attempt to find solutions before dropping it completely.
Not that it matters to anyone else what tools you use, just that is the impression from your initial post (to me at least).
I badly want an intimate look under the sheets at how the vscode team does their development cycle. These updates are consistent and generally very high quality, and focused on a handful of features. I want to replicate it for my team. But I don't want buzzwords like "agile", I want to cut through all that and see the actual actions, behaviour, and tools that result in this kind of success.
It would be interesting to see a case study of this, as well as how the interaction with the public community, and collaborators has worked. I do know that some pieces do burrow from the larger community, and it's interesting even what you can glean from GitHub alone.
They seem to coincide closely with the release cycles of Visual Studio proper. I wonder if both teams (or the same team) are within similar disciplines.
I work at Microsoft. Generally, here, we have a relaxed philosophy towards approaching things. No pressure cooker environment. Don't feel like going to work? Stay at home. Because it's not shoved down your throat, you develop a particular affection towards your work, and when it gets to crunch time you put your head down and work because you actually want to. I can't speak for every team, but that's the general state of affairs.
I very much enjoy vscode for local edits. Alas! Majority of my time is spent on remote machines. I’m yet to find a solutions better than ssh + vim. I desperately want to be able to use vscode on remote boxes (eg using whatever python interpreter and pytorch happens to be installed there)
Irony is that jupyter notebooks are a decent middle ground for my workflow since the editor is actually running on the server (although I’m not super in love with it since I have to refactor etc and missing out on what IDEs have to offer).
Vscode remote extension has been a joke unless I’m missing something big ... akin to Rsyncing files, making edits locally, and pushing it back out.
Nuclide (atom) seemed like it does what I want but I never got it to work in my vpc.
41 comments
[ 0.83 ms ] story [ 1821 ms ] threadAs someone who does python, Go and js with jetbrains IDEs, would VSCode be better?
There's also keymap extensions to emulate keybinds from other IDEs. You should try it at least.
Code has become hands down my favorite editor. I don't use the debug often, but it's passable. Just depends on your needs and use. I'd suggest giving it a try for a couple weeks (just to get past any initial pain points).
I tried to use the git UI that it provides, but in the end preferred to manage my vcs from the terminal.
I'm reasonably happy with it - and I didn't think this was going to be the case when I first tried it out.
And VSCode doesn't take 30s to launch.
I did use the JetBrains Goland for around 3 months since I heard some praise from my co-workers but found that it'd didn't contribute much.
The debugging works as well in VSCode as it does in Goland but yes, delve (the debugger backend) crashes sometimes when debugging goroutine heavy code.
Completions, refactorings, renames, linting and goimports all work flawlessly.
Would seriously recommend VSCode + Golang.
For JavaScript and family VSCode is the best from what the Frontend team in my organisation tells me.
I'm using Sublime Text 3 but these two text editors have many more extensions/packages than ST3 and while I don't want to move to a slower text editor, the packages seem to good too pass up.
1.1GB file, 10M lines.
Code: ~10s, smooth scrolling, instant jumping.
Sublime: ~50s, smooth scrolling, instant jumping.
Atom: ~10s, smooth scrolling, very choppy jumping: ~5s loads per jump (also got some error messages about text too large for buffer)
1.0GB file, 40k lines.
Code: ~15s, scrolling somewhat choppy, quick jumping
Sublime: Application not responding after ~60s, waitied another 60s, no change. Same behavior each of the two times I attempted.
Atom: ~8s, smooth scroll, ~30s per jump, occasional "Editor is taking too long to load" messages.
Note: Atom enforces a maximum line length of ~500 chars before it wraps regardless of word wrap setting. This means the 8s load was only showing a couple lines worth of content. I find this restriction not acceptible for the long-line test case, but including anyways for completeness) Full "report": https://pastebin.com/wUv8PSgp
[1]: https://news.ycombinator.com/item?id=17369898
I've never found Code to be particularly slow, and will generally load in a couple seconds. I tend to have it open most of the day on the project(s) I'm actively working on. The benefits of the integrated terminal alone probably saves me more time than I ever spend waiting for it to load. It's always been very responsive in the application, and worst case scenario I've had is on occassion the syntax highlighting or context auto-complete may have a delay. But that doesn't stop me from being able to continue typing by hand and is generally as good or better than Sublime.
The extensions are all around REALLY nice to have. Being able to add support for more languages via extension has been great, what little I've used of that. And the integrated debugger has been very usable when I've used it. Git integration and Diffing could use a bit more work, but that's true of even dedicated Git applications.
I've really been beyond appreciative of the iterative improvements as well. Every release I notice something that I like in the release notes. I will say I did like the old open-docs layout more than the Tabs once I had gotten used to it. It still works okay, but I didn't appreciate that one regression in behavior. But most were more used to tabs, and I understand the resistance.
I'm talking freezes for multiple seconds while typing kind of slow. This is with less than 5 plugins. Vim has become my default editor now, and I only use VSCode if I want to move a lot of files around.
I don't work for Microsoft, I'm not locked in, and I'm just trying to get my own work done. I am equally productive with Vim, and it doesn't lag, so I switch over.
Not that it matters to anyone else what tools you use, just that is the impression from your initial post (to me at least).
(and perhaps a "keyboard only" guide to vscode)
(and perhaps since it's running javascript anyway a quick way to find and change running extensions, something like emacs has)
Irony is that jupyter notebooks are a decent middle ground for my workflow since the editor is actually running on the server (although I’m not super in love with it since I have to refactor etc and missing out on what IDEs have to offer).
Vscode remote extension has been a joke unless I’m missing something big ... akin to Rsyncing files, making edits locally, and pushing it back out.
Nuclide (atom) seemed like it does what I want but I never got it to work in my vpc.