(Yes, I'm aware this makes me sound like an old man!)
I have used many IDEs.
I have never ever felt the need to use vim.
Is it fair to say, because VSCode does not have a "vim mode", it is somehow inferior as an editor?
I seriously don't get it. I have used VSCode almost from day one. It is a fantastic editor and quite a capable tool. I seriously love it.
Everyone can use it as its meant to be, a great tool platform that has a great community of plugins and support.
That said, VSCode is very good. But I don't believe in a web-based IDE and in remote Github repos. That's a recipe for disaster and unescapable vendor lock-in, and in any case it's only an option for web dev., really.
Edit: Since some people always take things literally: I have of course tried vim, like most people who ever worked with Unix/Linux I suppose, but never got beyond that. I am surprised that it seems to have become so "fashionable" lately. There are many alternatives to vi/vim and many IDEs. My experience is that vi has always suffered from its interface and has struggled to expand beyond "bearded Unix gurus"...
I personally tend to install micro, or use nano if that's not possible.
For dev. I use an graphical editor, usually VSCode these days. I used emacs at some point a long time ago.
The good thing with git and al is that there is no need to access a remote repo., and that's one of the points, so there is usually no need to edit source files remotely.
Extrapolating from personal experience, I think this might be down to Covid WFH where more people have had to ssh into remote machines and may need to edit files so might choose to use vim as it’s easily available. And vim is something that I find is better learned progressively where you pick up 1 or 2 tricks every week or something so those people might have been able to pick it up over the last year or so and are now evangelizing it.
I have also been WFH because of Covid but haven't had to change much or anything to my way of working and I do SSH to multiple machines every day. That might vary a lot from person to person, though. I have avoided doing actual dev. on a remote machine by setting up a VM to run Linux locally as any sort of remote desktop tends to be a pain.
Also, with distributed source control (git and friends) there is usually no need to access remote source files.
Want to have your mind blown? Microsoft (yes that Microsoft) officially supports remote development on Windows Server via SSH. As in, run vscode on your Linux box, create an SSH remote on your Windows Server, develop remotely on the server via SSH. Fully supported.
I was excited for this as a way to avoid touching Windows altogether, but it works pretty crappily in my experience.
See this plugin here: https://github.com/VSCodeVim/Vim
It works surprisingly well.
I also enjoy the emulated plugins (vim-surround mostly).
Is VSCode an inferior editor compared to Vim/Neovim? Absolutely, it is. Is Vim/NeoVim an inferior IDE experience compared to VSCode despite the ongoing evangelism by NeoVim fundamentalists? Most likely, yes.
Here's an example before I start getting flak — NeoVim doesn't have stable indent visualization lines and stable and sensible code folding support. Try writing serious Markdown documentation or Python code in NeoVim and then in VSCode.
The NeoVim website also mentions that being like an IDE is not one of its goals.
I already know the responses I'm gonna get - it's open source, submit patches or shut up, it's personal taste, those features are irrelevant etc etc.
> I seriously don't get it. I have used VSCode almost from day one. It is a fantastic editor and quite a capable tool. I seriously love it.
You should keep using it. Don't get swayed by people proselytising Neovim.
I've written a lot of C, a lot of scripting languages, and a bit of C++. I've used many IDEs.
For me, the "command line" workflow of Makefiles, vim & gdb are really, well, great. When I was a graduate student, I did a lot of pair-programming with a vim wizard who showed me just how insanely fast one can be with it -- it's small, but extensible. Sufficiently intelligent that you can open a 10 GB+ text file in it, jump to a certain line, make a change and exit; all before VS/VSCode would have opened. It's an add on to an IDE. Sometimes, for me, it replaces it.
I've never ever felt the need to use VS, or VSCode. I know other devs love VS for C++, but I love vim – VS feels like a big, bloated IDE where you have to memorise the location of 4e6 different GUI positions and take your hands continually off the keyboard to do anything. Intellisense (and, to a lesser extent, Windows as a whole) deeply irritates me. Vim has a weird, esoteric language with a learning cliff rather than a learning curve -- but I've used it almost from day one. It lets me feel incredibly powerful; it's light, yet has more features than I will ever need.
You and I are different. We've got different interests, different application areas in mind, and different preferences for how to write code and debug it. And that's okay! The key to being productive is accepting that people are different, work differently under different circumstances, and have different strengths, skills, and preferences. It's much better to be accommodating of them, rather than stifle them, and leave a proportion of your staff frustrated.
I'm just very slightly peeved that your preferences are being chosen by Github as a defacto default $EDITOR, but that there is no option whatsoever for mine – despite the fact that javascript vim / emacs "modes" are recognised as being almost religious, with highly developed FOSS javascript libraries nearly offering both keybindings and an implementation for either editor at a click of a button [e.g. 1] that have been around for >10 years.
On top of that, I can't help but notice that Github is usually very accommodating with individual developers' preferences -- to the extent there are often multiple ways of doing things as a result. The fact that, now, both Github and VSCode are both Microsoft products -- and that Microsoft famously likes people to use its "infrastructure", which is often orthogonal to the rest of the world -- just makes a little tiny bit of me feel like this is a change being pushed upon us, as originally explained in their "Embrace, Extend, Extinguish" strategy. I get it, it's a neat feature in beta, and it'll directly benefit some large proportion of their users. But if they're going to deploy fully equipped editors to the web, I'd like to have the ability to chose mine -- and give you the freedom to choose yours. I can't help but think that if this feature was developed prior to their acquisition by Microsoft, it wouldn't be VSCode that was deployed.
it sounds like you are completely ignoring the command palette, which allows for a quick, keyboard-only way of interacting with VS Code. have you given it a chance?
This one sentence convinces me that you have not used VSCode in any meaningful way.
I ditched GUI items for getting stuff done long time ago with VSCode. I just bring up the command palette and type away. Its insanely great.
When I tried VS Code, it wasn't even possible to hide the tabs. As a long-time user of Emacs and highly-configurable X window managers, the inability to remove useless graphical elements like tabs made VS Code unbearable.
Also, Command Palette? Heard of it?
There’s also a “code” command that will open a file or directory in VS Code.
- VSCode Remoting is really useful. It doesn’t suffer as much from latency as SSH or display forwarding, and lets you use some local configuration when remoting. Neovim will soon have a feature like this.
- Language servers for code intelligence has greatly improved editor support for languages. Up until the introduction and adoption of LSP, which was practically an invention of VSCode, language support was significantly more hit-or-miss with most editors. Basically only IntelliJ IDEA could do similar code intelligence across many languages. Because of LSP though, more editors and more languages can participate in inline documentation, go to symbol, errors as you type, debugging, etc. for example, many people now use language servers with Vim, and you can see useful integrations for languages like Terraform/Hashicorp HCL.
- The extensions ecosystem: it isn’t necessarily the greatest ever, but it is very solid.
- Compared to many IDEs, it remains lightweight and fast to boot. Though I’m not complaining, (regular) Visual Studio and IntelliJ are too useful to ignore in some cases.
- Unification: because it’s so versatile, across OSes, across runtimes, over remoting, over Code Spaces, you can buy into the ecosystem in your projects. You can tell Code Spaces what extensions to install and what commands to run, to try to build a nice environment. You can tell desktop VS Code what extensions are recommended, add workspace configuration to help improve the workflow. Users still can use other editors, and you can still include editor information for those editors too. But, for someone who just wants a good option to edit a specific project, pushing them towards VS Code is a really safe bet.
To be clear it has some issues too:
- There is no equally useable OSS version, as the Microsoft distribution has become more dependent on services and blobs.
- It’s not as quick and responsive as something like Sublime Text or vim.
… but honestly, I think it’s just great. If I was a new programmer again and I could jump right into projects and immediately begin working on them without having to figure out the rigmarole of version control, tool chains, build system and editor config, that would be amazing. For that reason I think Code Spaces and VSCode are net goods, though I think we ought not become too dependent on the specific solution. VSCode is never going to be the perfect editor for any specific use, but I believe overall it is usually a great editor.
The flipside is that MS pouring money into VS Code has tremendously benefited the entire code editor ecosystem, including (especially) FOSS editors that can reuse their language servers.
An example is the Python language server
https://github.com/microsoft/pylance-release
They base it 90% on the open-source pyright library. Then the lock down all their own enhancements.
https://github.com/microsoft/pyright
This is why MIT isn't always the correct choice. GPL wouldn't hurt devs at all and would protect from this kind of garbage from MS.
But would it protect against Pylance existing, or would it just be more expensive to develop but still proprietary (and possibly not free-as-in-beer), or would it be Free?
There's only one of those three where devs (as opposed to Free Software ideologues) win, and one where both lose.
(And really, it would do none of those, since pyright is also owned by MS, so they could reuse it on any terms even if the owner [them] offered it to others only under GPL terms. All GPL would do is prevent someone else from competing with Pylance by taking pyright and building similar functionality on top, possibly with a still-Free license.)
This attitude of MIT being bad because it gives people freedom to do Bad Things™ really makes me question what open source is actually about (yes I know that it's complicated and means many things, that's not what I'm talking about here). It seems to me that some proponents of it really believe in it so they can tell other people what to do.
"Some", perhaps. But this is a really disingenuous way to characterize open source.
MS could pay a dev team to write everything themselves, but it's a matter of cost. Given the choice between paying for a ground-up development for a tiny gain or using the open project, inertia would push toward the open project.
Finally, there's the question of trust.
Why does MS feel the need to lock these things down?
It's obvious now that "Open" was a hook. It killed off all the competitors like Atom or Brackets and even mostly killed off other editors like Sublime. The only question now is the final goal of their lock-in. The only real observation is that all of "the new MS that loves devs" was just more of the classic Microsoft we've known for decades.
So in your hypothetical, Microsoft not only uses the GPL instead of MIT outbound, but accepts contributions under the GPL instead of the CLA it uses for most MS open source project contributions, including pyright, inbound, etc.?
If they asked for people to sign over copyright for all contributions, they simply wouldn't get many takers because it would be transparent that the only reason to ask would be to close the source later.
How is that any less true when the outbound license is MIT, and, therefore, how is the fact that they get contributions with the CLA now not a firm disproof of that claim?
There's never a question of Microsoft's goal. It is always to destroy your choice to use non-Microsoft products. They pour resources into a "free" product that I will admit is good. It has to be, to kill all competing products over many years. Then when there is no reasonable competing product, they switch it to a paid product.
I can remember when Windows 3.1 was released. I did development on it at Ford, to emulate a vector graphics terminal. I remember when Office was bundled with Windows for free; now it is 1/3 of their revenue. I have seen Microsoft repeat this game over and over. History truly does repeat itself.
I suspect that open-sourcing in anything at all is essentially a long-term PR/marketing/recruiting investment, as well as as positioning Microsoft as the keepers and main developers of what has become an important standard.
That said, by "reuse" I mean that end-users are free to install the non-free binaries extracted from VS code, which interoperate with any text editor that implement a language client. They are all on NPM.
Check out VSCodium, similar to Chrome/Chromium, it's just VSCode minus all the related Microsoft stuff.
Yes, just clone? Most people who want other editors probably don't want browser-based ones.
I'm not sure if the VSCodeVim or VSCodeNeovim extensions work on the online version yet, but I'm sure some VSCode/GitHub engineers are on the case if not.
EDIT: VSCodeVim (the main "Vim" extension) does "work" on github.dev but the escape key doesn't, so as soon as you press "i" you're stuck in insert mode forever. https://github.com/VSCodeVim/Vim/issues/7005
xterm.js [1] is pretty good.
Something like gotty [2] and a engine for getting a container with a git checkout started should be relatively straight forward.
xterm-min-8.js
I forgot HN is not the place for humor, and I did not intend to cast any actual aspersions toward anyone maintaining cool projects.
These are at least 3 different questions:
1) Why should I use VS Code in general?
2) Why should I use VS Code online? (the articles topic)
3) Why should I use VS?
The answers might turn out completely different.
Personally, I have for my main languages (C++ & Python) full IDE's (VS & Wing IDE). For quick Python scripts, VSCode is considered an option that I use rather often.
In what VSCode shines is - as also other commenters mentioned - his plugin eco-sytem. This has true swiss-knife traits. So I'm using it for many secondary and ad-hoc technologies:
- CMake files
- Julia
- GPS files
- JS files
- LaTeX
- JSON
- XML
- CSS
- Markdown (vanilla, asciidoc, ReST)
- remote editing
VS Code is a decent text editor with a good plugin ecosystem. It's faster to start (if it doesn't have too many slow plugins) than most IDEs and easier to get used to than vi-based editors or EMACS. And unlike Sublime Text it's free. Unlike Notepad++ it's cross-platform.
I personally use CLion for C (as well as Markdown, CMake, and shell scripts that are part of the same project as the C), PyCharm for Python, DataGrip for SQL, and VS Code for various text tasks like log file analysis and quick note taking.
It's a handy editor, very useful for ad-hoc work but not really advantageous compared to a full IDE for most regular day-to-day work IMO.
But I did go from notepad, to eclipse, to ST, to vscode to JetBrains, so … obviously I’m trying to get into emacs now
I don’t ask my work to pay, because I use it personally as well, and I look at my brother as a woodworker and he’s honed his tools to what suits him.
I do the same.
It doesn't even come close. It's powerful but it's definitely not the same. I would go back to NetBeans before using VSCode. There's no religion behind it, it's just that there are tools that suit my needs better than others.
Considering nearly every S/W dev globally can make that in a couple of days, I'm not sure how much of a flex it is considering it would be your primary work tool.
And I say this as someone whose never used a Jetbrains tool and use Vim for nearly everything (except when I'm on Windows where I use a mix of Notepad++ and VSCode).
Sometimes you can afford it, and sometimes you can’t.
I think we forget when you could (and still can) do dev with a text editor.
I 100% get what you say, but that’s a lot of money potentially - which is where I think vscode /vim etc shine in that it’s free and can do the same kinda thing
This is only possibly true if your definition of "global" is "1st world".
Each to their own really, and honestly not every tool is going to be a good fit for every project. I have day work on Visual Studio that I wouldn't dream of moving to VSC for a bunch of reasons.
The reasons myself and others like VSC also have a lot to do with the plug-in ecosystem. More people using it means someone has likely already encountered my use case which means it's more likely a plugin exists to do what I need.
There are places that live on JetBrains for this reason (sprawling homogenous codebases that cross domains and languages). Having support to hand not only for the code you use most, but every language/framework other folks in your organisation use, is a really useful feature for integration/debugging work.
I would now feel uncomfortable using anything else.
It was so sleek and lightweight at first it was really a pleasure to use. But performance and bugs seem to increase, even if you don't use many or any plugins at all.
Devs with this many extensions are an OpSec/data governance nightmare!
VSCode desperately needs some sort of access policy/permission system for their extensions, and make it more obvious when an extension phones home code or other data its user doesn't directly provide it with.
Copilot, for example, straight up sends and uses your code - not just the modifications you've made to the laundered code it provides you with, but any or all of it [1].
It still has decent performance and I will continue using it. I think I have my linters correctly configured so there isn't any huge background scanning of files. But I have the impression the early versions were faster.
At least this way it makes sense, as a pure Web application.
It lacks some nice features and improvements that PHPStorm has, but it's pretty good overall. There are a couple things that NetBeans does better than PHPStorm, though.
IDEA is the same way. Turns out coding isn't about text input after all.
I guess I'm a pair programmer with Clippy now :-(
Does it load fast and offer the features I want? Yes. Within reason, that's all I care about. I don't know what the perfect codebase size is for you (4mb? 16kloc?), but if that matters to you I hope you get to use that product.
My main drivers are IntelliJ products (WebStorm, Rider, CLion, DataGrip...).
VSCode is just too sluggish for me.
I was thinking of something that would allow you to use any machine with a browser.
From there, you can run whatever terminal-based editor you want, or so the blog post about github.com development having moved to Codespaces tells me [2].
But for the lighter-weight web-based editor, it doesn't look like it. If you're a CLI person, you could browse using the GitHub CLI and clone repos from there to start editing; not as convenient as punching a single key to get from viewing in a browser to editing, though.
[1]: https://docs.github.com/en/codespaces/customizing-your-codes...
[2]: https://github.blog/2021-08-11-githubs-engineering-team-move...
Unfortunately I really doubt they'll ever offer alternate editors, especially given the technical challenges involved in embedding it in the browser, connecting it to whatever hosted environment it has, etc.
The best you might hope for is that they'll provide a terminal to the workspace, from which I could see text-based editors being available (in fact... I wonder if you could do that from VSCode's built-in terminal)
I should really just take the time to switch to VS Code and rip off the bandaid since I think it would make life easier in the long run.
Emacs will be around forever, but vscode will dominate.
Still have some hope that eventually it gets redone in React Native or something.
It is usable just not very good, yet.
And - I find the constant change in configurations very confusing, and the plugins also have scant documentation. I can tell 'what is installed' but not exactly how they work together.
Having tied out JetBrains after years away - I'm now permanently back in the IDE camp. For whatever reason they are now 'faster' and so the extra bulk of features comes pretty much for free, and they are just well optimized for whatever you're trying to do.
Java on VSCode is frankly full of little snags. C++ same.
VSCode is a handy go-to tool for quickly looking at code from any language.
For pilfering through some open-source Java, Dart, Rust, that little C project, Python ... the VS is it.
But for mainline projects, a good IDE is it.
1) When you alt-tab you lose dialog tooltip, I can't handle this, it should be a number one priority to fix this 2) A lot of languages just look plain ugly in VS Code, not so in Emacs for example, Vim w/e