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.
> 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.
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.
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.
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 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).
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.
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.
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'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?
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.
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.
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.
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.
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.
[+] [-] placebo|8 years ago|reply
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...
[+] [-] WorldMaker|8 years ago|reply
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.
[+] [-] albertgoeswoof|8 years ago|reply
e.g. if VS Code and the idea of MS supporting OSS was around 5 years ago, perhaps Windows phone might have had enough apps and been successful.
[+] [-] Vinnl|8 years ago|reply
It's mostly not liking Electron-based, performance is very reasonable for VSCode, I think.
As for the end-game: it's most likely luring you into Azure. Tight integration with a proper editor/IDE might give it an edge over competitors.
[+] [-] sz4kerto|8 years ago|reply
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.
[+] [-] chmln|8 years ago|reply
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.
See https://pavelfatin.com/typing-with-pleasure/ if you're curious.
[+] [-] gwking|8 years ago|reply
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.
[+] [-] z3t4|8 years ago|reply
[+] [-] Franciscouzo|8 years ago|reply
[+] [-] D_Guidi|8 years ago|reply
[+] [-] pacala|8 years ago|reply
[+] [-] veidr|8 years ago|reply
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.
[+] [-] ssijak|8 years ago|reply
[+] [-] veidr|8 years ago|reply
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.
[+] [-] pjc50|8 years ago|reply
(joking but also serious)
[+] [-] yodsanklai|8 years ago|reply
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...).
[+] [-] spinningarrow|8 years ago|reply
[+] [-] xfer|8 years ago|reply
[+] [-] wvenable|8 years ago|reply
[+] [-] Shorel|8 years ago|reply
>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.
>It's the rolling coal of computers.
[+] [-] hasenj|8 years ago|reply
[+] [-] sambeau|8 years ago|reply
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)
[+] [-] SiVal|8 years ago|reply
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.
Now there's a stretch goal....
[+] [-] omaranto|8 years ago|reply
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.
[+] [-] unknown|8 years ago|reply
[deleted]
[+] [-] vanderZwan|8 years ago|reply
[+] [-] pbiggar|8 years ago|reply
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.
[+] [-] giancarlostoro|8 years ago|reply
[+] [-] moomin|8 years ago|reply
[+] [-] calcifer|8 years ago|reply
[+] [-] rvern|8 years ago|reply
[+] [-] drej|8 years ago|reply
Good luck to everyone on the VS Code team.
[+] [-] rkachowski|8 years ago|reply
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.
[+] [-] Vinnl|8 years ago|reply
[+] [-] dmitriid|8 years ago|reply
[+] [-] veidr|8 years ago|reply
Then for bonus points, come back here and post link to it. I would support it; my team wants that, too.
[1]: https://github.com/Microsoft/vscode/issues
EDIT: there is one: https://github.com/Microsoft/vscode/issues/1927
[+] [-] pbiggar|8 years ago|reply
[+] [-] mrweasel|8 years ago|reply
[+] [-] jclay|8 years ago|reply
[+] [-] nojvek|8 years ago|reply
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.
[+] [-] segmondy|8 years ago|reply
[+] [-] c-smile|8 years ago|reply
This is prototype I've made to give an idea of how the same thing could be done in Sciter: https://sciter.com/htmlcss-desktop-ui-solutions-distribution...
In general it is expected that such thing can be done in 5% of VS Code distribution size.
Sciter draws things faster than Electron as e.g. on Windows it uses DirectX directly. Electron uses Skia that is mostly CPU based rasterizer.
Yet to make syntax highlighting I've introduced "marked runs" - https://sciter.com/tokenizer-mark-syntax-colorizer/
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.
[+] [-] sam_goody|8 years ago|reply
Which is not surprising considering that Windows itself does the same thing [2] (hence, my not using Windows).
Even if they allowed us to opt-out of telemetry now, I wouldn't trust them not to silently opt us back in later.
This is not something I can accept my editor doing, and would expect a little less apathy about it from the HN crowd.
Does anyone know more about the MS spyware and how much I need to worry about it?
[1] https://github.com/Microsoft/vscode/issues/16131 [2] https://arstechnica.com/information-technology/2015/08/even-...
[+] [-] baldfat|8 years ago|reply
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.
From 2016 > today we continue to send events stating that a user has opted out and nothing else i.e. no usage data is sent. Here is the test to ensure that is all we send... https://github.com/Microsoft/vscode/blob/master/src/vs/platf...
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.
[+] [-] nolok|8 years ago|reply
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
[+] [-] hudo|8 years ago|reply
[+] [-] nickpeterson|8 years ago|reply
[+] [-] marijn|8 years ago|reply
[+] [-] kylestlb|8 years ago|reply
[+] [-] santaclaus|8 years ago|reply
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.