Chanced upon this opinion:
iProgrammer: Atom v Visual Studio Code - The Unexpected Consequence Of Consolidation.
Chanced upon this opinion:
I think his take on Visual Studio vs Visual Studio Code is completely incorrect. I don’t see MS turning VS Code into an IDE, I think they very, very much want it to stay an lean and fast editor. The landscape pre-Atom acquisition seems to be that MS has two IDE products (VS for Windows and VS for Mac), and one editor (VS Code), and as far as I can tell it makes perfect sense to invest in both.
I agree with you concerning the distinction between a code editor and an IDE. But the point was the relationship between Atom and VS code in light of the acquisition of github by MS.
Yeah, the whole Atom vs VS Code situation is interesting, completely agree.
AFAICT the only really significant difference between VSCode and Atom is the API design (and the package ecosystem), so if there is some kind of convergence of APIs then who really cares if Atom and VSCode don’t stay separate?
Do you know why is Atom so painfully slow to use compared to VS Code, and whether it is fixable? I had read that previously they had an inefficient buffer system, but I think that they reimplemented that and merged in the changes. Still slow…
Have you tried it with all your plugins off? There are some Atom plugins that really drag things down.
Yes. Turned off every plugin, on a new 12K workstation, and was a little better but still very slow. But the bigger issue is that vscode is fast, even with plugins, which is necessary with an editor of that sort.
Somebody had mentioned Atom/Xray, and I read all about the project, which seems great. I do hope that M$ can pour money and talent into that project.
Huh, I knew they had rewritten a lot of components of Atom in lower level languages, but now they seem to be doing a major rewrite. I guess the last step will be to drop Electron, and we will have come full circle…
Hm, Atom’s performance is about the same as VSCode’s for me (on every machine I tried), so I have honestly no clue why you’re seeing such big differences there. Can you describe what precisely feels slow? Typing, resizing stuff, navigating files?
Yeah, that’s going to be very exciting. It’s entirely possible that both VSCode and Atom (if they still exist separately then) will build on the stuff pioneered by xray.
It used to be really slow, but it’s a lot faster now, almost–but not quite–as fast as VS Code (on my 5yo computer.)
This summarises my experience too. I used to be on VSCode because Atom was so much slower back then. Then I gave Atom + Juno another go because the debugger really did seem useful, and it turned out that the slowness of Atom seemed to be almost completely gone (I’d say 90-95% speed of VSCode, DQMOT).
I am encouraged to hear that my experience was not universal. I will happily try atom again when v0.7 is practical to use. The last time I tried (a few weeks ago) involves switching to another branch of Revise, which caused dependency chaos on v0.6
The issue of slow extensions is a big one for editors that rely on extensions for everything useful (e.g. the latex extensions were a complete disaster for performance and usability). It sure would be nice to use a single editor for Julia, latex, python, and markdown…
Unfortunately some editing experience is not good enough in Emacs, e.g. VSCode really gets everything about writing frontend languages right while Juno is still the best experience about editing Julia code. Nowadays I mostly just use Emacs for its org-mode. Still central to my workflow, just not for actual code editing. Sure one can do any type of editing in Emacs if they want, and I really want to use one editor for everything, but sadly it’s already not the best experience out there in most cases.
Emacs in windows is slow.
In Emacs you have to polish your own user experience, if you do not do that, there are many more rough edges than in Atom/VSCode.
Emacs shines in other areas:
- Remote REPLs
- Remote file editing
- Use in terminal
- Arbitrary window layouts
- seamless switching between languages, i.e. Emacs users are more likely to use one editor for everything instead of e.g. RStudio for R and Atom for Julia.
- You can move your life to emacs (you can even use it as a window manager, for email, as a pdf reader, web browsing, etc. in case you wish to do so)
I had the same problem on my Linux machine (Centos 7). I downloaded the proprietary graphics drivers and suddenly Atom was fast. Maybe check this?
Yeah, that’s a good point – Atom heavily relies on good GPU support for speed. So does VSCode though, so I’m not sure why that’d be faster.