
Keep VS Code from Becoming an IDE - bhalp1
https://dev.to/rpalo/keep-vs-code-from-becoming-an-ide-570l
======
alexdima
Hi, I'm a developer working on VS Code.

VS Code is architected in a way where extensions are not eagerly activated by
default. Each extension can declare a list of activation events, such as e.g.
opening a file of a certain language, invoking a specific command, starting
debugging, etc. See for example the quite long list of activation events for
our built-in TypeScript extension [1].

However, we also offer an activation event called ' * ', which means an
extension can ask to be activated on startup. Some over-eager extensions might
be using ' * ' to start up as soon as you open a VS Code window. You can find
those extensions at any time using F1 > Developer: Show Running Extensions
which will show the subset of extensions running at any time, and if they were
activated on startup or not.

Moreover, that view can guide you into profiling the extension host and can
help you easily figure out if any extension is consuming extensive CPU. This
was added quite recently [2].

[1]
[https://github.com/Microsoft/vscode/blob/1638acdd62d94bc4d99...](https://github.com/Microsoft/vscode/blob/1638acdd62d94bc4d991e8cab1d672260493f82f/extensions/typescript-
language-features/package.json#L30-L43)

[2] [https://code.visualstudio.com/updates/v1_19#_running-
extensi...](https://code.visualstudio.com/updates/v1_19#_running-extensions)

~~~
polskibus
VS code sometimes performs better than VS. Can you elaborate on the reasons?
Are there plans to migrate some optimizations or architectural lessons to VS?

~~~
Analemma_
Not a VSCode developer, but I imagine VS and VSCode are so completely
different under the hood that performances comparisons between the two are not
very useful. Not only are they architecturally completely separate animals,
but VS probably has a lot of legacy baggage that needs to stay for backwards
compatibility, which VSCode lacks.

------
RubenSandwich
I'm sorry but this headline doesn't reflect the content of the article. (The
linked article has the same headline.) The article is more about enabling VS
Code extentions by workspace in order to keep VS Code fast. The current
headline strikes me as clickbait.

~~~
jakear
Yeah, I read the headline as a call to action/complaint directed at VSCode
developers.

------
aphextron
>Some people like a big, heavy, comfy IDE. Some people like a light, zippy,
relatively simple text editor and a terminal window. And some people like
Emacs. We don't talk about them. (I'm joking, I'm sorry, I couldn't resist.)
I'm part of the zippy editor/terminal group.

I really, really, hate this often touted false dichotomy, and the smug sense
of superiority it engenders. Some people just use the _right tool for the
right job_. If I'm cranking out some bash scripts, of course I'll pop open
Vim. If I need to edit a CSS file real quick, I'll open up Sublime. If I'm
writing a new C# class to integrate with some large codebase based on a
complex library, for the love of god give me Visual Studio. If I'm debugging a
JSP stack trace in Java/Spring, I would hate my life without IntelliJ. People
who "personally identify" with their preferred tools and use/advocate them
zealously are idiots with narrow experience.

------
cup-of-tea
I honestly think if more people gave emacs a chance they'd find it's exactly
what they've always wanted.

~~~
Someone1234
I find my mouse too expressive to throw out.

emacs and vim have always had self imposed limitations by requiring that all
of the core features work on a remote terminal (with mouse being an after-
thought/optional extra). Sublime, VS Code, and even Visual Studio have no such
limitation so I'll keep using them.

Each to their own of course. :)

~~~
hartator
Exactly this. Vim key shortcuts are truly awesome, but most of the times,
mouse selection is just so superior, specially now with multicursors, column
selections, and live feedback.

~~~
z3t4
Do you have a demo on multicursor mouse selection !?

~~~
tomsmeding
That is most probably with a plugin; there are a number of plugins for vim
that provide varying amounts of multicursor support. I haven't found one yet,
though, that provides the amount of integration and speed that sublime text's
multicursor feature gives; in my experience, the relevant vim plugins work
mostly and are slow.

------
apetresc
I don't know anything about how VS Code is architected, but surely if language
support extensions are such a drag on performance, the plugin API has some way
to load them dynamically only when a project of the relevant type is opened,
right? Or does it really load every conceivable language plugin you have
installed into memory whenever you open a scratch file in VS Code?

~~~
coldacid
Apparently that is indeed what happens, but VS Code still needs to load each
active plugin's manifest and prepare hooks for when it'll be loaded. Still
nowhere as bad as actually loading them all.

There are still plenty of other extensions that provide language-specific
features that aren't language support, and those will end up getting loaded
every time if they aren't deactivated. I find it's still useful to keep those
installed and disabled by default, and only enable them for appropriate
workspaces. It does help with maintaining Code's great performance.

------
gildas
Isn't VS Code (without any extension installed) already an IDE? As far as I
know, I cannot disable the integrated NodeJS debugger or the integrated
terminal for example.

~~~
Sean1708
Except there's no real definition of what an IDE is, just a general gut
feeling that we mostly agree on. VS Code is one of the things that people
don't agree on, however, so some will say it is and some will say it isn't.

------
brightball
This is why I use two. I use Sublime for my "should always be fast"
because...it's always insanely fast but then use VS Code for more code-like
things.

~~~
rhodysurf
I have the same workflow. I prefer Sublime but the Go, Dart, and Python
plugins are too good in VSCode to give up for me.

------
sus_007
One can also install only an "Extension Pack" for a specific
language/framework on VSCode and enable the only extension pack (in stead of
going through each extension and disabling them) that he/she needs to work
with at the moment.

Like when I'm working with Django(Python) I only enable my Python Extension
Pack(has Jinja Templating & Django Snippets Support) whereas I only enable
Node Extension Pack while writing Javascript.

------
nuggien
So you do want an IDE, just not all of it all of the time? Headline is pretty
clickbait, sorry.

------
ryanpcmcquen
I always struggle with extensions. Often I just want to go completely
extension free (as I do with Vim and Emacs). But some extensions are too good.
A few that come to mind for VS Code are:

\- Prettier

\- Regex preview

------
zwieback
How much of that is a startup issue? My IDE sessions (VS, Eclipse, etc.)
usually last several days but then I'm still using a workstation 90% of the
time.

------
pikzel
If you want a "snappy editor", don't use one written as a web app.

~~~
jxub
I don't think that the issue lies there.

Look at the likes of Eclipse, not using Electron and way slower, while
offering a marginal increase in functionality compared to a customized VS Code
with plugins. Also, would you spend 5 hours each day in front of a Winforms or
Awt based usually ugly-ass editor?

The only negative side of going with Electron in the VS Code case is the size
increment that comes from bundling the chrome engine.

------
DrBazza
tl;dr disable all extensions, and enable the ones you _need_ on a per-
workspace basis.

~~~
ryanpcmcquen
The irony is, that this article is _very_ short.

