Integrated Terminal Performance Improvements
code.visualstudio.com
code.visualstudio.com
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.
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
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.
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.
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.
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" } ```
What are they referring to? I've been staring at the pic for nearly a minute and can't see anything misaligned.
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 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.
Try cloning my repo here:
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#...
Just open the dev tools and have some fun. You'll learn a lot.
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...?