Live data from Hacker News

The Era of Visual Studio Code

blog.robenkleene.com

51–60 of 698 posts

Re: The Era of Visual Studio Code

#51
post #36

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…

JetBrains is and always has been amazing, but I like VS Code mainly because I'm accustomed to Visual Studio which is a huge bloated mess, especially inside a VM. For me it's quite an improvement. I mainly do C# back end stuff, so YMMV. I'm sure C# is a first class language for VS Code.

VS 2019 without ReSharper does not feel bloated at all.

Re: The Era of Visual Studio Code

#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 same time.

I use this setup primarily to have at least some sort of a barrier between my system and the gigabytes of NPM packages that get downloaded as dependencies. Moving between systems easy as well - I just copy the VM images. It also makes it easy to experiment a little bit. If I want to e.g. upgrade an important package and something goes wrong, I just revert the VM and I'm back in business. Having Arch as the distro is a nice bonus.

There's a chance that IntelliJ IDEs will get the same remote functionality as well but the timeline is unclear [1].

[0] https://code.visualstudio.com/docs/remote/remote-overview

[1] https://youtrack.jetbrains.com/issue/IDEA-226455

Re: The Era of Visual Studio Code

#53

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…

I have to reinstall PlatformIO every time I use the program.

It only takes a second but its absolute madness.

Re: The Era of Visual Studio Code

#54
post #9

VS Code is awesome. If you told me ten years ago my daily driver text editor on Linux would be a Microsoft product, well, you’d have been right. Sane defaults. Snappy interface. Universal UI on multiple OSes that doesn’t suck. First class and best in class TypeScript support. It’s going to be hard to beat, now or five years from now.

It's good for JS. It's ok for Golang, since there doesn't seem to be anything better that's free. But I still feel it's an editor trying to be IDE. I love it for markdown/asciidoc though.

Using NVim with go-vim, disabled gopls instead using gopls from native lsp. I am fine with that combo.

Markdown on Vim requires fiddling with formatoptions but combined with live :MarkdownPreview in the browser while you type in Vim is fine and displays mermaid among many other markdown extensions.

Re: The Era of Visual Studio Code

#55

I pay for a personal subscription to the JetBrains suite, use IntelliJ and PyCharm all day, and have also used Visual Studio all day in the recent past. The combination of modern IDEs with modern hardware is pretty awesome. My use of Emacs fluctuates depending on the job, language, environment, etc. but I've mostly used it for Org mode and a scratch pad since I signed up for JetBrains. That said, I tried Nova from Pa…

I use JetBrains suite as well. If only they could offer ONE IDE that is configurable to be used on many programming languages. Having many different binaries is a pita.

Re: The Era of Visual Studio Code

#56

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.

It has the rendering engine of a browser and that also has some advantages in rendering capabilities. Browsers are really good at rendering rich text, it's what they were designed for, and a native editor can't beat that. There's the occasional big text file that I have to open, in which case Vim would do a better job. But usually VS Code has no performance issues for me.

Me as a Vim fan I thibk its save to say that even vim doesn't handle large files well and is especially bad with files containing long lines.

Re: The Era of Visual Studio Code

#57
The UI is an absolute mess.

"Check for updates" immediately shows "Downloading updates". That's not what I expected. How about some confirmation?

Start a .NET project and you see "Downloading package 'OmniSharp for OSX' (49713 KB)", "Downloading package 'Razor Language Server (macOS / x64)' (51227 KB)". No prompt. Just starts downloading 100MB of deps.

For some reason the Output tab down the bottom has 20 options in a dropdown menu to switch to different outputs ("Github Authentication", ".NET Test Log", "OmniSharp Log"). I'm not sure why I care about any of these - if I do, why are they hidden in a dropdown menu?

F# gets its own icon on the left menu for some reason.

"Accounts" in the left menu has a notification badge with a count of 1 because I'm not signed in to sync my settings.

The settings icon on the left brings up a menu of 12 different options, some of which launch a settings editor, some launch a pre-defined search of extensions, another pops up a modal dialog.

In a .NET project, if I "Start Debugging", it opens a launch.json and in a comment tells me "Use IntelliSense to learn about possible attributes", making me define my own launch configuration instead of a default

Re: The Era of Visual Studio Code

#58
post #7

If VS Code is an endpoint to incremental improvements in text editing, then the next big thing that appears will involve a revolutionary approach.

Text editing is mostly a solved problem, and arguably done better elsewhere. VS Code makes improvements on interacting with particular languages / DSLs.

better elsewhere

Like in unix tools or other text editors?

Re: The Era of Visual Studio Code

#59
post #42

For those that like Vim, but also like some of the features that VS Code offers, but do not like VS Code itself and/or its Vim integrations or emulations, I must heartily recommend coc.nvim [0]. It's like using a modern IDE, minus the bloat and anti-features which make most of them (including, of course, VS Code) painful to use. [0] - https://github.com/neoclide/coc.nvim

ALE [0] is also nice if you just want a lightweight way to add linting / formatting / name lookups / autocompletion without a lot of extras.

It uses LSP for everything, and can apparently be used together with coc, although I'm not sure why you'd want both.

[0] https://github.com/dense-analysis/ale

Re: The Era of Visual Studio Code

#60
post #51
post #36

Earlier quoted context omitted.

JetBrains is and always has been amazing, but I like VS Code mainly because I'm accustomed to Visual Studio which is a huge bloated mess, especially inside a VM. For me it's quite an improvement. I mainly do C# back end stuff, so YMMV. I'm sure C# is a first class language for VS Code.

VS 2019 without ReSharper does not feel bloated at all.

I'm running VS2019 inside a VM on a Mac and it's horrendous, particularly compile times. It does feel normal on a proper Windows box though.
Post reply on HN