Live data from Hacker News

The Era of Visual Studio Code

blog.robenkleene.com

111–120 of 698 posts

Re: The Era of Visual Studio Code

#111

I'm not a fan of VS Code because everything is a plugin. And plugins are inconsistent, buggy, inconsistently documented, hard to use and find and update and goodness knows who developed them. Plugins can be duplicated, outdated, abandoned and incompatible. But worst of all, a big pile of plugins isn't a consistent integrated product vision. I gave VSCode a solid go, and I had to keep installing plugin after plugin, b…

You don't need all the plugins. You just need a curated set. And some of the plugins are fantastically high quality. The Microsoft Python one is excellent, as is the Remote development one. I'm a fan of VS Code because in spite of it having a plug in system, there are great plug ins there. And that one single great plugin is all that is needed (for that specific purpose)

I'd be more interested in VSCode if Microsoft's strategy was to relentlessly implement the most popular plugins into VSCode natively such that the most commonly used and needed functions were built in and did not require plugins.

The problem with systems that are really just frameworks for other to build on is they become reluctant to build stuff that plugins exist for. The philosophy becomes to depend on the plugins rather than built out needed features. This entrenches the spaghetti pile of plugins.

Plugins are great and necessary - Jetbrains IDEs have plugins. The difference is a philosophical one - are plugins there to provide core functionality, or are they there to provide uncommon use cases? VSCode uses plugins for basics, JetBrains builds basics in - with JetBrains you can never install a plugin and happily work away. With VSCode, the very first task you must carry out is to start managing your inventory of plugins.

Re: The Era of Visual Studio Code

#112

Earlier quoted context omitted.

better elsewhere Like in unix tools or other text editors?

emacs and vim are super efficient, nearly infinite in keybindings, and fully programmable and extensible.

Except not doing ctrl-c ctrl-v easily. Or standard keybidings. I wonder if an offshoot with standard keys in a terminal based on vi would work (really simple and native, I used simple mode alas it almost were transparent but not quite. )

Re: The Era of Visual Studio Code

#113

Kind of a weird set of text editors in the article. I think the preferred tools depend highly on your language and environment. I'm guessing this is for the JS-frontend specialization mainly. If you did Java, C* etc. then the ubiquitous text editors/IDEs were not these ones. I have converted to VSCode because it just works and I don't have to mess with PATH or whatever. I run it on Windows, Linux and MacOS and it wor…

>I have converted to VSCode because it just works and I don't have to mess with PATH or whatever.

While I love VSCode and use it every day (mostly for markdown), I have definitely needed to play around with PATHs to get VSCode working nicely with my conda installs on both windows and mac (i.e. it never seems to actually point to the right python interpreter). No idea who is at fault here, but it seems to be a consistent problem for me.

Re: The Era of Visual Studio Code

#114
post #35

Earlier quoted context omitted.

My only problem with it is performance when you load large repos and occasionally large files because it is an Electron app eventually. I know the extension ecosystem has thrived just because it is Electron but I wish MS worked on a native editor to achieve it.

See, I don't think that's possible. VSCode only has 10 or so employees full time. I don't think they could make a good text editor with this kind of dev speed on 3 different platforms natively. Sublime is great but it updates once every other blue moon for a reason.

> Sublime is great but it updates once every other blue moon for a reason.

I like both editors (VSCode and Sublime) and just want to point out that Sublime Text 4 is in semi-public alpha. It is "semi-public" in the sense that the download link is given in the Discord channel, but anybody could join it.

For nine months or so, there has been a new release of ST4 every 2-3 weeks. Development is definitely ongoing (though I'm quite happy with ST3 as it is).

Re: The Era of Visual Studio Code

#115
post #70

I'm not a fan of VS Code because everything is a plugin. And plugins are inconsistent, buggy, inconsistently documented, hard to use and find and update and goodness knows who developed them. Plugins can be duplicated, outdated, abandoned and incompatible. But worst of all, a big pile of plugins isn't a consistent integrated product vision. I gave VSCode a solid go, and I had to keep installing plugin after plugin, b…

> It reminded me of using VIM as an IDE - not an IDE, a big pile of stuff that isn't integrated. I prefer to use Vim as a powerful editor, within Unix as my IDE.

same here, use it on the server and desktop, gave up on vscode one year ago, did not need my purchased jetbrains(webstorms etc) for 99% of the time.

vim rules for me, as a full IDE from the terminal.

Re: The Era of Visual Studio Code

#116

Earlier quoted context omitted.

You don't need all the plugins. You just need a curated set. And some of the plugins are fantastically high quality. The Microsoft Python one is excellent, as is the Remote development one. I'm a fan of VS Code because in spite of it having a plug in system, there are great plug ins there. And that one single great plugin is all that is needed (for that specific purpose)

I'd be more interested in VSCode if Microsoft's strategy was to relentlessly implement the most popular plugins into VSCode natively such that the most commonly used and needed functions were built in and did not require plugins. The problem with systems that are really just frameworks for other to build on is they become reluctant to build stuff that plugins exist for. The philosophy becomes to depend on the plugins…

No way, it sucks when you've got a monolith full of unnecessary gadgetry. Right now VSCode is already getting pretty bloated w/ builtins

Re: The Era of Visual Studio Code

#117
post #52

I completely switched to VS Code once I discovered the remote development feature [0]. It allows you to run VS Code locally but work on a project in a different environment (via SSH, Docker, WSL). The integration is seamless - search, debugger, terminal, extensions - everything looks and behaves as if it was running locally but is delegated to the configured remote. You can even have different remotes opened at the s…

Note that this feature doesn't work in open source builds of VSCode, it's an MS only thing.

I read about this fact elsewhere also. Could you expand on this a bit? My impression was that VSCode and its associated extensions are open source, so I'm curious how Microsoft could make certain parts exclusive to its own build of VSCode.

Re: The Era of Visual Studio Code

#118
VS Code is nice for green developers, however I always encourage finding a different editor. This helps encourage exploration, customization, and configuration. You will need to take the training wheels off sometime in your career.

Another reason to prefer other editors is they tend to stay out of your way. VS Code tries really hard to make you not even leave the window.

Anecdotally, a previous colleague once sold me on SublimeText. I had liked it and used the free version but VS Code was also free without pay. The colleague encouraged that it was better to buy a software sometimes (SublimeText license) than continue searching for a free solution for every tooling issue I had. It was the first time I was able to rework my reasoning as to why I should pay for software. The reasoning is simple: invest in yourself. This is more powerful than investing in an no-cost ecosystem to solve your problems.

Re: The Era of Visual Studio Code

#119
post #102
post #98

Earlier quoted context omitted.

This is such a hugely undervalued feature, and no other editors seem to provide anything remotely close. I found it particularly useful for the COVID work from home - I yeeted my work laptop into a corner and just SSH into it to continue working with the ergonomics of my home desktop machine.

Not to be that guy, but emacs has had this for years via tramp.

As someone who used tramp and switched to VS Code, it's absolutely not the same thing. The difference is plugins work on the remote side of the connection without having to be aware they're in a remote connection. VS Code makes this work by having an agent running on the remote host. For the first time I actually got autocomplete and code jumping working without a horrendous amount of effort.

Re: The Era of Visual Studio Code

#120

Earlier quoted context omitted.

You don't need all the plugins. You just need a curated set. And some of the plugins are fantastically high quality. The Microsoft Python one is excellent, as is the Remote development one. I'm a fan of VS Code because in spite of it having a plug in system, there are great plug ins there. And that one single great plugin is all that is needed (for that specific purpose)

Does VSCode have something similar to emacs’s spacemacs, doom or prelude?

are you asking if anyone implemented the 3d first person shooter DOOM inside of the vscode plugin system? that could be a summer of code project for some aspiring coder.
Post reply on HN