back to article Visual Studio Code 1.50 goes hard on extensions support, but tackling add-on bloat is becoming more onerous

Microsoft has released version 1.50 of the world's most popular code editor, Visual Studio Code, with enhancements to core features, richer extension support, accessibility improvements, and not forgetting a build that runs on Raspberry Pi. The VS Code team delivers an update every month like clockwork, confusingly named by …

  1. jemmyww

    I started tackling the bloat early on. Every extension I add I immediately disable and then enable for the workspace. And disable extension auto updates because you don't want them interrupting when you're working.

    1. drkvogel
  2. Ross 12

    "If anything can impede the growing popularity of VS Code, it will be when the number and sophistication of its many extensions become a burden."

    Ahh yes, the Firefox trap.

  3. Fruit and Nutcase Silver badge


    "but the editor is also in the habit of inviting developers to install further extensions when it thinks they might be useful"

    1. fidodogbreath

      Re: Clippy!

      >blip< "It looks like you want to fill up your system drive and make your work environment more annoying. I can help."

  4. Howard Sway Silver badge

    greeted by a flurry of messages from extensions demanding updates

    One day soon we will pass the Install Update event horizon, whereby actual computing work will become impossible due to not being able to install every available update before even newer versions of the first thing in the update list become available.

  5. Anonymous Coward
    Anonymous Coward

    Don't blame the extensions...

    ... Visual Studio Code is bloated to begin with.

    What kind of world are we living in where a text editor with a 200MB install footprint is considered lightweight? (And yes, I know it's built on Electron and that explains why. That's no excuse though.)

    1. J27

      Re: Don't blame the extensions...

      Welcome to 2020. Most IDEs are at least 4GB, that's what makes it "lightweight".

    2. Alan Bourke

      Re: Don't blame the extensions...

      200MB is peanuts in 2020.

      1. Wempy

        Re: Don't blame the extensions...

        % ls -lh $(which vim)

        -rwxr-xr-x 1 root wheel 2.1M Sep 22 01:29 /usr/bin/vim

        Just saying...

        1. Munchausen's proxy

          Re: Don't blame the extensions...

          -rwxr-xr-x 1 root root 6.2K Apr 8 2020 /usr/bin/geany

    3. bombastic bob Silver badge

      Re: Don't blame the extensions...

      the fact that it uses Node.JS is bad enough, but when i played with it early on it was ALL 2D FLATTY FLATSO FLATASS (instead of 3D Skeuomorphic) and I _REALLY_ hate that. Nevermind the inherent slowness of JAVASCRIPT.

      (this is why I stiil use DevStudio 2010 for C/C++ on Windows, which is happening less and less often these days anyway...)

      From the art6icle: Is there anything that can disrupt it?

      Yes. Micros~1 bloat. When a JAVASCRIPT EDITOR ultimately takes A MINUTE (or more) to load (give them some time, it'll happen), because of all of the bloat and extensions and 'did I mention bloat', performance goes out the window, and this is the problem Eclipse and InteliJ (which are actual JAVA, which is better) and other non-native-compiiled editors have had. That, and a potential "must have 16Gb of free RAM available or it won't even load" [do not doubt me, if unchecked, this is coming, we've seen this trend before].

      I've DEFINITELY seen something like this with IntelliJ already, though not as bad as the 16Gb I suggested here. I think I managed to get IntelliJ to work acceptably with only 4G (or maybe 5G) for the VM that was running it by carefully tweeking its settings (unfortunately IntelliJ garbage collect memory MISmanagement is piggy, and Gradle made it worse). Later I allowed the VM to have 8G when I installed more RAM on my new workstation. And IntelliJ is compiled p-code Java, NOT JAVASCRIPT, which would be WORSE. So I have reason to make this future claim of hideous bloat and gluttonous memory hogging.

      Why not just make an open source C/C++ native compile editor that uses a commonly accepted toolkit like Qt or GTK or wxWidgets so that it PERORMS WELL on embedded systems, and can also use X11 remotely to display on a local computer which is what I've been doing with pluma for YEARS now... and before that, gedit [until gedit's interface turned into SUCK, but thanks to Mate, pluma was forked from its earlier version and improved]. (Of course, I've been working on my own for several years but I still need to earn money to live on, too... which is why it's not finished yet)

      1. Anonymous Coward
        Anonymous Coward

        Re: Don't blame the extensions...

        "Why not just make an open source C/C++ native compile editor that uses a commonly accepted toolkit like Qt or GTK or wxWidgets so that it PERORMS WELL on embedded systems, ..."

        Code::Blocks. As far as IDE's actually being executed on embedded systems, I've never seen the point as those are mostly proprietary traps (or just license stuff you have to deal with). I have no idea why you'd run Electron anything on a RPI, not unless you hate yourself or just think it's "cool".

        VS Code will always be the "slow kid" wearing an Electron shirt, but it has its usefulness. Or maybe better put, commercially focused software receiving free work from the young OSS developers has its spoils :-) ie. a very decent experience across Linux AND Win (I have to use both).

        Back in ~2002, before the "Java == Bad" ideology, I actually liked IntelliJ for about 2 years. However, at some point in ~2012 I tried it again it was... too much. I still like Eclipse, but while I'm not a blind Java hater, I still don't want JRE anything :-/ (just like I don't want Electron anything). So, today I stick with Code::Blocks or Kate and yes, VS Code for my Arduino "stuff" (although works well with Code::Blocks, but not Kate as far as I know).

        1. _LC_

          Re: Don't blame the extensions...

          Ever tried KDevelop (or QtCreator)? KDevelop has an AppImage download, which means that you can try out the newest version without having to install it.

          They both have a lot of perks that you don't get to see on first sight. Both are more complete than Visual Studio Code, while being a lot faster and light-weight.

        2. fidodogbreath

          Re: Don't blame the extensions...

          VS Code will always be the "slow kid" wearing an Electron shirt....

          I laughed out loud at that line. Please enjoy a beer.

      2. Maelstorm Bronze badge

        Re: Don't blame the extensions...

        Why not just make an open source C/C++ native compile editor that uses a commonly accepted toolkit like Qt or GTK or wxWidgets so that it PERORMS WELL on embedded systems...

        Beyond you, who runs an IDE on an embedded system? Everyone that I know does the work on a workstation, compiles the code with a cross-compiler, and then loads the image into the firmware. Unless of course your definition of embedded is different than mine.

    4. Charles Calthrop

      Re: Don't blame the extensions...

      A world which is not 1996

      I remember stripping spaces out of my xhtml so they would load faster, and fretting about image sizes for days

      That world has long gone. You may argue for better or worse, but it's irrlevant. It's gone and it is not coming back. Neither is the world where we use floppys, or worry about 200mb install files.

  6. Maelstorm Bronze badge

    So many things....

    I've read some of the comments on here and I do agree with many of them. Visual Studio Code's 251MB install footprint is actually lightweight, considering that the full Visual Studio takes 6.01GB over 47,762 files and 9464 folders. Android Studio is worse. The IDE components take 1.59GB while the SDKs take up a whopping 126GB in 223,563 files and 28,057 folders. It likes to shove extensions down your throat based on the files that you are editing. I use a few based on the work that I do. One that I have found very useful is the vim extension. It has it's issues like everything else, but since I do a lot of work in a Unix environment using vi, it makes it easier to switch platforms between Unix and Windows.

    VS Code: Beyond it's issues, it's a nice little editor that's lightweight, loads fast, and generally well behaved.

  7. Anonymous Coward
    Anonymous Coward

    I don't know about other languages but for C/C++ on linux..

    ... it brings nothing to the table over simply using the command line tools in a terminal (since it simply uses gcc and gdb underneath) other than slightly quicker look up of definitions and values, which for me isn't enough to put up with its sluggish performance and over complicated GUI. I'm far more productive with 4 terminals open for search, edit, build, run & debug. But I guess I'm just old school.

    1. _LC_

      Re: I don't know about other languages but for C/C++ on linux..

      That is silly.

      I can't even begin to describe all the helpful features of KDevelop (or QtCreator).

      See my post from above:

      1. Anonymous Coward
        Anonymous Coward

        Re: I don't know about other languages but for C/C++ on linux..

        Well try and begin describing them because neither of your posts bother. Do they provide any more debugging info or stepping ability over and above gdb? Any better compiler errors than provided by gcc? Is the editor any better than all the others available? No? Then I'm not interested. I want functionality, not pretty colours and cutesy icons.

        1. _LC_

          Re: I don't know about other languages but for C/C++ on linux..

          Are you trying to tell me that running the compiler from the shell and picking up the error lines from there, then going to the editor and manually entering the line numbers to go to, is an advantage?

          You sound like a troll. Starve. :-P

          1. Anonymous Coward

            Re: I don't know about other languages but for C/C++ on linux..

            Perhaps give it a try sonny then you'll understand. What do you think we did before IDEs turned up?

            And yes, it is an advantage because the shell has 101 other tools you can use too such as tracers, profilers, library decoders etc not that you'd probably know about any of them.

            I notice you didn't answer the question btw.

  8. Adrian 4

    if only ..

    .. there was an editor that was only eight megs, even if that did mean it was constantly swapping.

    1. NetBlackOps

      Re: if only ..

      Notepad++ is still used here when I don't need anything fancy save the usual syntax sugar and brace matching (e.g. C-family of code) clocks in at 9 MB total. Like boltar, the rest is done through various shells, tools, and the ever present makefile.

      Not to say I don't use bigger hammers, I do. Updating Visual Studio 2019 as I type.

POST COMMENT House rules

Not a member of The Register? Create a new account here.

  • Enter your comment

  • Add an icon

Anonymous cowards cannot choose their icon

Other stories you might like