A free, powerful, open sourced editor and IDE constantly improving and growing - what's not to like? - I get that some don't like the electron-based thing/performance but it never bothered me (and I bought and use both Sublime 2 & 3) - guess it requires a degree of sensitivity that I'm not bothered with - sort of like people who claim they can't hear mp3 because they can only enjoy CD quality audio (not saying it's not true for them, just that luckily I enjoy both the same).
The question I'm wondering about is what is Microsoft's end game with this? I'm comparing this to the history of Google Chrome that, when released, was similar in the sense that it was better than the alternatives: wickedly fast, open sourced, with no apparent strings attached. The business benefits to Google and market control from owning Chrome are obvious today and I'm trying to understand the long term view in VSCode - i.e how to you eventually create business value from a free editor? Premium features? Better integration with Microsoft's services? I wonder if there's a deeper vision - I mean, as opposed to Chrome, VSCode does not know much about me personally, does not provide much data to further leverage Microsoft's services, and targets a much narrower audience to begin with. So, what's the business model behind it's development. I'm too much of a skeptic to believe it's just so developers have a warm fuzzy feeling associated with Microsoft...
> what's the business model behind it's development. I'm too much of a skeptic to believe it's just so developers have a warm fuzzy feeling associated with Microsoft
There are a couple things others touch on, but to expand on a few things:
1. Microsoft was formed for developers in the first place. It's first product was BASIC (for MOS 6502). Developer productivity has always been a part of Microsoft's long term vision of itself. It is entirely possible for VSCode to be developed solely to give developers warm fuzzies and for that to fit Microsoft's long term vision.
2. VSCode gently encourages you to explore other Microsoft tools and services. It's built in Typescript and makes cross-platform .NET a reality and has some useful Azure integration extensions to help you run things on Azure services. Part of the delight to VSCode is that it doesn't hard sell any of those: it offers them as opt-in tools and lets you explore them yourself. (Opinion: This is a wonderful sort of return to confidence from Microsoft that their developer tools nearly sell themselves on their own merits, Microsoft doesn't need to hard sell them.)
3. VSCode is "made out of Azure". Part of why VSCode has seemed so effortless to build was that a lot of the core pieces (particularly the Monaco code editor at the heart of VSCode was built for Azure, then reused by IE/Edge Dev Tools, VSTS, before being brought into its own in VSCode) were built for Azure itself to provide a nice development/devops environment experience in the cloud. That seems a pretty good advertisement for something like Azure when even the systems built to support the services offered are strong development tools of their own merit.
Minor correction, the first BASIC was for the GE-235. The Altair was the first home computer to have a version of BASIC, but BASIC had already been around for a decade before it was ported over.
To extend on that, dotnetcore is dead in the water without a decent and supported cross-platform development experience. Visual Studio and vsmac get the job done for now, but for the long run they need something that also works on linux and is consistent across all three platforms.
One very specific performance metric is startup time, and Sublime beats the pants off VSCode in that department. Creating new top-level windows in VSCode is also annoyingly slow compared to Sublime (presumably because it's spinning up a new browser context). Other than that, it seems snappy enough.
I just started visual studio code on my workstation, and it took 9 seconds to display a window, followed by 2 more seconds before populating it with an empty document. Sublime was sub second startup
I've always had sub second startup times. With text rendered within the first 1.5-2 at most. Time to "Actual interactivity" usually takes around 3-5 seconds, but that's mostly due to my plugins. I could start typing per-se, just not in Vim mode.
I mostly leave the editor permanently open on the project I'm working on, so I guess I don't really notice it much either way. And using the integrated terminal to change one dir back and switch to another project, then opening it with code . is a pretty good flow so I don't feel stifled in that sense either.
> I mostly leave the editor permanently open on the project I'm working on
I leave Visual Studio permanently open, but I use sublime for quick edits/viewing/changes (e.g. opening a remote file on perforce, or modifying a config file), so even 2 seconds to interactivity is just too long.
Never tried Sublime (it sounds fantastic), but VSCode is lightning fast compared to the other IDEs I currently use or have used in the past: Eclipse, IntelliJ, Visual Studio, and MonoDevelop.
IntelliJ is probably the most annoying...it takes less time than VS does, but during the 2 minutes it takes to start it hijacks the OS window focus at least 5 times. I like to actually work on other things while waiting for that beast to start up and it constantly screws everything up.
Opening big files, opening lots of files, doing search and replace in open files, and my favourite, use thousands of parallel cursors to thousands of simultaneous edits in a single file, they are all noticeable slower in VSCode.
I just opened a new window with 9 file tabs, and it opened in 3 seconds. I'm using a 2012 quad i5 desktop with non SSD drives. I suspect with SSD, it will be 1-2 seconds.
I use VS Code most of the time, but the reason I always use Notepad for taking quick notes _is_ the startup time of VS Code. If they improved it, I'd be using it for both. It is an important metric for some.
I work in IntelliJ IDEA whise startup times are horrible. However, since I always work on a set of projects, I never close them, so, essentially, startup time is 0.
Also, IDEA has scratch files for quick notes available through a shortcut (I guess VS Code might have a similar plugin), so startup tome isn’t an issue either.
Engineers like to optimize everything, including how they use their time. If you've got something in your head that you want to fix or write, you want to spend time doing just that, not staring at your screen waiting and maybe losing some of your mental model.
Startup time and crashes seem to be a problem on mine. I compiled my own vscode though so that might have something to do with it.
Still use it exclusively as my C++ IDE with the help of clangd. Would love a native easy to use editor with good support for LSP and vscode's debug protocol. Bonus points if it works in the command line.
> I'm too much of a skeptic to believe it's just so developers have a warm fuzzy feeling associated with Microsoft...
Given that the development is very-very cheap for Microsoft, even this single thing could make worthwhile for MS to continue the project. VS code appears on HN regularly, it connects to a demographic that's very different from MS's core dev audience.
> guess it requires a degree of sensitivity that I'm not bothered with - sort of like people who claim they can't hear mp3 because they can only enjoy CD quality audio (not saying it's not true for them, just that luckily I enjoy both the same).
Maybe its better on other platforms, but on linux there's 30ms keyboard input latency in vscode, compared to the avg of 6ms I get in sublime.
The perceived difference in responsiveness is significant.
My impression is that VSCode is partly about promoting TypeScript, and for what it's worth it has more or less worked on me. Create a "x.ts" and type some stuff; you will see error messages immediately that are roughly as good a first experience with an IDE as I've ever had. I mostly work in Python and Swift, mostly in VSCode, and I wish the support for those languages was nearly so good.
I am an intermediate JS programmer, fiddled with TypeScript a couple of years ago and was unconvinced. Since then TS has matured a lot, and I have been exposed to it in passing from looking at VSCode extensions. If I were to begin a web project today, I would give TypeScript a try. If it weren't for VSCode my thinking would probably be quite different.
As an open source project, VSCode is a significant example of TypeScript on Electron. As a self-hosted IDE I imagine that it has been a good source of feedback for the TypeScript team. I would be very interested to know how many TS issues (checker / compiler bugs, feature requests, etc) have emanated from VSCode.
> I imagine that it has been a good source of feedback for the TypeScript team. I would be very interested to know how many TS issues (checker / compiler bugs, feature requests, etc) have emanated from VSCode
You can filter by the "VS Code tracked" label on the TypeScript issues which will give you a rough idea.
Take a look at their telemetry policy, they basically know what type of underpants you are using! Having statistics on what 30% of the worlds' developers are doing and their preferences can be great when making business decisions. It's a bit weird that VScode is intruding on VS market though, it will be interesting when VScode threatens VS - will MS step in and stop them from implementing certain features !?
VS Code is such an excellent open-source project, and also such a great tool despite the obvious and much-bemoaned inherent disadvantages (aka "tradeoffs") that come with being an Electron-based app that it, along with its cousin TypeScript, fundamentally changed my perception of Microsoft.
I'm not monogamous with my code editors and typically have a few of them open.
These days, I notice VSCode is very likely to be one of them.
This roadmap document seems eminently reasonable, and pretty representative of how well-run the VS Code project tends to be.
I’ve always wondered why some people seem so married to a single editor. Based on the file type or context I might bounce between a number of them.
I used to use Sublime Text a lot, but that’s been completely replaced for me by VSCode.
I use IntelliJ IDEA predominantly for Java, Groovy, Python, Kotlin, PHP. I’m not a fan of its type hinting for JS or suggestions for HTML/SASS/CSS so I use VSCode for all my ‘web’ work.
I’ve also found VSCode to be faster/nicer than IDEA for random things like JSON, SQL, Dockerfiles, Vagrantfiles, Bash scripts.
IDEA generally supports these well enough, but is too noisy (constant bugging about connecting to a data source when opening a SQL file, etc.) or is just lacking a little something compared to VSCode.
> I’ve always wondered why some people seem so married to a single editor.
Familiarity, such as keyboard shortcuts. Especially for VI(M) or Emacs users, using anything else is an absolute nightmare. If you haven't been spoiled by VIM, then there really isn't much difference between "all those other editors".
I use Emacs, VIM, VS Code, and Eclipse, but they all need to have a VIM mode enabled or I'm outta there! VS Code can actually use an embedded neovim instance in its VIM mode for EX commands, which is pretty neat.
I started using Emacs like twelve years ago. At this point I'm hopelessly lost to it. My fingers natively speak a language that other editors don't understand.
> I’ve always wondered why some people seem so married to a single editor.
I'm thinking exactly opposite. I wonder why people change their IDE's/Editors so much between Eclipse/Visual Studio/IntelliJ or between notepad++/sublime-text/atom/VScode/coda/text-mate etc.
What's wrong with using vim or emacs and being happy rest of your career? It's funny so many of my colleagues kid me by saying "emacs is a great operating system but it lacks a good editor" without ever trying it while I'm using emacs without a problem for the last 6-7 years and people around me changing their editors every year to "popular editor of the year" for better features/performance.
> It's funny so many of my colleagues kid me by saying "emacs is a great operating system but it lacks a good editor" without ever trying it while I'm using emacs without a problem for the last 6-7 years and people around me changing their editors every year
I thought only the vim users used that refrain. vim users are also unlikely to switch to a different editor.
> What's wrong with using vim or emacs and being happy rest of your career?
I agree with your basic notion -- it takes quite some time to be really fluent with serious IDEs and editors, so changing is inefficient.
But just one editor/IDE doesn't work for everyone. If you favour a GUI-only editor like Sublime Text, for example, then you probably need to also know a console-based one. Or if like me you prefer a heavy IDE for most project work, you probably need to be fluent with a lightweight editor.
For me IntelliJ IDEA + emacs covers all the bases. I'll look briefly at new tools to keep familiar with the landscape, but I'd rather invest the time it would take to learn them into something which will improve my skills in something more useful to the craft than just more tools that do essentially the same things.
I’m not married to an editor so much as my bindings. I’d really hate to use an editor/ide that doesn’t have a decent implementation of at least some vim bindings, though I have to sometimes.
Ultimately I think it’s familiarity and a subtle fear that learning any new system will be a time sink.
> I’m not married to an editor so much as my bindings.
Agreed, and it's extremely annoying that VS Code has different default bindings on different platforms. I switch between Windows and Linux a lot and there's no simple way to e.g. say "use the default Windows bindings on Linux" or vice-versa.
I have to manually create my own keybindings and then copy them to every machine and then bother with keeping them in sync.
I'm not sure. I heavily switch between VIM and VSCode. I sometimes dive back into Emacs. It really depends on what I'm doing. But I like the refreshing feeling of using a different editor.
> VS Code .. fundamentally changed my perception of Microsoft.
It certainly changed my perception of electron. I don't use it daily because my editing requirements are already well met, but it really is a lovely piece of work.
As much as I wanted to like and use VS Code, Electron base still ruined it for me. If it was some other app where I do not expect instant snappiness and lower memory usage, for example, Slack (also Electron app), I would swallow it, but for an editor, I can`t.
I upvoted you to try to offset the misguided downvotes. That is indeed the worst thing about VS Code.
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.
Don't it get lost or closed by mistake all the time?
To me much of the value of a separate app is being able to cmd+tab between application and I frequently just close my browser be get remove all windows and tabs.
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.
Next lesson: you can switch to the n'th tab using Alt+<n> (or perhaps a different modifier key depending on browser and OS). Since pinned tabs appear on the left-hand side, that means you'll always have e.g. Alt+1 for email, Alt+2 for calendar, etc.
(Nice and related is that you can do Super+<n> for window switching in at least Windows and Ubuntu.)
Me, too. For instance, I use a site-specific browser for:
- 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:
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.
Uh, I believe Cmd-Shift-4 saves the image directly to the desktop, then I usually hit one of my hot corners that shows the desktop, grab it, hit the corner again and drop in the image. It's usually pretty quick. I did not know about holding Ctrl copies the file, I'll probably use that more often now because it probably is a little faster. But if you want to save an image you don't have to open up preview to save it or anything.
For me it's just saving me from minor inconveniences. Things like having an app I can easily switch to instead of flicking through many browser windows/tabs to dig it out.
I try to offload as much stuff from the web and into the desktop because it means I can do all my window management with cmd+tab and Spectacle. If something lives in the browser I have a second layer to manage with ctrl+tab, slowing me and increasing mental load.
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 :)
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.
Yet I have 32 GB of RAM on my machine, and rather than use any of that, VS2017 will just use < 2GB, and swap constantly on large solutions. The 32-bit restriction is getting ridiculous.
I use VSCode to work on medium-sized VueJS+TypeScript projects (maybe a grand total of 200 code files), and it regularly consumes around 800mb - VS territory. Perhaps it's very sensitive to how it's configured/what plugins are installed.
I assume you use ReSharper? I have a 1M+ LOC C++ application that I work on regularly and have never had a performance issue. There was definitely slow down when I moved from VC6 to VS2005, but man, that was so long ago.
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 think there are a lot of people who open and close their editors pretty regularly, I can imagine that the start-up time for VSCode can become quite significant to those people.
I don’t think Electron is entirely to blame e.g. I tried the Discord app and it was amazingly snappy (just install both Slack and Discord and you can feel the difference).
Just compare VSCode with Atom - both Electron apps, both text editors, both extensible in JS.
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)
I actually really want to know how Discord does it. Do they actually use the DOM, or just draw everything themselves?
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.
> Do they actually use the DOM, or just draw everything themselves?
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.
How much memory does it use? My emacs instance uses ~200M with a moderate amount of files(along with other processes mostly repls). I would imagine VSCode to be in the same ballpark, and 200M is not that of a big deal imo.
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.
Task manager shows working set by default. Working set is affected by things like minimizing the application, it'll also usually shrink if the application has been left idle for some time and other applications are being used. Whether it's the right column or not depends; it's more of an indication of how much the OS feels that it needs to hand over to the process, than how memory-hungry the process is. Private bytes might be a better number for that; OTOH if many of the bytes aren't touched, then they don't count for much.
Commit size isn't the most important number either. You can commit large chunks of memory and if you don't touch it, Windows won't allocate it; not in physical memory nor in page file.
> Commit size isn't the most important number either. You can commit large chunks of memory and if you don't touch it, Windows won't allocate it; not in physical memory nor in page file.
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 completely irrelevant whether physical pages have been actually allocated to back the the virtual pages that are committed
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.
I'm a little bit philosophically opposed to Electron based apps but VSCode has been nothing but snappy for me on all matter of low-end machines and virtual machines I've used it on.
>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.
More tolerable in a scence that I could live with 1-3s occasional actions in it (switching organisations for example). Not saying that it is good. But I will tolerate that more than the editor hanging on large files or taking to long to process actions which should be instantanious.
My main wish for VS Code is 'proper' multiple cursors (where by 'proper' I mean 'works the way I expect' which is the Sublime Text way).
I fully understand that if you come from a world of 2D blocks (or regions) where you can select rectangles then VS Code's way of doing things makes sense but I am so used to having multiple identical cursors and being able to swipe vertical lines through tables of text or more often down the ragged right hand side that I find VS Code frustrating for hard-core text editing.
I seem to start every new project using it and I love its language-specific coding tools (and how it handles extensions) but as soon as I need to do a large edit on a nasty piece of text I find myself switching back to Sublime.
(I will of course give it another go as soon as I start another new project)
I wouldn't call that a problem per-se. It draws a cursor where there it text to draw one. This makes sense to me as I can edit a column of values and not pick up already empty columns.
To do what you want I'd just multi-cursor the start of all the lines and hit end. Usually ctrl+arrow over word boundaries gets anywhere I need after that.
Anything fancier still I've just written a regex instead.
Could certainly be a preference option to enable blank lines on multiple cursors. it would have to fill the white space.
I've tried it and there is still a problem: the cursors draw from wherever the previous cursor was. This makes it impossible to draw a line of cursors vertically through your text without first placing a single cursor at either the top of the bottom of where you want to draw the line. So instead of click-drag (with a modifier key) you have to click-click-drag (with a modifier key).
I've also tried to put cursors along a ragged right edge and that doesn't work as it tries to create a rectangular selection. It looks like its worked but as soon as you hit a cursor key the cursors try to line up and you end up with cursors at odd positions. Very odd.
I haven't used Sublime in years now, but that was one huge feature I think about and miss often when in VSCode. I'm glad VSCode does have the current implementation of multiple cursors, and the way Sublime did it differently is subtle, but man it makes a huge difference!
I'd love to have an editor scripting language in VS Code that would be a lighter-weight way to create an editing macro than building an extension. Despite the annoying scripting languages, both vim and emacs get a lot of their power and popularity by enabling users to easily add little, custom editing features that they can then bind to keystrokes.
Not a macro recorder, but a real scripting language in which cursors, multiple selections, find results, regexes, files, folders, editor panels, the built-in terminal, menu items, semantics provided by an extension (ex: "PythonFunctionName"), external processes, git merge conflict lines, etc., were first-class objects.
The scripting language would most likely be JavaScript, of course.
I don't use VS Code and I'm surprised there isn't already a lightweight way to run some JavaScript code to script the editor. Are you saying you need to bundle up any code you write in a proper extension before you are allowed to run it? Sounds bureaucratic to me, VS Code should learn from Emacs.
Given that it's an Electron app, wouldn't it suffice to use plain JavaScript (or TypeScript, given that part of the editor's raison d'être), and add a few extra "built-in" modules specific to the VS Code environment?
Yes, I think that would be just fine as long as the modules encapsulated the "native" functionality of the editor. As long as developers could easily orchestrate and build on top of existing editor (& built-in git, terminal, extension, etc.) functionality without having to reimplement it from basic JS string processing, JS (incl. but not requiring TS) would seem the logical choice.
I tried VS Code for a few weeks and really liked it. In particular, it's super super fast (compared to vim, spacemacs, emacs and atom, all of which I've used in recent history). It's by far the fastest and smoothest text editor I've used and I was sad to leave it.
I left it because the Vim mode is completely unusable. None of the commands work like you expect them to, undo was broken and I'd periodically lose my undo history. Everything was just a little bit wrong. Which is a shame because it's otherwise a really fantastic editor.
You found it to be fast in comparison to vim and emacs? I am surprised to hear someone say this. I also think it is plenty fast for my needs, but certainly not faster than vim or emacs.
Did you mean fast in terms of performance, or in terms of your ability to edit, or something else? And you weren't using a GUI version of vim/emacs, right?
Yes, absolutely. I'm running vim in iterm2, and I haven't had time to figure out why it's slow. Things that are really slow in vim are scroll speed, a 1s-ish pause when ALE fills the quickfix window, and an undiagnosed merlin-related pause when opening ocaml files.
So scrolling is slow. Terminal related? Maybe - terminals are slow. But when highlights an error in elm or ocaml code, scrolling becomes unusably slow (not that it's really that fast otherwise).
By contrast, no plugin I loaded made VS Code slow, and it was super smooth and fast to do, yes, scrolling, all the time.
My current emacs is via spacemacs, and I'm only using it for magit. Apart from asking me to update .recentf EVERY SINGLE TIME I refresh magit, it also takes a very noticeable pause to update the git status. By contrast, that was completely backgrounded in VS Code (though I didn't really use it since I prefer magit, so apples and oranges comparison here).
TL;DR: vim is not fast, especially not if you want to do something like use it in a terminal with plugins. VS Code is actually really fast.
I definitely share the sentiment that Spacemacs is slow, which annoys the crap out of me (for a lot of things it feels less performant than Atom/VSCode because people don’t write things in an async way in elisp often it seems).
With regards to vim though, there is no reason for it to be slow, except for some specific plugin pulling you down. Are you using synchronous linters? I thought Ale was async. I would also recommend vim-plug and lazy loading for plugin management.
I’m on Mac myself and use vim regularly in iTerm, Terminal.app and Gui, and am currently not experiencing any problems. Of course, environments vary.
Also, you can try switching out your vim with neovim, which should work seamlessly.
It's not just plugins slow Vim down, a few things that come with Vim are slow too.
The worst is probably language specific support for LaTeX files, particularly syntax highlighting, there is even a tex-slow (http://vimdoc.sourceforge.net/htmldoc/syntax.html#tex-slow) entry in the Vim manual. On my old netbook (haven't heard that word in years!) it was so bad Vim lagged behind my typing, and I'm not particularly fast. I turned off syntax highlighting which fixed the lag, but missed it so much I switched to Emacs instead (and discovered AucTeX which is fantastic, so I wouldn't switch back now).
From Alacritty's FAQ:
Q: "macOS + tmux + vim is slow! I thought this was supposed to be fast! This appears to be an issue outside of terminal emulators; either macOS has an IPC performance issue, or either tmux or vim (or both) have a bug. This same issue can be seen in iTerm2 and Terminal.app. I've found that if tmux is running on another machine which is connected to Alacritty via SSH, this issue disappears. Actual throughput and rendering performance are still better in Alacritty."
I did, but it didn't work all that well for me. I just tried it a minute ago. However, I found that macvim was way better for me, once I figured out how to make it look as pretty.
That's very strange, it seems to be the case for both Vim and Neovim, and it doesn't depend on the terminal or shell I'm using. Is it just something inherent in the Mac environment then? I was always left scratching my head over the number of plug-ins people used, wondering how the program was even functional for them.
I don't really know, as I haven't looked into it much. But my vim config is in git and shared between Linux and Mac laptops. On Linux (2013 Thinkpad) I can't really detect much lag at all, but on the Mac (2015 MBPro) it's really quite annoying - to the point it subjectively seems about as "slow" as Atom. Interactive things like scrolling are especially annoying - non interactive things seem ok though.
I'm no Vim or Mac OS poweruser though - I've just kinda put up with or avoided it. Sorry I couldn't really offer much beyond confirmation :)
Thank you! I have a HUGE bias against Apple in general but when I am using a Mac I have always find it laggy compared to my Linux and even Windows terminals.
The vim emulation plugin has gotten better recently, IMO it's the best I've seen in a GUI editor. The undo history thing sort of persists because the vim plugin maintains a different undo history than vscode. They implement undo branches whereas VSCode's native undo stack does not, and the native stack only sees large chunks of changes instead of individual actions.
I'm actually working on a fork of VSCode that rewrites their native undo stack to support branching and more granular control so the vim plugin can sync to it and not maintain two undo histories. We're hoping to submit a PR for that soonish, as soon as school stops kicking my butt.
I'm not sure about the boundary where "editor" ends and "IDE" begins, and I'm not sure which side VS Code falls on at this point.
Either way, I think it worth mentioning that the Vim emulation plugin for JetBrains' products is truly the best out there... and a great milestone for others to strive toward. The scope of what's emulated (including Vim-style search and replace), the ability to cherry pick which keyboard shortcuts use Vim mappings and which use the native editor mappings, etc.
In my humble opinion, IntelliJ is a better Vim than Vim is. I noodle around with VS Code here and there... but it's approaching an uncanny valley point where it's too heavy for use as a plain text editor, but not able to compete with WebStorm (or whatever) as a web IDE.
Emacs modes normally use regular expressions for everything from syntax highlighting to semantic insights. This does not make it fast. Emacs performance usually degrades linearly with the size of the file being edited, and most CPU activity occurs synchronously and blocks the UI.
I don't think Emacs is a fast editor unless you run it bare with -Q, at which point you've left out all the stuff that makes Emacs useful.
IMO it ought to provide a state machine engine for modes to use to do syntax highlighting, something that it can cache at line boundaries, stop and start electively depending on bit of the buffer is displayed in the current window, evaluate the state machine on a background thread (so, concurrent with actual usage, unlike the idle work it already does), etc. A state machine without extra knobs would only provide lexical highlighting, but I think extra knobs (e.g. variables, stacks) could be added to make it more useful.
The retained mode text styling with font locking etc. is not the optimal design choice for performance, I suspect.
Emacs, at least in windows, can be surprisingly slow. I think they have fixed some issues with long lines, but those used to be aweful. Also large files can be slow. Also, too many packages is a problem, which we might well see in the future for VS code, too, but the javascript runtime is likely orders of magnitude faster than the emacs one, no?
vim, on the other hand, is supposed to be really quick as far as I have heard!
I only use Emacs on UNIX systems and it is quite fast.
On the old days I was usign XEmacs, which did not had any issue with Windows.
Now if someone is running Emacs as cygwin application, then it might be slow I guess, given that everything on cygwin is slower than pure Win32 applications.
I find VS Code VIM to be the best outside of well VIM and getting better.
I am thinking that in the near future the brain bending of Neovim inside of the a text editor VS Code ecosystem will happen. They already are putting parts of Neovim inside of VS Code editor in the last patch.
I just can’t put my finger on it, but in VSCode I very frequently end up in a weird vim state where I just have to hit escape until it resets to normal mode. There just seems to be a lot of corner cases or something that I end up hitting frequently.
And I’m fairly certain that is not on my part seeing as both vim itself, Spacemacs and Atom’s vim mode work superbly for me. It’s one of those things where VSCode just ends up irking me too much and I switch back to other editors :/
I suspect what you're running into is some kind of crash when running a command. I will say that I don't think we're doing a very good job handling errors, and I suspect it's that most users don't report them (they just press <Esc> and it goes back to normal).
If you try opening up dev tools when that happens, it's likely the issue will pop up.
Honestly, there's several places that from an engineering quality standpoint bother me quite a bit. Performance on rapidly repeated actions is one. We have a couple race conditions too. A bunch of inproperly handled errors is another.
However, most of these don't really impact most users most of the time. If you're using vim, you're probably not holding down `dd` or rapidly typing actions one after a while. Similarly, as errors are separated into their own action and are captured at the top level, hitting escape is usually enough to get you back to a usable state.
I stopped thinking of VS Code as an "editor" and more as a lightweight IDE and my perceptions about it changed a lot. It's still way faster / smoother than working with Atom though, and I used Atom since it came out, but it's too sluggish feeling. Also search in VS Code is powered by ripgrep which is coded in Rust, and it is blazing fast.
I’d love to see more IDEs try to address the issue of Spellcheck in code editors. Currently, you can do it by writing your own spell checker and embedding it in your language server, but this is a recipe for repeated work and inconsistent user interfaces.
And I always turn if off because it is unusable. For text it's okay but for code it's rules doesnt make any sense - concatenated words are marked as errors which is real annoying.
I believe NetBeans only spell checks comments and other 'real' language text (git commit messages?), not code itself. I'd imagine other IDEs to do the same. It's really silly if some IDE spell checks code and marks camelCase as errors.
I just tested some things in PyCharm. It has no problem with word_word or wordWord as variable names. It's even smart enough to flag just the non-word in word_ajsjasjasa.
It will also put a squiggly under camelCaseWords in Python code by default, but that's because of PEP8 style rules, not spelling.
I wonder what the "issue dynamic" will be in the coming months/quarters. There are currently 5000+ open issues, 3000 of them feature requests. I hope the roadmap doesn't present any new features, but it's solely working on squashing all these to bring the issue number down. Looking at the Insights page for the last month (1600 closed issues, 630 new issue), I'm remaining hopeful, but only time will tell. I originally wanted to write that VS Code needs a "Snow Leopard" iteration, but it seems that it's already underway.
I really like how relaxed and informal this way of presenting a roadmap is (especially coming from a corporation like Microsoft).
Also, the fact that they've identified and focused on keeping startup time low and performance high is a core point for the value of a code editor really gives me hope for VSCode. Especially that they seem to realise responsiveness and low resource usage is more valuable than blindly adding new features and extensions.
EDIT: oh, instead of defining a color scheme with regexes (which kinda sucks), you would define colors based on the semantics given by the language service. That would be extremely nice indeed.
Has configuration become any better? I tried using VS Code for both Go and Python and all the magical stuff you needed to add to JSON files in weird places became a show stopper. I simply cannot figure out how it ties together and or figure out what my configuration options are.
You edit one personal settings JSON file for all of your options. You don't have more than one file and it over rides the options so the only things in your JSON file are your options and I comment a ton about what and why they are there.
I prefer this over any gui system. I can copy and paste this and have the same options across all my machines.
I don't remember that ever being the case. The settings are in settings.json, that's "how it ties together."
It opens alongside the default settings file, that's a searchable list of "what my configuration options are."
Clicking the name of the property in the default settings file copies it to your personal file with the value you select. It's even easier than Sublime to configure.
I also found configuration to be obnoxious when I first tried VS Code. It's better now.
It's still a JSON file, but the UI for editing it has improved a lot over the past year or so. You can search/filter the default configuration to see what options are available, and then you can just click each option to override it in your user or workspace config.
Is anyone aware of an article detailing how the VS Code team was able to realize so much performance out of Electron? VS Code is one of the most native-feeling, lightweight Electron products I've used (as compared to say, Slack) and I wonder how they got there.
Like any webapp they analyzed their paint times and made great performance improvements.
From the data structures of how they store lines and tokens of currently edited files, scrolling, refreshing changes on the screen etc they analyze perf, see what can be optimized and make it happen. Very few teams put perf above features at MS. Vscode is exceptional in that sense.
Also vscode uses processes quite a bit. The main app lives on one process, the language servers are all different processes, extensions are different processes etc. all communicating over jsonrpc
This means the main editor cannot get clogged by an extension hanging up or crashing.
I have 22 years of daily vi experience. VS Code is the only visual editor that I can stomach outside of vim. I have tried sublime, eclipse and hated them. Tried emacs many occasions, but just couldn't be bothered to learn all those shortcuts.
That allows to do syntax highlighting without change of DOM. In VS Code, in order to make things at least somehow moving, they were forced to implement sliding window editing - DOM represents not full text but only viewable portion. That creates a lot of problems and significant portion of Code is the fight with limitations of browser's DOM.
> but it sends data to Microsoft even with Telemetry et al off
I think Microsoft responded 100% correctly. They stated what they were doing, proved what they did, and they were wrong and stopping it.
BTW I rather deal with a developer that is that responds this way. I also don't mind my editor sending update pings and when I have crashes which most programs are opt-out.
But we don’t need to do that and I don’t think it’s what you expect as a user – so we will stop sending anything i.e. even the opt out event Look for a change there soon.
Thanks for bringing this to our attention and I hope you enjoy working with VS Code.
Actually, the issue link you give actually states that it doesn't if you don't want it to.
It used, at time of issue creation, that one telemetry call was still sent, to tell that you disabled telemetry.
They have since removed that call too, and the only ones left are those to the update server at startup to know if a new version is available (and one to extension market to know if extension updates exists). It can be user disabled, by disabling auto update.
I hate how Windows 10 telemetry is forced down your throat, but for vs code there is no such issue
Most people really don't care if MS knows you opened Code, used it with JS and Python projects, and installed 3 extensions. And yeah, it makes Code much better when MS knows how you're using it, btw
Does anyone know what the "Investigate into a native model layer" point might be about? It sounds very relevant to my interests, but though it is apparently ongoing, I wasn't able to find any issues or other pages referencing those terms.
I use VS Code and enjoy it very much. However, for some reason the git diff visualizer doesn't really work anymore - I have to re-open the IDE to get it to show new changes to saved files. Anyone else have this issue?
> for some reason the git diff visualizer doesn't really work anymore
Yep, exact same issue with recent releases VS Code releases on RHEL. Every few days VS Code starts diffing against an old version of the code and I have to completely exit and restart.
This release cadence from MS is completely killing some internal packaging operations at big corps I've worked at.
(For those who don't know, applications are typically QA-ed and packaged so they can be automatically requested and deployed via MS SMS or whatever the latest version is. No downloading .exe)
Typically this packaging process takes longer than it does MS to release a new version. They're in a constant state of catch-up, and it's frustrating for developers that want the latest and greatest version.
This speaks more about enterprise "packaging process". Why can't they let the devs manage their own machines? This is one big reason devs love Macbooks, because OSX just doesn't allow the employer to fuck around with the machine a lot.
"Why can't they let the devs manage their own machines?"
Part of the problem is that then the devs aren't actually managing the systems, they are blindly trusting the vendors. To a large extent, (re)packaging is make-work that should not need to happen, but it does provide a kind of safety fuse. In the event that a vendor breaks something or worse, unilaterally decides to change the product, organizations needs to be able to put a stop on new versions. The change of icons on VS Code was a trivial misstep, but it demonstrates that the VS Code team has the power to push changes that that users do not actually want on to large numbers of systems.
It is the same dynamic as the snap/flatpak vs. Linux distribution packaging debate. Most of the time, the developer can deliver their software faster, more reliably, and with better QA, if they are given a direct pipeline to user desktops. Sometimes, though, they will screw up, or they will make a decision that works for them, but not their users.
Well, I do appreciate the service that distributions do.
In Debian everything has a manpage, even if upstream does not provide one and things install into the right directories and integrate into the system well.
If for instance Chromium adds some phone home functionality, I trust that it will be patched out...
The homebrew debacle has shown me that today's "open source" developers don't care about their user's privacy.
I like VS Code. Been using it for a few months now. Would be nice if it started up faster though. Sometimes I still use sublime just to quickly open a single file.
For javascript, typescript etc VS code is excellent. For simple hacking I still use vim a lot, and for medium side projects I just open geany which is light and fast and does the job fairly well.
At the moment for web related work I use vscode, otherwise I still keep coming back to vim and geany, which are light-weight, quick and get the job done.
Geany is truly excellent, I hope it can keep evolving as it has been for many years.
I tried VS Code for a while and the vim integration is really good. Unfortunately it's just not-quite-there IMO. I have a few muscle-memory things like ":tabe foo<tab>" that breaks when I try the tab completion (and IIRC it does something irritating like moving focus).
The problem with `cmdline` modes is definitely that tab completion doesn't work imo. Unluckily, that's blocked on the VSCode side, although it is possible to move our cmdline down to the status bar (probably would have been the better choice to begin with, really).
For example, with the neovim rewrite it's possible to expose not only tab completion, but also the wildmenu: https://imgur.com/DO6IXYb
The question I'm wondering about is what is Microsoft's end game with this? I'm comparing this to the history of Google Chrome that, when released, was similar in the sense that it was better than the alternatives: wickedly fast, open sourced, with no apparent strings attached. The business benefits to Google and market control from owning Chrome are obvious today and I'm trying to understand the long term view in VSCode - i.e how to you eventually create business value from a free editor? Premium features? Better integration with Microsoft's services? I wonder if there's a deeper vision - I mean, as opposed to Chrome, VSCode does not know much about me personally, does not provide much data to further leverage Microsoft's services, and targets a much narrower audience to begin with. So, what's the business model behind it's development. I'm too much of a skeptic to believe it's just so developers have a warm fuzzy feeling associated with Microsoft...