
VS Code Roadmap 2018 - madspindel
https://github.com/Microsoft/vscode/wiki/Roadmap
======
placebo
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...

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

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

~~~
ZenoArrow
Minor correction, the first BASIC was for the GE-235. The Altair was the first
home computer to have a version of BASIC, but BASIC had already been around
for a decade before it was ported over.

[https://en.m.wikipedia.org/wiki/GE-200_series](https://en.m.wikipedia.org/wiki/GE-200_series)

[https://en.m.wikipedia.org/wiki/BASIC](https://en.m.wikipedia.org/wiki/BASIC)

~~~
slededit
Meant the first MS Basic :)

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

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

~~~
dotancohen
> 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

~~~
dbmikus
I use Emacs, VIM, VS Code, and Eclipse, but they all need to have a VIM mode
enabled or I'm outta there! VS Code can actually use an embedded neovim
instance in its VIM mode for EX commands, which is pretty neat.

~~~
ake1
using it for actual editing is on it's way as well.

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

~~~
veidr
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
Why do people use desktop Slack? I always run it my browser, I just don't see
the value proposition of a native application?

~~~
mrweasel
Don't it get lost or closed by mistake all the time? To me much of the value
of a separate app is being able to cmd+tab between application and I
frequently just close my browser be get remove all windows and tabs.

I like the compartmentalisation of separate apps, but I doesn't really care if
it's written as an Electron app, as long as reacts fast enough.

~~~
Vinnl
Not OP, but my browser is open pretty much all the time, and pinning tabs
ensures they don't get lost.

~~~
teh_klev
So today I just learned you can pin tabs :)

~~~
Vinnl
Next lesson: you can switch to the n'th tab using Alt+<n> (or perhaps a
different modifier key depending on browser and OS). Since pinned tabs appear
on the left-hand side, that means you'll always have e.g. Alt+1 for email,
Alt+2 for calendar, etc.

(Nice and related is that you can do Super+<n> for window switching in at
least Windows and Ubuntu.)

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

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

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

~~~
sambeau
I've tried it and there is still a problem: the cursors draw from wherever the
previous cursor was. This makes it impossible to draw a line of cursors
vertically through your text without first placing a single cursor at either
the top of the bottom of where you want to draw the line. So instead of click-
drag (with a modifier key) you have to click-click-drag (with a modifier key).

~~~
Already__Taken
I do find the click-click drag annoying too.

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

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

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

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

~~~
iaml
iterm has terrible latency, you should try using alacritty - way faster.

~~~
phaedrix
Unfortunatley Alacritty has the same issues:

From Alacritty's FAQ: Q: "macOS + tmux + vim is slow! I thought this was
supposed to be fast! This appears to be an issue outside of terminal
emulators; either macOS has an IPC performance issue, or either tmux or vim
(or both) have a bug. This same issue can be seen in iTerm2 and Terminal.app.
I've found that if tmux is running on another machine which is connected to
Alacritty via SSH, this issue disappears. Actual throughput and rendering
performance are still better in Alacritty."

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

------
moomin
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
FWIW, Intellij IDEs have a builtin spell checker.

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

~~~
tstieff
It tends to work best with Java conventions, so camelCase spellings are
interpreted correctly, but other conventions - not so much.

~~~
moomin
And this is kind of my point: your spellchecker needs to interact with your
language server.

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

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

------
Vinnl
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...](https://zwabel.wordpress.com/2009/01/08/c-ide-evolution-from-syntax-
highlighting-to-semantic-highlighting/)

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

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

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

~~~
veidr
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](https://github.com/Microsoft/vscode/issues)

EDIT: there is one:
[https://github.com/Microsoft/vscode/issues/1927](https://github.com/Microsoft/vscode/issues/1927)

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

Unfortunately, not yet :(

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

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

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

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

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

------
segmondy
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
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...](https://sciter.com/htmlcss-desktop-ui-solutions-distribution-
sizes/)

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/](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
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](https://github.com/Microsoft/vscode/issues/16131)
[2] [https://arstechnica.com/information-
technology/2015/08/even-...](https://arstechnica.com/information-
technology/2015/08/even-when-told-not-to-windows-10-just-cant-stop-talking-to-
microsoft/)

~~~
hudo
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

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

~~~
mikewhy
Yep software analytics and blood diamonds are pretty equivalent.

~~~
jasonkostempski
Anything goes if it improves the product.

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

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

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

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

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

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

~~~
Rondom
Well, I do appreciate the service that distributions do. In Debian everything
has a manpage, even if upstream does not provide one and things install into
the right directories and integrate into the system well.

If for instance Chromium adds some phone home functionality, I trust that it
will be patched out...

The homebrew debacle has shown me that today's "open source" developers don't
care about their user's privacy.

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

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

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

~~~
chillee
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](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](https://github.com/Microsoft/vscode/pull/36690)
(it is my PR, for disclosure).

------
MatthewWilkes
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](https://github.com/Microsoft/vscode/issues/5953)

------
ng-user
I really want support for multiple monitors!

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

~~~
wvenable
Why does an editor need SFTP support?

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

~~~
Scarbutt
_Why does an editor need SFTP support?_

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

~~~
wvenable
Of course that's what he wants but I feel like putting that in the editor is
the wrong level of abstraction.

------
milin
Very interested in the language server protocol aspect of this.

~~~
type0
There's Sourcegraph editor based on it, although it's still in beta
[https://about.sourcegraph.com/products/editor/](https://about.sourcegraph.com/products/editor/)

------
carlsborg
This is a great python IDE for Linux.

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

~~~
reificator
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?

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

