Obligatory comment: I really like VSCode but keep jumping back and forth between it and Sublime because of startup time.
I like VSCode enough to use it daily and extensively and jump back to sublime when I need to jump around projects fast–when startup time becomes crucial.
I believe they will solve this issue at some point.
I think they can probably improve, but just due to being built on chromium means a level of overhead that's likely higher than sublime. If fix means acceptably close, they might get there. I'm now using VSCode daily and have no real complaints.
By startup do you mean the initial loading of VSCode or the cost of switching project contexts within VSCode?
I wonder if you can just pre-load Code and hide it in some manner plus use CLI commands to open new folders/files within the existing VSCode instance rather than a new one?
I do agree, though. VSCode has so many benefits but every so often I hit an irregular usage where I'm opening lots of various stuff and its a bit slow.
While VSCode is great, it's also useless as $EDITOR.
It's very slow to start (when it's already running), and while you'd think you could speed this up by making it open a new tab in your current window and and return control the parent process when you close that tab ("code -r -w", I believe), that's not possible. It can open the new tab, but it never relinquishes control, at least not for me.
Wouldn't be an issue if startup was super fast with "code -w", but creating new windows, even when VSCode is running, takes several seconds.
> and while you'd think you could speed this up by making it open a new tab in your current window and and return control the parent process when you close that tab ("code -r -w", I believe), that's not possible.
I'm running a Touch Bar MBP connected to the LG UltraFine 5K with no visible problems FullScreen or not on the LG panel.
Resolution is set for "Default for display" and I run Flux. Initially I had some issues with the monitor that went away when I got a new USB-C cable. Perhaps that would help...?
Author of the blog post here. Canvas works fine for HDPI screens, you just need to handle it by tweaking the size of the canvas element (in CSS pixels, .style.width) and the number of actual pixels in the canvas (.width).
I'm on Linux, but I actually chose VS Code over Sublime 2 because I switched to an HD display. Sublime 2 does not scale tabs (or at least it didn't when I switched) which drove me nuts. I didn't expect to like VS Code but I do. I like it a lot, especially for going to and from different display resolutions.
Having never looked at the source, I'm curious about how you build an editor using web technologies. Is it just a big textarea that gets manipulated with JS?
The textarea is to accept input, presumably. It's a trick often used in a normal browser HTML page, too. You get focus, keypresses, copy/paste, etc. via the native browser UI. It's a shame that HTML doesn't provide something similar, but as a hack it's not too bad.
I opened the DevTools inside vscode and executed 'document.getElementsByTagName("canvas")'.
In a single editor group[1] in edit mode there are two canvases. One is for the overview over the scroll bar. The second is the minimap. When you are in diff mode there are two more canvases to show the diff on the right side.
I really wish Microsoft had used a different platform to build VS code on, like C#/Mono, Java, anything except Javascript/Electron basically. I just started using VS code for C++ development, trying to switch from Vim, an I basically like everything about the concept, but the execution and quality/polish of the software is mediocre at best. At least three times a day random stuff breaks: code completion stops working, switching between header/source (using a plugin) stops working, all keyboard input except shortcuts stops working, Vim plugin acting up, the app randomly starts to use 40% cpu until I kill it etc. On top of that performance is just so-so for most things (editing, autocomplete), and quite slow for others (e.g. gotoSymbol for the whole project). This was very disappointing for me to find out considering all the praise VS code gets for being ‘probably the best Electron app’.
I don’t mean this as a flame, but the software just feels like all the other applications I tried that are based on web technology. If it works everything is fine, but if you stress the application enough, inevitably things start to fail in ways that suggest it was simply too difficult to properly QA and test the thing to the point it doesn’t hit some weird platform edge case. I sincerely think the product itself is awesome, apparently that’s enough for people to put up with the shoddy stability and general sense of quality?
Maybe there are other reasons and the platform is not actually the problem, but I find it remarkable that something as advanced as VS code fails in similar ways my own web-based projects usually fail.
And now I read they are going to implement their own console rendering using HTML canvas, because the obvious ways to implement it when you are stuck with a Electron have major shortcomings... Somehow I just feel Microsoft with all their talent and resources could have made an even more impressive product if they had made the exact same thing based on some other platform...
Something is seriously wrong with your setup. I know many vscode users, and none of them are having your problems.
I'm not saying you aren't having real problems, but they aren't common and they can appear in any editor -- I used to fill vim with plugins and it would hang frequently.
very good clarification the truth I liked your article, I would love to learn more of this world of technology as a trend to niverl worldwide and develop web pages and develop applications that allow us to go forward and know more about what is new IA
My setup is just the official, latest release, with the Microsoft plugin for C++, the Vim bindings everyone uses, and one additional plugin for switching between header and source. I customized nothing besides a few keybindings and enabling neovim mode. This is on Ubuntu by the way.
I also used VS code a little on macOS for web development, and to be fair, I didn’t run into any of these problems there. But that’s for projects that are literally 100 times smaller than the C++ project I’m working on.
I don’t really buy the anecdotal ‘other developers never have any problems with VS code’ observation. I’ve been following the VS code release announcements here on HN for a while (it’s what got me interested in trying VS code), and they regularly seem to contain fixes for weird platform problems or regressions, to the point they’ve even had to retract a few of them because of serious problems found after deploying the update.
Look at the past threads for releases (I wont link, but) they are filled with nothing but praise.
I'm totally non-affiliated with VSCode, but switched from Atom a few months ago and yes, anecdotally it's been an amazingly smooth experience.
I am actually the opposite of you: totally thankful for JS and electron, and I think they are the best possible future for apps.
To be honest, I really think people have an emotional reaction to JS/Electron one because it's seen as a threat to their preferred language, and two because it has all this built up hate due to legitimate past problems. A few years of pretty hectic pace in JS-land and now it's close to greatness, but still very inconsistent, so people still love to hate it. Couple that with some poorly made apps (looking at you Spotify/Slack) and you have a weird sect on HN that now vilifies Electron/JS with totally incorrect arguments about stability and speed (both are very doable with modern practices).
I'm not saying you are this person, or your grievances aren't real. But I'd be happy to put some money on the following points:
1. Electron/JS apps will be more prolific in the next 5 years
2. They will also be clearly the best platform for speed, stability and flexibility due to massive and ever improving ecosystems and dev tools.
Both have been happening, and to be honest, today we're at a point where I think it's a no-brainer to choose JS for just about any complex UI. The problem is you're wading into a fast-changing, diverse ecosystem, and a few wrong choices there can be very painful.
I am floored at how eloquently you've put every single one of my thoughts on the matter. Seriously, bravo (and thank you because I will inevitably quote you).
> it's a no-brainer to choose JS for just about any complex UI
Javascript? Sure. Electron? Maybe not. Show me an Electron app with load times that aren't measured in seconds. Or an Electron-based text editor that doesn't choke on a moderately sized text file. VS Code is currently taking half a gig of ram on my notebook with three text files open...
I happen to quite like VS Code, but to claim that Electron is a no-brainer is simply false. There are serious tradeoffs.
It just stops working and I cannot enter any text in the editor area anymore, even though all keyboard shortcuts and the terminal area still work. Enabling/disabling the extension fixes the problem, until it occurs again. I've disabled neovim mode for now, so far this seems to help but time will tell. Interestingly there is at least one bug open in the vscodevim issue tracker for the exact same problem, but it's closed because 'it hasn't been possible to reproduce this for a long time' :-/
very good clarification the truth I liked your article, I would love to learn more of this world of technology as a trend to niverl worldwide and develop web pages and develop applications that allow us to go forward and know more about what is new IA
I work in the VS Code team - the experience you are having is not the experience we aspire to. It would be great to dig into this a little more and see what we can learn.
Perhaps the easiest way to have a deeper dialogue is via a GitHub issue. The easiest path to creating one is leveraging 'help->report issue' that will include some additional context that will help us dig in a little more.
Thanks, I’ve definitely not given up on VS code considering how soon after I started using it I already liked it as much as I do. So if I somehow manage to isolate/reproduce some of the problems I’m seeing, I will file an issue fo it.
As I point out in a sibling comment, reporting aberrant behaviour can be difficult because the cause is usually unclear. Why is Code Helper using 100% CPU? Who knows. It happens every few days and doesn't seem be related to anything specific I do. More tools (such as a "task manager" similar to Chrome's) to gain visibility into what VSCode is doing would help here.
For excessive Code Helper CPU usage, you should be able to surface what the file/arguments were used to launch a Code Helper instance (how you do this depends on the OS). That will tell exactly which component is acting up, eg. TypeScript, search, terminal, extension, etc.
This may be a recent change? The last time I tried reporting excessive CPU usage, the Code Helper process didn't have any context info in the command line.
I'm much happier than you, but I concede there are some rough edges, especially related to extensions.
In particular, ESLint and the Go extensions randomly cause problems for me. I often lose JS autocompletion and linting; no errors, just stale or missing markers and only fix is to restart the window. Often the Go completer or "go vet" or whatever goes bananas and gets stuck taking 100% CPU. Often a random "Code Helper" sits taking 100% CPU for no discernible reason. Sometimes the Helper mysteriously gets better after a few minutes.
I can always work around these issues by restarting stuff. The main problem is that I can never report anything cogent based on this misbehaviour, because I have zero visibility into what is causing them; for example, as far as I know VSCode doesn't have a "task list" for its async operations (such as indexing, linting etc.), so there's no way to correlate misbehaving child processes with those operations like you can do in Chrome. I once submitted a Github issue with dumps (macOS process traces) when a Code Helper process had sat at 100% for an hour, but the VSCode team said it wasn't helpful, but they also didn't offer any way to actually trace the problem. There are also no logs as far as I can tell.
Admittedly, often it is extensions or external tools that misbehave, not VSCode, but the above remains true -- without any visibility there's no way to fix.
For all that, VSCode is the best IDE I have had since I was a Java developer using Eclipse around 2006 or so. VSCode doesn't quite reach that level of integration (for example, Eclipse had instant incremental compilation built in, whereas in VSCode linters are for some reason dumb and stateless and have to potentially look at your entire project every time you make a code change, which is the opposite of instant), but it's getting there.
Author of the blog post here. The standard shortcuts are ctrl+` for toggling the panel and ctrl+shift+` for creating a new terminal. This is what I use on top of that:
A big thing that I use is that if you do quick open (`ctrl+p`) and then type `term `, you can then type the terminal number to go to the specified terminal.
That is pretty concerning if they have to drop down to what is essentially a slightly improved framebuffer to get acceptable performance for a terminal emulator. The Electron waters are shallow and when you jump in head first you might hit a performance wall sooner than your feet hit the water.
I predict that by 2020 they'll have migrated the editor and terminal emulator to an OpenGL surface.
Or maybe you just underestimate the demands of a terminal emulator? More specifically, the demands of many users of a terminal emulator. People want to try to see the matrix, they want 60fps scrolls full of arcane details too quick to actually be useful, but clear enough to kind of skim to give the impression that it may be useful.
VSCode isn't the first terminal emulator to use a videogame canvas renderer approach (by decades), and won't be the last. (Not just because the work was PRed to a shared library that other applications use too, but also because there will always be people trying to see the matrix in terminal emulators as long as there are terminals to emulate.)
That was done because it was the only method available or because they started out with high performance / low latency / ... goals. Here is the VS Code team saying DOM performance was useless. And at the end of the day we're talking about 80x20 characters, sometimes color.
No, the VS Code team is saying DOM performance isn't enough for the high performance / low latency demands they are seeing.
The performance with DOM was already good enough for all my needs, personally.
They had a lot of people wanting 60fps consoles, so they decided to take a 60fps approach, and even though it is "just" text/color/limited graphics, it shouldn't be a surprise that the 60fps approach is the same one they would take for a more graphics-focused approach somewhere else.
I don't think it's entirely fair to say that they had to drop down. I suppose that all comes down to what you mean by "acceptable". Personally, I think they chose terminal rendering as something to optimize and I think it's a great choice. You emphasized "terminal emulator" in your comment. I don't think they chose to optimize the terminal because it was new ground, but rather because it's a well understood problem space. The Electron waters are limited, yes. But I think it's nice to see developers pushing at those boundaries, no?
What's the case for using the terminal in VSCode? I use a modern multitasking computer where VSCode is in one area or screen and my terminal in another (and other things in others).
By using my own terminal I get to keep everything custom about that terminal rather than having another one.
Surely there's reasons that I'm missing?
Edit: thanks for all the responses. A lot of great new things I didn't think of before!
Wouldn't it be better to run the linter in the background and have the editor mark the problem lines? I have keyboard shortcuts bound to "next marker" and "previous marker" so I can jump to the next problem.
They don't work across an entire workspace, sadly, and I have an outstanding Github issue about it that has not seen any activity for years. Project-wide linting is something that VSCode really lacks right now. For example, it's easy to change something in one file that breaks another file, but you won't get any error markers until you go to the broken file.
> Wouldn't it be better to run the linter in the background and have the editor mark the problem lines? I have keyboard shortcuts bound to "next marker" and "previous marker" so I can jump to the next problem.
The ESLint plugin does both these things; linting is just an example. I use the terminal's click-to-open file feature for opening files that have have merge conflicts during git rebase, and for opening spec files that failed. It's just handy to have.
For me it's keeping things organized in my mindspace. When I tab to a VS window, it has my code right there alongside it's relevant git cli and server output. Helpful when I'm running a lot of services locally or simultaneously adding code to a package and using it locally with npm link in a different codebase, before publishing.
With something like iterm it's a little more sluggish to remember which tile corresponds to which codebase, especially when it's spitting out a lot of logs and obscures it's current directory
- You open a project, the terminal is already set in the working directory of your project. It saves you to have to cd to the right directory.
- When you debug, you see the logs of your server at the same time as the stack trace, the breakpoints without having to play with the windows.
- you can put in the vscode project some developers command, like linting, building, launching in debug mode... adding buttons to your interface to run them.
- No need to start two programs, close two programs that you always use together.
As someone who regularly has several browser-based projects open, it's nice having a small part of the window that shows the current progress of the build.
I've gone back and forth using a "normal" terminal and using the one in VSCode. I often end up using the latter since it keeps the build progress with the proper project.
Having the project folder as the CWD automatically is a really nice time saver, too.
> Misaligned characters: Due to many monospace fonts not being strictly monospace for some Unicode characters, this could lead to situations like the one seen on the right-side of the image below: (image)
What are they referring to? I've been staring at the pic for nearly a minute and can't see anything misaligned.
I'm an iOS Developer learning React, using Webstorm I can get all the auto completion + some other things I like from Xcode. Can I set up VS Code to do the same?
I've been using VSCode for a while. I have this one issue with it, I couldn't figure out how to switch between the Terminal & the editor. Often I just (CMD+ Tab) to go to an independent terminal and execute some command. The only way I could figure out to do this within VSCode is "Contrl + ~", but have to do it twice if it's already open. So, does any of you know if there's an easy way of switching between the editor and the terminal?
Alacritty is extremely fast, but you need to use a terminal multiplexer like tmux or screen if you want commonly used features like tabs or scrolling. Which would be fine, except that both tmux and vim run significantly slower than expected in Alacritty on macOS; there's a performance bug somewhere.
73 comments
[ 3.7 ms ] story [ 117 ms ] threadI like VSCode enough to use it daily and extensively and jump back to sublime when I need to jump around projects fast–when startup time becomes crucial.
I believe they will solve this issue at some point.
I wonder if you can just pre-load Code and hide it in some manner plus use CLI commands to open new folders/files within the existing VSCode instance rather than a new one?
I do agree, though. VSCode has so many benefits but every so often I hit an irregular usage where I'm opening lots of various stuff and its a bit slow.
It's very slow to start (when it's already running), and while you'd think you could speed this up by making it open a new tab in your current window and and return control the parent process when you close that tab ("code -r -w", I believe), that's not possible. It can open the new tab, but it never relinquishes control, at least not for me.
Wouldn't be an issue if startup was super fast with "code -w", but creating new windows, even when VSCode is running, takes several seconds.
So I still use "joe" as $EDITOR.
Exactly this is actually coming in v1.17.
Resolution is set for "Default for display" and I run Flux. Initially I had some issues with the monitor that went away when I got a new USB-C cable. Perhaps that would help...?
Just open the dev tools and have some fun. You'll learn a lot.
I opened the DevTools inside vscode and executed 'document.getElementsByTagName("canvas")'.
In a single editor group[1] in edit mode there are two canvases. One is for the overview over the scroll bar. The second is the minimap. When you are in diff mode there are two more canvases to show the diff on the right side.
[1] https://code.visualstudio.com/docs/getstarted/userinterface#...
I don’t mean this as a flame, but the software just feels like all the other applications I tried that are based on web technology. If it works everything is fine, but if you stress the application enough, inevitably things start to fail in ways that suggest it was simply too difficult to properly QA and test the thing to the point it doesn’t hit some weird platform edge case. I sincerely think the product itself is awesome, apparently that’s enough for people to put up with the shoddy stability and general sense of quality?
Maybe there are other reasons and the platform is not actually the problem, but I find it remarkable that something as advanced as VS code fails in similar ways my own web-based projects usually fail.
And now I read they are going to implement their own console rendering using HTML canvas, because the obvious ways to implement it when you are stuck with a Electron have major shortcomings... Somehow I just feel Microsoft with all their talent and resources could have made an even more impressive product if they had made the exact same thing based on some other platform...
I'm not saying you aren't having real problems, but they aren't common and they can appear in any editor -- I used to fill vim with plugins and it would hang frequently.
I also used VS code a little on macOS for web development, and to be fair, I didn’t run into any of these problems there. But that’s for projects that are literally 100 times smaller than the C++ project I’m working on.
I don’t really buy the anecdotal ‘other developers never have any problems with VS code’ observation. I’ve been following the VS code release announcements here on HN for a while (it’s what got me interested in trying VS code), and they regularly seem to contain fixes for weird platform problems or regressions, to the point they’ve even had to retract a few of them because of serious problems found after deploying the update.
I am actually the opposite of you: totally thankful for JS and electron, and I think they are the best possible future for apps.
To be honest, I really think people have an emotional reaction to JS/Electron one because it's seen as a threat to their preferred language, and two because it has all this built up hate due to legitimate past problems. A few years of pretty hectic pace in JS-land and now it's close to greatness, but still very inconsistent, so people still love to hate it. Couple that with some poorly made apps (looking at you Spotify/Slack) and you have a weird sect on HN that now vilifies Electron/JS with totally incorrect arguments about stability and speed (both are very doable with modern practices).
I'm not saying you are this person, or your grievances aren't real. But I'd be happy to put some money on the following points:
1. Electron/JS apps will be more prolific in the next 5 years
2. They will also be clearly the best platform for speed, stability and flexibility due to massive and ever improving ecosystems and dev tools.
Both have been happening, and to be honest, today we're at a point where I think it's a no-brainer to choose JS for just about any complex UI. The problem is you're wading into a fast-changing, diverse ecosystem, and a few wrong choices there can be very painful.
Javascript? Sure. Electron? Maybe not. Show me an Electron app with load times that aren't measured in seconds. Or an Electron-based text editor that doesn't choke on a moderately sized text file. VS Code is currently taking half a gig of ram on my notebook with three text files open...
I happen to quite like VS Code, but to claim that Electron is a no-brainer is simply false. There are serious tradeoffs.
I work in the VS Code team - the experience you are having is not the experience we aspire to. It would be great to dig into this a little more and see what we can learn.
Perhaps the easiest way to have a deeper dialogue is via a GitHub issue. The easiest path to creating one is leveraging 'help->report issue' that will include some additional context that will help us dig in a little more.
In particular, ESLint and the Go extensions randomly cause problems for me. I often lose JS autocompletion and linting; no errors, just stale or missing markers and only fix is to restart the window. Often the Go completer or "go vet" or whatever goes bananas and gets stuck taking 100% CPU. Often a random "Code Helper" sits taking 100% CPU for no discernible reason. Sometimes the Helper mysteriously gets better after a few minutes.
I can always work around these issues by restarting stuff. The main problem is that I can never report anything cogent based on this misbehaviour, because I have zero visibility into what is causing them; for example, as far as I know VSCode doesn't have a "task list" for its async operations (such as indexing, linting etc.), so there's no way to correlate misbehaving child processes with those operations like you can do in Chrome. I once submitted a Github issue with dumps (macOS process traces) when a Code Helper process had sat at 100% for an hour, but the VSCode team said it wasn't helpful, but they also didn't offer any way to actually trace the problem. There are also no logs as far as I can tell.
Admittedly, often it is extensions or external tools that misbehave, not VSCode, but the above remains true -- without any visibility there's no way to fix.
For all that, VSCode is the best IDE I have had since I was a Java developer using Eclipse around 2006 or so. VSCode doesn't quite reach that level of integration (for example, Eclipse had instant incremental compilation built in, whereas in VSCode linters are for some reason dumb and stateless and have to potentially look at your entire project every time you make a code change, which is the opposite of instant), but it's getting there.
Curious what keyboard shortcut people use to move focus from editors to the Terminal and create new terminals? Anyone use tmux inside terminal?
{ "key": "ctrl+`", "command": "workbench.action.terminal.focus", "when": "!terminalFocus" }
This will focus the terminal if the focus is anywhere else, if the terminal is focused it will close it.
You can add this one if you want ctrl+` to only toggle focus between the terminal and the last editor:
{ "key": "ctrl+`", "command": "workbench.action.focusActiveEditorGroup", "when": "terminalFocus" }
On tmux, Joao from the team did a write up on configuring persistent sessions in the terminal using tmux https://medium.com/@joaomoreno/persistent-terminal-sessions-...
``` { "key": "ctrl+`", "command": "workbench.action.terminal.focus", "when": "!terminalFocus" } ```
I predict that by 2020 they'll have migrated the editor and terminal emulator to an OpenGL surface.
VSCode isn't the first terminal emulator to use a videogame canvas renderer approach (by decades), and won't be the last. (Not just because the work was PRed to a shared library that other applications use too, but also because there will always be people trying to see the matrix in terminal emulators as long as there are terminals to emulate.)
The performance with DOM was already good enough for all my needs, personally.
They had a lot of people wanting 60fps consoles, so they decided to take a 60fps approach, and even though it is "just" text/color/limited graphics, it shouldn't be a surprise that the 60fps approach is the same one they would take for a more graphics-focused approach somewhere else.
By using my own terminal I get to keep everything custom about that terminal rather than having another one.
Surely there's reasons that I'm missing?
Edit: thanks for all the responses. A lot of great new things I didn't think of before!
edit: quick youtube example how it works together https://www.youtube.com/watch?v=cMrDePs86Uo
They don't work across an entire workspace, sadly, and I have an outstanding Github issue about it that has not seen any activity for years. Project-wide linting is something that VSCode really lacks right now. For example, it's easy to change something in one file that breaks another file, but you won't get any error markers until you go to the broken file.
The ESLint plugin does both these things; linting is just an example. I use the terminal's click-to-open file feature for opening files that have have merge conflicts during git rebase, and for opening spec files that failed. It's just handy to have.
With something like iterm it's a little more sluggish to remember which tile corresponds to which codebase, especially when it's spitting out a lot of logs and obscures it's current directory
- When you debug, you see the logs of your server at the same time as the stack trace, the breakpoints without having to play with the windows.
- you can put in the vscode project some developers command, like linting, building, launching in debug mode... adding buttons to your interface to run them.
- No need to start two programs, close two programs that you always use together.
I've gone back and forth using a "normal" terminal and using the one in VSCode. I often end up using the latter since it keeps the build progress with the proper project.
Having the project folder as the CWD automatically is a really nice time saver, too.
Hope the configurable panels allowing terminal on right side will get merged soon.
[0] https://github.com/Microsoft/vscode/pull/34267 [1] https://github.com/Microsoft/vscode/issues/2806
What are they referring to? I've been staring at the pic for nearly a minute and can't see anything misaligned.
Try cloning my repo here:
https://github.com/styfle/react-server-example-tsx