VS Code Roadmap 2018

https://github.com/Microsoft/vscode/wiki/Roadmap

by madspindel • 9 years ago

360 230 9 years ago

veidr5• 9 years ago

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.

crispinb2• 9 years ago

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.

manyxcxi• 9 years ago

I’m not monogamous with my code editors

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.

dotancohen2• 9 years ago

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".

:wq

isthisnagee• 9 years ago

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.

dmitriid8• 9 years ago

For me ”marrying to an editor” is mostly about muscle memory. Onve you know all tje shortcuts, you are much more productive

antjanus• 9 years ago

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.

jeffisabelle• 9 years ago

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.

merlish2• 9 years ago

Re. a single editor: The constant, never-ending search for The Perfect Editor :)

ssijak4• 9 years ago

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.

veidr5• 9 years ago

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.

davedx• 9 years ago

Why do people use desktop Slack? I always run it my browser, I just don't see the value proposition of a native application?

atomi• 9 years ago

I can see that if you close your editor often. I don't.

By the way checkout GitLens on VS Code.

spinningarrow2• 9 years ago

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).

drdaeman• 9 years ago

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)

merlish2• 9 years ago

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.

hasenj• 9 years ago

Why is Slack being an Electron-based app more tolerable? I find it absurd that you need a whole browser to make a chat app.

ssijak4• 9 years ago

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.

xfer• 9 years ago

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.

SaturateDK• 9 years ago

177 MB for me, right now. However that's just the windows task manager, so it's properly not accurate.

ssijak4• 9 years ago

Here is a hint of performance

https://blog.xinhong.me/post/sublime-text-vs-vscode-vs-atom-...

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.

yodsanklai• 9 years ago

Electron base still ruined it for me

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...).

Sean17082• 9 years ago

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.

pjc50• 9 years ago

Well, the regular Visual Studio is a native app and has terrible performance and memory usage too.

(joking but also serious)

m_fayer2• 9 years ago

The regular Visual Studio uses about the same amount of memory as VSCode while being an order of magnitude more complex and feature-rich.

EpicEng• 9 years ago

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.

wvenable3• 9 years ago

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.

Shorel3• 9 years ago

Quoting myself:

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.

dmitriid8• 9 years ago

My sole wish for VS Code is multiline errors and warnings, as more languages adopt properly formatted errors (like Elm and Reason)

veidr5• 9 years ago

If that is really your sole wish, you should really file an issue[1] if you haven't already.

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

dmitriid8• 9 years ago

Yup, that’s the issue :) I even asked if it could be bumped up in priority.

Unfortunately, not yet :(

pbiggar5• 9 years ago

In Elm mode, when you're on an error, you can get the whole error to pop up.

dmitriid8• 9 years ago

That’s the thing. You have to hover your mouse over errors etc.

drej• 9 years ago

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.

Good luck to everyone on the VS Code team.

pbiggar5• 9 years ago

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.

slimsag• 9 years ago

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?

nerdponx2• 9 years ago

Vim can be really slow with too many plugins running.

pbiggar5• 9 years ago

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.

pjmlp3• 9 years ago

It is surely faster than Atom, but not on the same league as sublime, emacs or vim.

sandos• 9 years ago

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!

barrkel4• 9 years ago

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.

chuckdries• 9 years ago

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.

StevePerkins• 9 years ago

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.

baldfat5• 9 years ago

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.

Tehnix3• 9 years ago

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 :/

moomin2• 9 years ago

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.

calcifer• 9 years ago

FWIW, Intellij IDEs have a builtin spell checker.

kasparsklavins• 9 years ago

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.

rvern• 9 years ago

GNOME Builder uses gspell: https://wiki.gnome.org/Projects/gspell.

gadders2• 9 years ago

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.

dingo_bat• 9 years ago

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.

gadders2• 9 years ago

Oh yes, I don't disagree. I think it would be good if they could at least do a "light QA" for trusted corporations - MS, Google etc.

And no devs at the corps I've worked at (big banks) have Macbooks for coding. If they do, it will just be connecting to a VM somewhere.

sjellis• 9 years ago

"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.

pjmlp3• 9 years ago

There are enterprise solutions for macOS management.

carlsborg• 9 years ago

This is a great python IDE for Linux.

baldfat5• 9 years ago

I wouldn't say its an IDE it just a really powerful editor and the RUN plugin is awesome.

reificator• 9 years ago

You've got an editor, a task runner to handle builds, a debugger, code completion, what else do you need to call it an IDE?

sambeau5• 9 years ago

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)

chrismbarr• 9 years ago

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!

Already__Taken3• 9 years ago

shift+alt click seems to behave just like sublime does, I left sublime a long time ago, I'm not sure what you're trying to describe there?

Do you mean because it selects the rectangle? Just hit an arrow key.

jameshart• 9 years ago

Right- or ‘end’ to get cursors onto the end of every line

sambeau5• 9 years ago

Last I tried you couldn't scrape down the right side of the ragged edge. I'll try it out again as maybe it's fixed.

I also found the 'extra' cursors too faint previously. Hopefully that's been improved too.

I'll give it a go as there's so much to like about it.

alexdima• 9 years ago

Hi, I'm a VS Code developer.

Can you please open a new issue and describe "as you would to a five year old" what's not working as expected.

Even from reading this comment thread I simply don't get it, so it might be something very easy to fix, once I do understand what it's about.

Thank you for your patience! :)

sambeau5• 9 years ago

Whoop! Would love to—thanks for your time :)

sam_goody• 9 years ago

I really want to try VSCode, but it sends data to Microsoft even with Telemetry et al off [1].

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-...

hudo• 9 years ago

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

jasonkostempski3• 9 years ago

Most people don't care that obtaining "real" diamonds gets people killed, doesn't make it OK.

baldfat5• 9 years ago

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.

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• 9 years ago

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

arcticfox• 9 years ago

Does anyone know more about the MS spyware and how much I need to worry about it?

Actually the project is open source, so rather than FUD up the conversation:

https://github.com/Microsoft/vscode/blob/master/src/vs/platf...

jasonkostempski3• 9 years ago

This line alone shows how they don't even grasp the concept of opt-in:

this._userOptIn = typeof config.userOptIn === 'undefined' ? true : config.userOptIn;

https://github.com/Microsoft/vscode/blob/b0a7b57d46a2dc1bafe...

mrweasel2• 9 years ago

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.

baldfat5• 9 years ago

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.

djur• 9 years ago

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.

nojvek3• 9 years ago

Their roadmap says they are working on settings ui improvements. I look forward to that.

SippinLean• 9 years ago

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.

SiVal2• 9 years ago

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.

Now there's a stretch goal....

vanderZwan• 9 years ago

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?

SiVal2• 9 years ago

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.

omaranto2• 9 years ago

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.

rkachowski• 9 years ago

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.

giancarlostoro• 9 years ago

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.

marijn• 9 years ago

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.

placebo2• 9 years ago

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...

D_Guidi• 9 years ago

MS biz is azure-based, so I think the worse can happen is to ship vscode with integrated azure tools...

sz4kerto• 9 years ago

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.

Vinnl6• 9 years ago

some don't like the electron-based thing/performance

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.

balefrost2• 9 years ago

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.

bobajeff• 9 years ago

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.

albertgoeswoof• 9 years ago

It's about getting developers back on the MS platform.

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.

bunderbunder2• 9 years ago

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.

pacala• 9 years ago

Makes it really easy to use Azure services.

chmln• 9 years ago

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.

See https://pavelfatin.com/typing-with-pleasure/ if you're curious.

DigitalJack• 9 years ago

I just checked on my win7 box. it's about 80ms. Typing in this reply is about 54ms. Notepad was 67ms. All that is like +/- 8ms.

lucky for me it's all unnoticeable.

WorldMaker• 9 years ago

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.

slededit2• 9 years ago

Minor correction, the first BASIC was for the MITS Altair 8800 which had an Intel 8080 CPU.

gwking• 9 years ago

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.

billti• 9 years ago

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.

https://github.com/microsoft/typescript/issues?utf8=%E2%9C%9...

z3t4• 9 years ago

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 !?

Franciscouzo• 9 years ago

Minor nitpick, but Chrome has never been Open Source. Sure, it's mostly Chromium, but the point still stands.

placebo2• 9 years ago

True. VSCode is more open source in this sense. Of course, that doesn't mean everyone is happy... https://github.com/Microsoft/vscode/issues/17996

Vinnl6• 9 years ago

It's (unfortunately but understandably) marked as a stretch goal, but semantic colouring sounds really nice. I first came across the idea in this post about KDevelop: https://zwabel.wordpress.com/2009/01/08/c-ide-evolution-from...

deburo• 9 years ago

What's the main idea behind this?

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.

Vinnl6• 9 years ago

The most compelling feature to me is that it can give different variables a different colour.

ng-user• 9 years ago

I really want support for multiple monitors!

nickpeterson• 9 years ago

Check out the Ionide plugin for Fsharp on VSCode, it's really good and improves at a breakneck pace.

milin• 9 years ago

Very interested in the language server protocol aspect of this.

type0• 9 years ago

There's Sourcegraph editor based on it, although it's still in beta https://about.sourcegraph.com/products/editor/

jclay• 9 years ago

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.

nojvek3• 9 years ago

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.

kylestlb2• 9 years ago

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?

santaclaus• 9 years ago

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.

wyldfire• 9 years ago

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).

chillee4• 9 years ago

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

If we wanted to keep it in the input box that pops up, we would need something along these lines: https://github.com/Microsoft/vscode/pull/36690 (it is my PR, for disclosure).

fulldecent• 9 years ago

Still no first-class SFTP support. Doesn't look like I'll try VS Code until at least 2019.

wvenable3• 9 years ago

Why does an editor need SFTP support?

Is this similar to Zawinski's law of software denvelopment?

Scarbutt• 9 years ago

Why does an editor need SFTP support?

Maybe he wants remote editing support, which is a nice a feature for an editor to have.

chillee4• 9 years ago

Is "Continue to invest into API that enables remote development" not what you want?

clintonwoo• 9 years ago

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.

MatthewWilkes• 9 years ago

Very sad to see that printing isn't on the roadmap for next year.

If others want this feature, it's tracked in https://github.com/Microsoft/vscode/issues/5953

segmondy2• 9 years ago

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.

c-smile• 9 years ago

Just in case (Sciter's author is here):

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.

susankim• 9 years ago

The regular Visual Studio uses about the same amount of memory as VSCode while being an order of magnitude more complex and feature-rich.

borplk• 9 years ago

My number one feature request for VS Code is the ability to detach multiple windows and move them around on multiple monitors.

For example I want the project sidebar thing to sit on a separate monitor.

Would be really nice.

ausjke• 9 years ago

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.

VS Code Roadmap 2018

Related Stories