Given the talks from Microsoft's own React Native team regarding the 300x performance loss from Electron based apps, I am looking forward to the day it gets rewritten in React Native.
I'm looking forward to the day when you can have multiple windows open on the same project without going through some horrible kludge. Some of us (!) have more than one monitor and would like, say, to put the debug widgetry over on _this_ one.
Speaking of which, as a light user of VS Code, is anyone else completely confused by the project / workspace interface? I'm always confused as to what project or workspace I'm in and what file is associated with what workspace, and what mode I'm in. The UX could use some love with the onboarding experience.
Tried it, but I didn't like how single window seemed to work with the VCS detection. And I found it generally too messy to keep track of what files belonged to what project.
I just have a few vscode windows open in fullscreen on my laptop. So I just switch to whatever one I need to use at that time. It's never really more than 3 at a time.
I think there's a plugin for it but workspaces would be much more valuable to me if they weren't a file you saved. The idea, I assume, is something like "these 10 repos with these 15 plugins are how I deploy this project."
In the end due to its UX I think it's pretty useless. I do use it on BIG projects because sometimes vscode will update or barf and forget what I had open.
I mostly just do "open folders in workspace" then hope it never goes away.
Yes, and your video shows Electron at ~700% of UWP C++ while React Native for Windows is at ~200% of UWP C++. That means an Electron program's reference set is ~3x as large as a RNfW program's, not 300x.
I hate visual studio programs. They are always so slow, buggy, and when they crash, the program vanishes from the task manger but is still are running from the background, so you cannot kill it easily. Visual Studio is a crutch for real coding.
To be honest, when I first heard my colleague say they were using "visual studio code" to develop their Python apps I thought they were repurposing some Microsoft vb.net IDE and hacking it to mesh with Python
The same team that does a bulk of the "python" language service dev for VS Code did the main plugin for python development in Visual Studio. It was actually pretty good.
Text editing is mostly a solved problem, and arguably done better elsewhere. VS Code makes improvements on interacting with particular languages / DSLs.
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. )
> Except not doing ctrl-c ctrl-v easily. Or standard keybidings.
I used to think like that but imho when you learn Vim registers it totally makes sense, plus if you're using it in a terminal emulator you can use ctrl-shift-c ctrl-shift-v. Now about Emacs I don't have much experience, but Doom-Emacs and Spacemacs use the System's clipboard by default.
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.
I'm a long time Linux user/developer, and I've completely switched to it for C++ on Linux.
I've used vim and various simple text editors for a long time, but wow is VS Code nice. The Linux port of IntelliSense (at least for me) works more consistently than any of the of the code introspection tools plugins for vim I've tried. It works especially well if you're using CMake - it can pull all of the header paths out of the generated build system without you having to touch anything.
(using Microsoft's C++ plugin and the vector-of-bool CMake plugin (which Microsoft took over development for))
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).
(Not a sublime fanboy or anything, just curious) What kind of plugins do you use that aren't on sublime? I was reluctant earlier for the same reason, but after I installed sublime-lsp I didn't think I needed much more.
the electron overhead is fixed. if it has problems with large repos it wouldn't be due to electron. it would be due to vscode itself or some extension you are suing.
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.
> My only problem with it is performance when you load large repos and occasionally large files because it is an Electron app eventually.
Discovering & pre-loading hundreds of thousands of files is slow on native too. I'm not particularly pleased with how easily folks write off web platform tech as somehow being the source of problems or slowness.
The one complaint that does seem fair is that the memory usage can be high, because there's so much runtime to load.
Also, I just keep thinking about your ask here. You want a native editor. But it wouldn't be a native editor. It'd be a native Windows editor, a native Mac editor, a native Android editor, a native iOS editor, a native web editor, a native Gnome, a native KDE editor, &c &c; your preference seems to be that Microsoft have made at least 5 editors. I'm not sure how the plugin system could exist amid such a diverse amount of native runtimes.
For what it is worth, I have never experienced this issue on modern hardware, and I regularly work with a very large monorepo.
Perhaps it is my habit of opening a subset of the repo into the workspace rather than the whole thing (e.g. only the bottom 4 or 5 directory levels so there is at most only a few hundred files in the workspace - builds etc just run from the usual command line so not having the entire repo in the workspace is not an issue for my workflow) but I have been nothing apart from really happy with the performance and have never been found wanting more, apart from loading time but that only happens once or twice a week so I can live with that.
I use VS Code daily, and most of the time I have a single workspace open with everything in it, probably more than a thousand repos.
Checking now, the workspace contains ~3.7 million files. I have had no perceivable performance issues with the editor, it works like a champ. Granted I have a beefy machine, but VS Code has been a pleasure from my first impression. For my needs, it's a great development environment.
Recently I onboarded someone to set up remote SSH editing. It did require a few technical steps, but after that they were joyous to see how well it works - a "game changer" in their words, saving them a lot of time and effort.
Absolutely agree with the remote SSH being a game changer - it is seamless and works amazingly well.
Since the start of lockdown I've been using it to remote edit from my laptop into my dekstop still at the office and it has been a flawless experience.
Compared to laggy and visually-aliased remote desktop experience (I did this for a while a few years ago and I ended up feeling see-sick after a while), or the faff of remotely mounting disks, it has been utterly seamless.
People like to bash VS code performance, but try opening a 60MB JSON file in different editors on Windows for example.
Notepad doesn't even load and crashes, Sublime will takes minutes to even load the file, Notepad++ will be unusable as scrolling will take a few seconds, and in VS Code it opens immediately and you can seamlessly scroll to any one of the 600k lines without any delay.
fwiw, I have the opposite experience with JSON files and sublime vs. vscode. Sublime opens fast and seamless, VSCode basically ceases to operate while it struggles to figure out syntax highlighting of such a "massive" file. I have near barebones installs of both, I do not believe it's plugins nor settings related.
Ultimately VSCode is my daily driver but I use sublime3 when I need to do fluid text editing, anything column/multi-select based, regex replaces, or manipulating large files. VScode has those features but they feel slow and buggy in comparison.
there's a great but not well known editor for windows called EmEditor that has a strong emphasis on performance and large file support. afaik the author has a background in low level performance optimization from Intel. if you work with large csv and/or json files you want this editor - it's amazing!
Suzukawa Editor (Japanese shareware) is interesting project. It claims it's the best editor for huge gigantic file. It compares with EmEditor in official page and it performs unmatched performance.
I haven't used this because I have no chance to edit such gigantic files.
I can't agree on Notepad++. It is my go-to for opening very large log files and I've never noticed scrolling issues. I love VS Code but I've found notepad++ to be the better solution for 'read-only' situations (opening very large files, searching files / directories).
The "Aggressive development" point is what got me to switch to VSCode from Sublime. While most of my colleagues were switching to VSCode, I stuck with Sublime, after never fully jumping into Atom for performance reasons. However - and I'm assuming due to the open source nature of the platform, or the accessibility of JS vs Python, extensions were just higher quality on VSCode. I think the Go extension is maintained by Microsoft themselves. Very soon things just worked better in VSCode.
Microsoft is selling you into the IDE, in small portions. This is similar to the IBM approach with JAVA last decade(s?).
You install a "text editor" for simple things, like code completion. Before you realize you don't even know which compiler you are using or where it came from. You just press F5 and look at convenient break points. And somehow it only runs right on Azure :) the last one is a joke (for now?)
As a language popularity grows, it approaches the Java curve. Just like nobody who uses `npm` like (or know) maven, nobody using VS Code know about the old java IDEs, and how they become todays Java IDEs. Or how the React monolith is the same as the Java Monolith.
I guess people mixing up java and javascript in the 90s... just thad more, long term vision?
Which IDE? If you mean Visual Studio, that's a Windows only product and it's really only good for Windows specific development like C# and MSVC. If you do C# or C++ development on Windows or XBox then you're likely already using Visual Studio and the community edition is a free product for individual use or open source products.
If you mean some future IDE that MS is working on that they plan to evolve VS Code into, I don't see MS trying to sell macOS or Linux users a proprietary dev environment or toolchain. It's certainly possible but your post doesn't provide any justification for that position.
Sure, just like Visual Studio Code exists for macOS and Linux. My specific argument was Microsoft is unlikely to release a proprietary IDE for macOS or Linux. Visual Studio for macOS is free and Microsoft open sourced Xamarin and Monodevelop [1] when they acquired it back in 2016.
Visual Studio for Mac is nowhere near as good as on Windows. I can't speak for how it is on Linux. I'm glad it exists, but I've found it a pain to use.
Obviously lots of C# development is still on Windows, but let’s not act like it’s 2003. I work on C# all day everyday and most of what I write runs on Linux.
You're right - it is a trojan horse and people are eating up the 'MS heart Open Source' PR. It's obvious when you look at what they're doing with language servers.
They've replaced the open source Python language server with a closed source one. The C/C++ was always closed. Their remote feature and collaboration tools are also closed. They're slowly making people depend on MS services without even realising it.
They want you to run your development environment on Azure and are making it possible piece by piece, turning your IDE into a thin client. And they're open about that aim but still call VS Code "open source". It is not - it has open source components and lots of telemetry so MS can develop those services. If people are happy with that, so be it but the 'love' they get is undeserved.
> And they're open about that aim but still call VS Code "open source".
Yeah, it's a principle worth remembering: "open source" doesn't mean anything if most of the software only runs on someone else's cloud without you having any control or visibility into it.
> They've replaced the open source Python language server with a closed source one. The C/C++ was always closed. Their remote feature and collaboration tools are also closed. They're slowly making people depend on MS services without even realising it.
So, what you're saying is that the absolutely enormous number of Python and C/C++ people can't produce a decent open-source plugin while tiny communities like the Rust folks can?
I don't like what Microsoft is doing here, but, let's be honest, the "open source community" has also spoken and what it has said is "We are a bunch of cheap, selfish jerks."
You don't have to fund very many programmers to create these plugins. Full-time funding for maybe 5 or 6 programmers per plugin can pull it off (and maybe not that for something like the remote development plugin). And not all programmers around the world cost $200K per year. However, even if they did, that's $1 million per year to support a plugin.
So, no company or individual out of the entire Python or C/C++ ecosystem thinks that's a worthwhile expense? No group of 5 or 6 companies think that's a worthwhile expense?
As we found with OpenSSL and other open source projects, no, apparently they don't.
Don't bemoan Microsoft's licensing when the problem sits with the "open source community" being cheap bastards.
Open-source C/C++ LSP server exists, clangd exists and ccls(https://github.com/MaskRay/ccls) is build on libclang which works very well for a few of my projects. I am not sure about python since i don't use it much.
Indeed, Microsoft Edge for Linux too is a trojan horse. Windows needs to gain leverage against open development platforms. They they need to reach other ecosystems (fedora, centos, mac os). Just like Google when you use their technologies you bet the app is talking to the mothership.
I'm legit confused on what you're trying to say. Are you saying tech stacks are a bad thing? Or that corporate investment or connection to a tech stack is a bad thing? What's your proposed solution or alternative?
One thing I _think_ you're saying that I do find important:
It's crucial to have experience in more than one ecosystem and tech stack, as you learn a lot from seeing communities reinvent the wheel and not learn from one another. You get to see common patterns in software development and engineering and, sometimes, you find novel approaches that are completely alien to the engineering ecosystem you started out in.
I am saying opaque, closed and proprietary tech stacks are the danger. See the other reply for a better discussion on what is happening. Basically Microsoft* is very well known for taking open source projects, extending them a little in a nice package, and then silently moving all the code to a proprietary closed solution that later on only works on windows or their platforms.
\* microsoft is well known for it, but Google does it a lot too.
You're right; my years of experience with Java, Maven, Netbeans, Eclipse (eugh...), and IntelliJ completely evaporated when I did 'npm init' on my current (Node and React) project, which I'm working on in VS Code.
VSCode is pretty good but annoys me that many tasks are primarily mouse oriented and some keybindings require home/end/pgup/pgdn and arrow keys. Feels tedious when coming from vim/emacs.
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, but it was truly painful trying to find where in the interface to use the plugin and how to use it.
It reminded me of using VIM as an IDE - not an IDE, a big pile of stuff that isn't integrated. I started using VIM as an IDE when I started programming and I believe it cost me a year of time - I should have gone straight to a consistent integrated IDE.
I prefer a batteries included approach such as the Jetbrains IDE's.
I absolutely do use VS Code - it's always loaded, but I only use it like a simple text editor.
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.
The Mac version of VS is not actually VS at all, it's rebranded Xamarin Studio. I assume the GP was talking exclusively about "actual" VS when he says it's much better now, which I also agree with.
I actually deal with a lots of code, c/c++/js/python/golang/lua/sql, guess what vim can be configured to work well for them all: autocomplete, syntax highlight, auto-format,etc. along with nerdtree, I rarely need mouse at all during coding.
Use Emacs - it's a big pile of stuff that's very well integrated, because the platform lends itself to deep interoperability - thanks to a strong conceptual model and extreme reprogrammability. :).
Jokes aside, I guess what VS Code needs is to grow a strong community of people who care about the editor as much as what they do using it. Emacs has managed to do that, so it's possible.
It seems like Emacs shares the same product philosophy of VS Code. Outside of the core functionality everything is an ELisp/Javascript plugin.
That explains Emacs amazing longevity, but as the article points out, Emacs longevity is actually a problem as its keyboard and UI conventions predate the modern conventions that came with Windows and MacOS.
It's a slightly different philosophy. Emacs is best viewed not as text editor with plugins, but as a Lisp Machine emulator with a text editor. The joke about it being an OS is more true than people think: what you get is a (2D, not 1D like shell) text-oriented programming environment, back from the times where "a programming environment" meant a fully end-user-programmable OS.
This has an important downstream consequence on the "plugin" ecosystem: since these "plugins" are better seen as small applications running on in a shared, restriction-free OS, they don't need a fixed and restrictive API to interoperate. The entire Emacs is the API, and as long as an elisp app follows conventions and plays nice, it will almost seamlessly interoperate with every other app. And in cases where it doesn't (e.g. you try to use two apps that do roughly the same thing), it's relatively trivial to patch out the conflicts yourself. Having an integrated debugger and REPL is also helpful :).
VSCode philosophy feels more restrictive compared to that.
As for the keyboard conventions, it's true and it impacts the market share, but that's a problem for almost any software that reaches longevity. Conventions come and go, so it shouldn't stop one from learning a tool that keeps proving its worth over decades. And in case of Emacs, if you don't like the default keybindings, you can quite easily patch them up to follow whatever convention you fancy :).
Terminology is a slightly worse problem because you can't patch that out if you don't like it - but then again, it's just a bunch of terms you need to learn; par for the course for any developer.
Keyboard conventions do come and go but muscle memory is expensive to reprogram. Your hands are also irreplaceable. So I go for the most efficient that's not too radically unfamiliar or painful.
And honestly one could spend a career learning every editor/IDE in depth without ever accomplishing anything else. Embedded is especially bad as one often must use the IDE integrated into the platform's SDK.
Right but that requires learning Emacs well enough to change bindings. Then all the other tweaks one makes to a tool like text expansions, macros, and learning differences in find-replace, refactoring, and autocomplete.
There's no more learning required for changing Emacs keybindings than in other IDEs. If you don't want to go the scripting way, you can use the Customize interface, which is Emacs's equivalent of Settings dialog in most other software. Hell, unlike most software, Customize interface gives you a choice between applying changes temporarily and permanently, so you can try things out and if you mess up, just restart the editor.
(Under the hood, stuff you change via Customize gets serialized into a file called custom.el. But you don't have to know that to use it.)
The difference between VSCode and Emacs is the difference between an extensible text editor, and an editor that was designed to be extended, molded, and shaped as you work. At any time within Emacs, you can evaluate Lisp code to extend or modify its functionality. What's more, the always-on presence of Lisp turns Emacs into a computing environment with strong editing primitives, rather than a text editor with stuff bolted onto it. I use it to automate tedious tasks, where it serves as a sort of Lisp-programmable super-shell that can ingest data from processes and network connections into buffers, as well as the inverse, all under the control of a powerful programming language.
I'd like to hear more about how you use Emacs as a "super-shell". Do you avoid shell scripts entirely in favor of Emacs Lisp? You mentioned network connections - do you actually do scripting with Elisp's networking primitives?
I've long felt that this was an obvious and good use of Emacs - as a central coordination point for the entirety of one's computational life, with everything manipulated programmatically from a single programming environment with both rich UI capabilities and a full-fledged programming language. No other project seems to understand the value of such a central point... but still, there are many ways Elisp could improve to make this kind of usage easier.
> I'd like to hear more about how you use Emacs as a "super-shell". Do you avoid shell scripts entirely in favor of Emacs Lisp?
No. But I do use Emacs Lisp to automate certain tasks and then wrap them up in an Emacs interface -- like highlighting some JSON to submit to an API endpoint, or using ivy to select a Docker container to start or stop.
> You mentioned network connections - do you actually do scripting with Elisp's networking primitives?
Emacs provides an OOTB way to hit API endpoints in the form of 'request'. So it's not just the networking primitives, but the utilities built on those primitives that Emacs comes with.
> there are many ways Elisp could improve to make this kind of usage easier.
Emacs Lisp has had two major warts: speed, and the lack of lexical scoping and CL-like constructs. The latter is largely addressed. The former is being worked on with efforts like gccemacs.
Why? A good Lisp will give you a decent ride around the block. Even without reaching code-data-equivalence enlightment, it's a fast way to round your knowledge of various paradigms and approaches.
> At any time within Emacs, you can evaluate Lisp code to extend or modify its functionality.
This is also true for VS Code (with JavaScript instead of Emacs Lisp of course). VS Code is just a bit more organized on the surface, giving it significant advantages over emacs in that regard, but also a bit more closed in culture.
I've recently switched from Spacemacs (vim-style modal editing and keyboard commands, in Emacs) to "Vanilla" Emacs.
I've been finding that once I changed capslock to become control, the various keyboard commands in Emacs make a lot of sense to me. In fact, far more than I thought they would, to the point where I'm feeling a lot more comfortable and competent performing the shortcuts, which means I remember a lot more of them. (Remembering shortcuts has always been a problem for me because I have various Adult ADHD issues.)
Sure, it's just one person's anecdotal and subjective, experience, but I've found myself using Emacs to edit my code (mostly Terraform and Ansible) much more than VSCode.
I agree that there should have been some kind of "core" package for Node.js that is supervised by the developers but still an optional download, but the people that were initially in charge of NPM fought that idea to death in order to make people... use and rely on NPM.
Some people absolutely took advantage of the situation from a financial standpoint and created a business opportunity for themselves, at the expense of the community.
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)
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.
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.
I could not understand why anyone would be happy if VSCode came with 50 core un-installable plugins and none of them were useful to you, since everyone has slightly different projects they're working on. It would be inefficient and it wouldn't cater to a larger user base.
There's a happy middle ground that far too projects choose: building a modularized system, but distributing core, currated plugins with the system.
Effectively, I don't care if I receive a batteries-included product where the batteries are pre-installed and on-demand loaded, vs one where they're permanently installed.
>> 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.
Unlike the FANG companies, Microsoft doesn't tend to rip the carpet out from under independent developers like that.
Right, but they would. Plugins aren't paid right now, so all I'd think it would take would be Microsoft saying "hey, people like your plugin, we'll pay you to maintain it, and if you don't want to maintain it, we'll inhouse it."
Wasn’t there recently a thread were Microsoft interviewed someone that has a third party dev tool, declined to hire him and then recreated the same tool with almost the same name without acknowledgement?
You mean the app that he named almost the same name as another, long-existing Microsoft product? (NuGet) It's not like AppGet was developed in a vacuum. And it's definitely nowhere near the situation like Facebook cloning Virtual Desktop, threatening to crush the original developer if he didn't join them, and naming it the exact same thing.
This is the difference between an opinionated vs non-opinionated IDE
You seem to prefer opinionated, where other people like the fact they can pick and choose from various plugins to my their IDE their own, and if they do not like the default implementation of a feature there likely is another plugin that may work for them.
For example there are a couple of git plugins, all of them act slighty different based on the workflow of the users of that plugin, if MS came in and said "No this is how git workflow is in VSCode and no other way is possible" that would turn off alot of users
Further you stated another glaring problem, Jetbrians mikes IDE's plural, specialized for each lang they are targeting, VSCode needs to work with many lang, there is not a VSCode:Python edition, and VSCode:Powershell edition, etc et c etc
It is just VSCode and plugins add the Languages you need / want support for
I thought that until I realised IntelliJ Ultimate is really IntelliJ + WebStorm + PHPStorm + RubyMine + PyCharm + Goland and with plugins you're covered for most major PLs except C,C++ and C# which require 2 separate IDEs.
That depends on perspective. If you are a professional programmer using JetBrains tools as daily drivers then I think think £100 over the InteliJ price is pretty reasonable to get access to their entire library of tools.
Consultants make at £400 day here, dotnet devs usually more.
If you are a hobbiest, it's cheaper.
And the costs decrease each year.
If you are saying £100, then it sounds like it would offer you money for value, so it's probably not for you.
> 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.
microsoft already has an IDE like this for their core languages; it's called visual studio. it's kinda bloated, but it's still a great tool for languages that microsoft has deigned to grace with its direct attention. for anything else, you're SOL; the plugin ecosystem is pretty limited for VS. the more VSCode reimplements plugins "natively" (isn't it all JS anyway?), the less it has a reason to exist.
It’s pretty easy though. You open a Python file, it asks if you want Python plug-in installed. Then you’re pretty much done except specifying your virtualenv. If you have linter settings it will ask if you want the linter installed.
The big thing with Jetbrains is the cost. PyCharm is $9-$25/month and VSCode is free
Sorry to spoil the party here but I wouldn’t call it excellent. I need to set environment variables and PYTHONPATH in 3 places (for the integrated terminal, for background processes and for the debugger). New environments are only detected after restart of the UI and It doesn’t Index or allow go to definition for libraries downloaded via pip most of the time. Also no refactoring support...
This is really frustrating. Am I doing something wrong?
In my company we use pyenv with virtualenv and everything works seamlessly. VSCode automatically runs the activate script from pyenv in a new terminal (in my case it is even the fish shell), debugging works fine, and I can go to definitions.
Note that a new extension, that works alongside the original python extension, has been developed by Microsoft: Pylance. It speeds things up based on pyright, a python type-checker.
For refactoring you can use rope [0] as a VSCode extension.
Hey, thanks for your input. I will look into using pyenv so that might solve my problem with "go to definitions".
However, I was also having a lot of trouble with environment variables, especially PYTHONPATH. How do you solve that?
Also rope did NOT work well for me. When I tried to refactor (rename) a function definition, it also changed variables in unrelated scopes that had the same name and were not related to the function at all. So I did not gain anything from that which I couldn't achieve using CTRL+F replace.
I've never had any trouble with PYTHONPATH, I guess this is solved by pyenv with virtualenv. You just need to select the project interpreter the first time you open the project and it should just work.
I haven't used rope extensively, it's too bad that it doesn't work well. It's open source so I guess it needs more contributions.
I totally agree with the everything plugin aspect.
Then consistent and integrated IDEs are a mix of “everything and the kitchen sink” and “our way or the highway”
Personally I prefered to pay the price of an ugly and patchworky workspace to get something that works like I want to work and without too many things I don’t care about.
I use VSCode with no plugins. It's an amazing code editor, and by default it does code highlighting for C++ and TypeScript. I build in a terminal, outside of the editor, the way it's supposed to be done.
Well an IDE is more than just a text editor+syntax highlighting+a terminal.
It's also about type hinting, refactoring, debugging, etc.
And for the two languages you speak of it just so happens that the support is shipped with VS Code since Microsoft is heavily invested in the development of these languages.
Curious what language/env you tend to work in? I have found that working in JavaScript and TypeScript, I don't really need any plugins when using VS Code. I do install a couple, but none are essential, just some small niceties.
I'd rather take an editor where I add in the stuff I need instead of it coming with all the xruft I won't be using. Visual Studio would be nice but the UI is way too cluttered for me and I can't focus if I can't organize the views as I need them. No issues with VS Code. I'd just wish it'd be possible to pop out the file explorer and git views into their own windows but I can use other tools for those so no harm there.
JetBrains IDEs are development environments, meant for editing code, in specific primary language. They really try their best to understand code that user works on (which is a hard problem, because code is frequently invalid while it's being actively edited), and make it as convenient as possible.
VSCode is - in my understanding - essentially, a step over older glorified extensible notepads on steroids. Unlike those older extensible notepads, it does have built-in programming language editing features, but mostly it's still not the core product but rather a job for extensions and language servers to fill that niche.
So for me VSCode wins over editors like Sublime or Atom, that don't have core programming language processing concepts baked in, but still loses to the specialized IDEs where specific language support is a primary feature (like PyCharm or GoLand).
Can’t speak to CLion and AppCode, but Rider is spectacular. It integrates all of Resharper’s (JetBrains’ C# code analysis tool) features with the IntelliJ core that run circles around the bloated, buggy mess that is modern Visual Studio (not to be confused with Visual Studio Code).
Love Rider. ReSharper makes Visual Studio unacceptably slow though. It's already borderline without RS but adding it makes it totally suck, for me at least.
PyCharm is also a common IDE core with a bunch of Python-specific extensions on top. It just so happens that JetBrains ships those extensions pre-packaged under different names for various target audiences, and they - especially the Java ones - have a lot of features, and decades of polish.
> JetBrains IDEs are development environments, meant for editing code, in specific primary language.
I've used RubyMine and IntelliJ. IntelliJ kept me sane for the thankfully-short time I worked with Java, and I appreciate it. But I can't get past how SLOW RubyMine is. Even on my $4,000 MBP, it just feels sluggish. Maybe that's because I'm at home on Rails, and I can think faster than the IDE, but there's really not much excuse to my mind for being that slow, especially on top-end hardware. It once helped me debug a plugin of plugin of a gem, and I'll be forever grateful for that, but I keep trying it every so often, and failing to part with my cash for it. I pay a lot for software, in general, but that one's just too steep for my taste, when tools like vim, Sublime, and VS Code exist.
I work on a stack that has ruby on rails on the backend, javascript on the frontend, .NET Core apps to do data transformation, and some NodeJS thrown in there, too. I have to switch back and forth between these projects regularly. There is no other tool like VS Code that provides me the flexibility to have snippets and highlighting and the things I need to maintain these projects, while also giving me the flexibility to switch between languages and syntax on the fly without having to wait 20 minutes just for the IDE to load up.
Java, Python, Go, Terraform, Bazel, all in the same IDE at once. Best in class refactoring for all of them. Handles the monorepo surprisingly well (Bazel is a big help here, too).
I had to bump the memory a bit on the IDE, but after hundreds of thousands of lines of code the index gets large.
I used to use VSCode heavily... Emacs before that. But now with IntelliJ I don’t really need much else. The plug-in ecosystem is really nice too.
> 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
This is why my experience with VS Code reminds me of Eclipse.
> It reminded me of using VIM as an IDE - not an IDE, a big pile of stuff that isn't integrated. I started using VIM as an IDE when I started programming and I believe it cost me a year of time - I should have gone straight to a consistent integrated IDE.
You don't start using Vim as an IDE. It's a waste of time, because like you said IDEs offer a complete product right off the bat. You start using Vim as a text editor, for text editor things, and when you're familiar enough with Vim's plugin ecosystem you may start to enhance your text editing experience with IDE-like features. And you may come to realize that's all you need.
Learning Vim for the sole purpose of tuning it into an IDE is a terrible idea no matter how you slice it. I blame people who hype their Vim setup as a complete IDE even though they started learning Vim as a text editor, not an IDE.
The articles talks about editors, but VS Code is mainly an IDE.
Its predecessors were in order Emacs + single-language IDEs + proprietary IDEs, then Eclipse and finally IntelliJ IDEA CE.
Emacs lost because it failed to update to reasonable modern conventions and because it used a niche programming language.
Eclipse lost because they released a bunch of different bundles instead of a single install (apparently because the contributing companies saw Eclipse as a common base for their proprietary IDEs), it was slow for the time, and had a bunch of unnecessary UI complexity (e.g. it had an unnecessary perspective system that would change the IDE layout depending on language, meaning that you couldn't just customize the IDE and have it apply for all languages, but had to customize each perspective).
IntelliJ IDEA lost because only the core was open source and major parts were proprietary, resulting in reduced 3rd party confidence.
VS Code is winning because they have a major company backing it that mostly doesn't seek to make proprietary IDEs with it except for minor proprietary aspects, uses the most popular language for extensions, avoids unnecessary UI complexity and is also fast and technically good.
Don't discount free. People can talk about a good craftsman paying for good tools, but corporate developers have to go through the corporate approval process to pay for just about anything, so free is friction-free.
Before VSCode the king of this was Eclipse. It was free, so it was everywhere, used by a plethora of companies. 2012-2015, when I was using it for vanilla Java development, knowing it let me get up to speed quickly on the Scale IDE, JBoss development from Red Hat, Mulesoft's MuleStudio, Teiid database virtualization, and Salesforce's IDE.
VSCode is taking it's place, IMO; Salesforce has switched to it for its IDE.
And people with fewer options. There are plenty of situations where you are stuck with Vim or Nano (Vim usually comes out on top if you're doing anything non-trivial).
1. People who do most of their work in the terminal and don't need a full IDE for editing their config files. A subset of those imo would be those who have lots of different servers they ssh into and like to have the same (or similar) editor everywhere. (vi and vim for example)
2. They like a more lightweight editor. Being able to configure anything relatively easily if you know what you're doing would probably also fill into this.
3. People who primarily use keyboard based navigation and like not having to move their hands as often. I count myself to this group, as I recently discovered doom-emacs and absolutely love the keybindings it has. (vim keys for navigation. Functions are handled by the spacebar and a key combination)
Its okay for web stuff but I use Jetbrains IDEs for C++ and Go. They are way better. C++ crashes and gets into weird states all the time on VSCode for me.
I'm an iOS dev for the past 8 years, so I've been all in on mastering Xcode. I now must use VSCode for certain things at work, and while it's not my favorite, I love the plugin ecosystem. I really wish Apple had improved the ability to write Xcode plugins; instead they kneecapped it. To folks who say that VSCode plugins are a shambles: flagship IDEs have their problems too.
It's been interesting to watch some of the UX patterns popularized by the editors mentioned in the article creep into Xcode, though. Again, I dislike some, but I'm glad to see evolution taking place, and I need to repeat a mantra I've said many times: "always be learning." That's the only way to remain successful.
I don't actually use a ton of VSCode plugins, but I'll give a shout out for GitLens. It is magnificent. Big thank you to the maintainers.
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 Panic (https://nova.app/) the other day, and the native app performance makes a noticeable difference. I know it's doing less, but I can still search the codebase quickly and the resource use is like 10% of other IDEs.
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.
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.
While Fugitive is very good, I've yet to find a better Git client than Magit, that's actually one of the things that make me reluctant to switch to Vim full time.
I was almost going to abandon vim in favor of VS Code due to the "intellisense" features, then I discovered coc.vim and I'm so happy that I don't have to leave vim
To my mind VS Code (and not only VS Code, vim and other editors also) not only competes with editors, but with IDEs as well. It's interesting that he doesn't mention JetBrains at all. I'm curious to see if there is a trend of people migrating from it (or not?) and why.
> GitHub’s Codespaces also run VS Code as a web app, this time by spinning up an ad hoc development environment.
This probably can be the first time we'll see people use online code platform for real.
> It's interesting that he doesn't mention JetBrains at all.
Think you nailed the most salient point, quite curious in the corporate battle of wits on Twitter, HN, and other venues. Since HN rules discourage meta discussions, I'm gonna stop here.
I want to like VS Code, but I can't stand the "dynamic" left side bar. It's used as an "explorer", it's used to handle "extensions" and it's used for search. I want a fixed left sidebar (fixed as an "explorer"). Is this something configurable?
You can try the following:
1. Open the explorer tab on the left
2. Drag every other item on the left bar into the explorer menu. This adds a little menu at the bottom
3. Collapse each of the menus at the bottom and never open them again
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].
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.
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.
This is also true with TRAMP. Anything in core Emacs, and any package outside it that isn't aggressively poorly written, works transparently with TRAMP. The core utilities for interacting with the OS such as start-file-process are all TRAMP-aware. (Or more specifically, TRAMP provides file handlers which customize start-file-process)
That comment doesn't contradict the post at all. If anything it supports that statement and then goes on to mentions that high latency connections are problematic.
High latency connections are a fact of life. If Emacs Tramp, for which development was started in 1998, when high latency connection were a lot more common, still has issues with high latency connections, that's not a glowing reference for its architecture.
Especially since it seems VSCode manages those connections better.
It's ok to admit your favorite tech has flaws, everything has them.
Not disagreeing with that. I am just saying that the previous post was that plugins don't have to be modified with Tramp and work transparently. The post referenced above does not disagree with that. Instead it says that tramp does not deal well with high latency connections. I think is important to be clear where the issue lies if one wants to get it fixed.
One area I have found where TRAMP really suffers is when you have a relatively high-latency connection. I'm living on the east coast right now and connect to a dev box in Washington to work, and tramp is basically unusable. Every time you enter a folder in a project, emacs will stall for 1-2 seconds (unless the folder has been entered and cached before: unfortunately every time you restart emacs you'll have to go through it all again). If you've forgotten to disable autocomplete in a remote shell buffer, the first character you type will cause emacs itself to hang forever. There's unacceptable lag when opening and even navigating files. Good luck ever running grep or magit.
With VSCode on the other hand, I have no issues at all: couldn't even tell the project was remote.
I still use emacs (emacs -nw via ssh), but it's nowhere near VSCode's responsiveness and now I cant use GUI emacs. It's definitely a source of frustration :/
> The difference is plugins work on the remote side of the connection without having to be aware they're in a remote connection.
This is cool when the machine you are connecting to is more powerful than the one you are sitting on. This is far less cool when the machine you are connecting too is less powerful than your desktop (RPi or Beaglebone, for example).
I spoke to the team in KubeCon last year and they said “our research team is looking into it” with a hand wave. I doubt IntelliJ will actually implement this anytime soon, sadly.
I use JetBrain's remote python interpreter functionality[0] with great success and convenience. For anyone whose development environment is appropriate for its use, I honestly cannot recommend it highly enough. It's only available under the full "Professional" license version, however.
This uses SSH and SCP to automatically deploy the code to the remote environment and run it with the interpreter on that machine, rather than your own local laptop/desktop. One advantage is that it does not require any special software to be installed on the remote server. I believe VS Code's solution requires a pretty hefty installation consisting of basically an entire copy of VSCode onto the remote server.
The downside of JetBrain's approach... I believe that it requires a local copy of the files in order to perform the "LSP"-like syntax error highlighting / suggestion functionality that JetBrains software is so lauded for. This could be difficult/inconvenient if your codebase is particularly enormous, or if you aren't allowed to mirror it locally.
However, given the amount of support that JetBrains has for this kind of setup, I wouldn't be shocked to see an additional option for something more in the style of "VS Code Remote Development"
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.
The situation is similar to Google Chrome/Chromium: Most of it is open-source, but the release binaries contain some proprietary bits for telemetry, marketplace access, etc.
Because VSCode is under a permissive license (MIT) rather than a copyleft license (GPL), Microsoft can add any proprietary extensions it wants. "Permissive" licenses are only permissive for the creator and other developers (only sometimes), not for the end user.
In order to contribute you have to sign away your rights, so it's only permissive to MS. It's a pervasive view on open source, cheered by sockpuppets, making people believe MS is now a open source company.
Eclipse foundation has a new project, Theia[1], which forks VSCode and one of the reasons they state is that the extension ecosystem is not opensource.
They want Theia to be a tool to build your own editor and it can be built as a hosted solution (like code-server) or a standalone editor
Edit: I see that the article also mentions Theia but this point about Theia vs VSCode is not mentioned.
> 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.
You can do something similar with IntelliJ by running npm inside a Docker container with your working directory mounted into it. IntelliJ will happily index the resulting node_modules folder without executing any code on the host.
Remote has been a game changer for my development as well. Work forces me on a Windows machine with the full suite of corporate spyware. Said spyware loses its mind when compiling, debugging, language server inspection, git actions on large repo, etc. Performance loss is somewhere in the region 2-10x.
With remote, I am able to do all coding on a non-infested Linux server with almost seamless usability.
Your company is equally cool with you just having all of your code/IP on a unsecured (i.e. not running crazy large antimalware, not actually insecure) Linux box?
sounds like my company: any windows machine is infested with a dozen or so McAffee things that make it unworkably slow. But none of the drones that role out McAffee has ever touched linux or osx, they prefer to leave that alone. So even though I actually prefer windows as a desktop OS, I mostly worked on a MacBook (until the pandemic, now I WFH on a my personal windows machine). But since WSL2 is finally backported to whichever outdated windows my corporate laptop runs, it is actually quite usable with VSCOde/remote containers + docker
Maybe it works for literal remote development, but the jetbrains support for remote dev in a docker container is a complete afterthought. There's tons of critical, relevant feature requests that have been stuck in the pipeline for years. In vscode, it is well thought out and polished. My team desperately wanted development out of containers to ease on-boarding and standardization of development environments. Trying to make it work with CLion was a nightmare that was practically dead before it started, and we thought we'd never get it. Then we found vscode's support and have never looked back. I sometimes laugh looking back at what we were having to do to get it to even slightly work, and think about all the troubles we would have had ahead.
It is also great for string all dependencies for development together in a docker-compose file. On any machine you just have to git clone and open vscode in the container and you are good to go. Even if you require a particular version of postgresql, some compiler version or a complete Kafka cluster; everything can be configured in a Dockerfile/docker-compose file and stored with the code. No more pages long readme's of how to get all dependencies set up just right. Especially when often switching between projects and machines this is a godsend. And for onboarding it is so easy to get someone a fully configured working environment.
The only thing that's been preventing me from fully adopting this is that I don't have my local shell environment (autocomplete, syntax highlighting, etc.) anymore. Maybe I'll have to look at getting that setup in a container sometime, and then copy that over to every container I use.
Absolutely. I build Android images (AOSP/kernel/lk customization) and at the beginning I was using Eclipse over a shared network folder (I have dedicated remote hardware to host and build these monstrous images), but everything was a chore. Then I switched to VSCode + Remote Development over SSH.
Imagine placing the workspace at the root directory of the entire Android source tree, pressing ctrl + shift + F and finding anything in less than a couple of seconds. For C/C++ code, press F12 just ANYWHERE on the code to go to the definition, no matter if it's the entire kernel code, or vendor or AOSP code: it just finds the definition at lightspeed.
For building I use the integrated console. If there is an error or a warning anywhere, you can just click on the console an it takes you to the file with the error/warning. Also it integrates perfectly with Git and has extensions to parse DeviceTree files.
And everything was just much more appreciated while working at home during pandemic.
It sounds like a testimonial advertising, but it's the way it is.
"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
When I used Rider at my last job, it would pick good auto defaults that you could customize based on the project configuration, including automatically generating IIS express configuration values.
Are there more explicit downsides you can mention?
JetBrains' IDEs have built-in update managers. They present you each plugin, giving you a tick-box of which ones to update. The Toolbox app manages the IDEs, allowing to update automatically or not, install pre-releases, and roll back. It's polished.
The IDEs use the established desktop UI norms of toolbar menus.
They come with pre-defined 'Run' templates for many languages/frameworks.
There is a single Event Log for output of updates etc.
The left menu has words so I know what the icons mean, and isn't obnoxiously large due to over-use of large icons.
I agree its good for a single framework. But the amount of features/ui for things I'll only use once on a blue moon is too high. I'll take config files and shell commands over multiple layers of buttons and menus any day of the week.
Yes it’s subpar compared to Visual Studio as a .NET IDE, but that’s probably one of the reasons .NET hasn’t been prioritized yet: There is Visual Studio.
The last time I opened VSCode was a few months ago. My work has shifted to other things, so I needed it a little less than before. I really hoped that VSCode could be an Emacs replacement, but I think that's a bigger job for me to pursue than I want to commit to.
For me, Emacs is not perfect, but it has always been the most versatile software I worked with. It's very much (and I want it to really be) the everything text editor. I got the interaction model (with a few good modes) burnt into my brain. I find it hard to get used to anything else (I usually also end up installing plugins to emulate Emacs in other editors/IDEs, but they never as good as Emacs itself.)
VSCode does get a lot of things right out-of-the-box: the interface is snappier when doing things like code completions and language plugins are rather consistent with little effort. But that's where it stops for me. At least I understand its popularity.
I use VS Code every day and it's a great platform, but to claim it's the endgame of editors is one big hyperbole. It's a very opinionated piece of software that serves lots of popular niches well right now, but I haven't yet been able to find a mix of extensions that makes it a viable replacement for IntelliJ for Scala, to name one example.
I'd expect the next uber popular editor to be optimized towards completely different things, though. VS Code is a great all-purpose IDE for enthusiasts and professionals, who are willing and able to dig into pretty complex UIs and complicated concepts. Take the git integration – it frequently breaks (for me), and when it works, it's really very superficial and requires me to really understand what git is doing in the background.
Last year I've tried to teach my dad how to use git, so he can put his python robotics projects in GitHub. It's been eye-opening: All the idiosyncracies and complex ideas that I've grown accustomed to over the years, that's one Eiger North Face of a learning curve if all you want to do is get those Python files on GitHub and have some people collaborate with you there.
It's also pretty hard to discover functionality in VS Code. It wants to be everything to everyone, so it can't expose functionality in a way that specialized IDEs can – and even those tend to be either messy or sort of cryptic. It's really hard to be effective in any IDE without memorizing dozens of keyboard shortcuts, which isn't a problem for software people, because we either like this, or have grown accustomed to it. I guess that's why the Touchbar is wildly popular outside of software engineering and related disciplines – for apps that support it, it exposes functionality directly and in a context-sensitive manner.
Hundreds of millions of people around the world will start programming in this decade as the world is rushing into a future where code is the stuff that most of anything outside pristine wilderness that we ever experience, is at least partially made of or faciliated by, that all social, economic, political activity rests upon.
There is no tooling that would be appropriate for this kind of use case – whatever will end up filling that niche, the casual programmer who doesn't want to get deeply involved with software engineering, but get their semi-complex problems solved without tasking a team of SWEs, whatever will do this will have to be a lot cleverer, easier to use, more discoverable, more intuitive – make collaboration feel much more seamless – and still be very powerful. VS Code with its laser focus on the current developer crowd is probably not very well-suited for this.
> It's really hard to be effective in any IDE without memorizing dozens of keyboard shortcuts,
Curious if you use the command palette much? It should be a decent replacement for route memorization of keyboard shortcuts: How do I format this document agian? Hm... F1;form;enter done. And git push? F1:gpu;enter. Etc.
I work on vs code and am trying to improve this area so all feedback appreciated!
Yes, definitely (I use Cmd-Shift-P a lot, which should be the same thing? I also use Sublime so that shortcut being the same is valuable), but more for things I need to do relatively rarely, as it's an order of magnitude slower than just pressing the respective key combo, plus requires some mindspace (what would I best type to find this?) – so it's not a complete substitute, but still extremely helpful. I'm not sure how I'd manage without. But, say, toggle comment is something I'd rather not do via the command palette, though, too slow and cumbersome, breaks my focus. It's not that great for discovering functionality, either ("autoformat" doesn't work, but might be the first search term I think of, etc.) – but it really helps with all the things I know are possible but that I use too rarely to remember a shortcut for.
I really like what IntelliJ is doing with the Mac Touchbar – that comes much closer to a substitute for memorizing (some) shortcuts for me. Cursor in a class definition, pressing shift gives me "Rename", "Change Signature", "Move Class", with Cmd pressed I get "Show usages", stuff that's somewhat context-sensitive and actually useful, though there's still lots of room for improvement, lots of useful functionality that isn't exposed that way, there could be more context-sensitivity, but it's a good start. It's something I miss a little when using an external keyboard or VS Code (which doesn't seem to support the touchbar yet). I have to look at the thing of course, but then it's right below the screen, so its not like staring at the keyboard while typing, and being able to "just do" these things without any memorization is nice, a little bit slower than shortcuts, but it doesn't break my focus nearly as much. No idea how one might offer something like this on devices with no touchbar, but I think they're on to something there, especially for people who spend only a small part of their time inside an IDE.
Good to know you use command pallet, I agree that it's not as fast as keybindings, but in my opinion it's a good way to learn about keybindings for future use -- if I search the same thing on the command pallet often enough, eventually I'll look over and see what the keybinding is.
I agree more touch bar functionality would be nice, though you can add that through extensions if you're really interested.
> No idea how one might offer something like this on devices with no touchbar,
What you describe should almost all be available by default via the F-keys already, which is nice because it works across all keyboards without needing to learn new stuff. I personally have by touch bar show just the F-keys when I'm in VS Code.
There's a couple big knocks against VS Code that don't get brought up enough
The extension API is underdocumented. It's very difficult and time consuming to onboard yourself as an extension author with just the MS docs, since they don't cover the entire API and the vast majority of data structures are undocumented entirely. This is really annoying when functions take structures as arguments and have optional fields. Descriptive naming isn't descriptive if it describes how the argument is used by the callee, not what it means to the intent of the caller.
VSC also inherits the core weaknesses of Electron. Not overall performance/memory so much as startup time (just a second ago I had to wait 3 minutes for VS Code to boot because I had too many workspaces open when my laptop's battery died on me). It can't open multiple windows in the same workspace (this is actually a fundamental flaw when debugging any kind of extension that needs to open its own workspace). It's possible to build an extension that uses compiled node modules, which is great for performance and usability, but it's officially unsupported because those modules are only compatible with the node version of a client's VSCode.
But when all is said and done, VSC has shown that it's a great platform and easy to target as an extension author (or easier than others), LSP and DAP are huge milestones, and the architecture itself is just so friendly to extension that it's created a fantastic and lively ecosystem.
But petty gripe: please kill the git username/password fields when I git clone a private repo over HTTPS in the console. I don't like being aggro towards what other devs find cool, but I think hijacking a CLI with an extension incredibly annoying. And I can't find a way to disable that specific "feature" without disabling all of the git integration, which I use all the time.
>Not overall performance/memory so much as startup time
Is this actually a problem, though? I typically use VSCode as a "focused" text editor; it's for working on a codebase for a long period of time (relatively speaking). A minute or do startup amortized over hours of work is not much of a bother really.
For quick edits, vim is still my go to. Different tools for different needs.
Yes, because of how VS Code has evolved we're not using it for quick edits but as a front end to entire systems. If I need to check something quick in a remote session that is configured through some extension in VS Code without simple terminal access and for one reason or another I haven't left it idling all day, those times will hurt my productivity.
We'd love to hear more about the lack of documentation you're referring to. It's definitely a solvable problem. Could you create an issue so we address the problem? https://github.com/microsoft/vscode/issues
Also on
> But petty gripe: please kill the git username/password fields when I git clone a private repo over HTTPS in the console. I don't like being aggro towards what other devs find cool, but I think hijacking a CLI with an extension incredibly annoying. And I can't find a way to disable that specific "feature" without disabling all of the git integration, which I use all the time.
This can be disabled with the `git.terminalAuthentication` setting.
697 comments
[ 3.9 ms ] story [ 331 ms ] threadhttps://youtu.be/IUMWFExtDSg?t=1146
(Edit: fixed three typos.)
I just have a few vscode windows open in fullscreen on my laptop. So I just switch to whatever one I need to use at that time. It's never really more than 3 at a time.
If you want a confusing workspace/project system try Eclipse!
In the end due to its UX I think it's pretty useless. I do use it on BIG projects because sometimes vscode will update or barf and forget what I had open.
I mostly just do "open folders in workspace" then hope it never goes away.
Linux, there seems no plans other than driving people into WSL instead, so.
POSIX CLI and daemons don't need GUIs.
https://github.com/Microsoft/python-language-server
https://github.com/Microsoft/PTVS
Like in unix tools or other text editors?
I used to think like that but imho when you learn Vim registers it totally makes sense, plus if you're using it in a terminal emulator you can use ctrl-shift-c ctrl-shift-v. Now about Emacs I don't have much experience, but Doom-Emacs and Spacemacs use the System's clipboard by default.
Solving a boring problem better is a thing new technology often does.
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.
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.
0: http://eradman.com/entrproject/
I've used vim and various simple text editors for a long time, but wow is VS Code nice. The Linux port of IntelliSense (at least for me) works more consistently than any of the of the code introspection tools plugins for vim I've tried. It works especially well if you're using CMake - it can pull all of the header paths out of the generated build system without you having to touch anything.
(using Microsoft's C++ plugin and the vector-of-bool CMake plugin (which Microsoft took over development for))
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).
At the end of the day, I go where the plugins are.
I guess LSP could do Dart which is the most critical aspect.
Though I still need remote development which is non-trivial...
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.
Discovering & pre-loading hundreds of thousands of files is slow on native too. I'm not particularly pleased with how easily folks write off web platform tech as somehow being the source of problems or slowness.
The one complaint that does seem fair is that the memory usage can be high, because there's so much runtime to load. Also, I just keep thinking about your ask here. You want a native editor. But it wouldn't be a native editor. It'd be a native Windows editor, a native Mac editor, a native Android editor, a native iOS editor, a native web editor, a native Gnome, a native KDE editor, &c &c; your preference seems to be that Microsoft have made at least 5 editors. I'm not sure how the plugin system could exist amid such a diverse amount of native runtimes.
Perhaps it is my habit of opening a subset of the repo into the workspace rather than the whole thing (e.g. only the bottom 4 or 5 directory levels so there is at most only a few hundred files in the workspace - builds etc just run from the usual command line so not having the entire repo in the workspace is not an issue for my workflow) but I have been nothing apart from really happy with the performance and have never been found wanting more, apart from loading time but that only happens once or twice a week so I can live with that.
Checking now, the workspace contains ~3.7 million files. I have had no perceivable performance issues with the editor, it works like a champ. Granted I have a beefy machine, but VS Code has been a pleasure from my first impression. For my needs, it's a great development environment.
Recently I onboarded someone to set up remote SSH editing. It did require a few technical steps, but after that they were joyous to see how well it works - a "game changer" in their words, saving them a lot of time and effort.
Since the start of lockdown I've been using it to remote edit from my laptop into my dekstop still at the office and it has been a flawless experience.
Compared to laggy and visually-aliased remote desktop experience (I did this for a while a few years ago and I ended up feeling see-sick after a while), or the faff of remotely mounting disks, it has been utterly seamless.
Notepad doesn't even load and crashes, Sublime will takes minutes to even load the file, Notepad++ will be unusable as scrolling will take a few seconds, and in VS Code it opens immediately and you can seamlessly scroll to any one of the 600k lines without any delay.
Ultimately VSCode is my daily driver but I use sublime3 when I need to do fluid text editing, anything column/multi-select based, regex replaces, or manipulating large files. VScode has those features but they feel slow and buggy in comparison.
I haven't used this because I have no chance to edit such gigantic files.
https://szkwjp.sakura.ne.jp/
This is a world ranking with other editors by the author, maybe others are suitable for non Japanese users.
https://szkwjp.sakura.ne.jp/bigtexteditors.html
Learn lazarus, what's that: a data module. A neat way of grouping related data sources and sharing them between forms which can query datatables.
Learn spring boot. What's that? Services. A neat way of grouping related repositories which can query entities.
Turns out if you learn one thing very well you know a lot of other things that are similar in nature.
Microsoft is selling you into the IDE, in small portions. This is similar to the IBM approach with JAVA last decade(s?).
You install a "text editor" for simple things, like code completion. Before you realize you don't even know which compiler you are using or where it came from. You just press F5 and look at convenient break points. And somehow it only runs right on Azure :) the last one is a joke (for now?)
As a language popularity grows, it approaches the Java curve. Just like nobody who uses `npm` like (or know) maven, nobody using VS Code know about the old java IDEs, and how they become todays Java IDEs. Or how the React monolith is the same as the Java Monolith.
I guess people mixing up java and javascript in the 90s... just thad more, long term vision?
what are they selling me
If you mean some future IDE that MS is working on that they plan to evolve VS Code into, I don't see MS trying to sell macOS or Linux users a proprietary dev environment or toolchain. It's certainly possible but your post doesn't provide any justification for that position.
[1] https://github.com/mono/monodevelop
They've replaced the open source Python language server with a closed source one. The C/C++ was always closed. Their remote feature and collaboration tools are also closed. They're slowly making people depend on MS services without even realising it.
They want you to run your development environment on Azure and are making it possible piece by piece, turning your IDE into a thin client. And they're open about that aim but still call VS Code "open source". It is not - it has open source components and lots of telemetry so MS can develop those services. If people are happy with that, so be it but the 'love' they get is undeserved.
Yeah, it's a principle worth remembering: "open source" doesn't mean anything if most of the software only runs on someone else's cloud without you having any control or visibility into it.
So, what you're saying is that the absolutely enormous number of Python and C/C++ people can't produce a decent open-source plugin while tiny communities like the Rust folks can?
I don't like what Microsoft is doing here, but, let's be honest, the "open source community" has also spoken and what it has said is "We are a bunch of cheap, selfish jerks."
You don't have to fund very many programmers to create these plugins. Full-time funding for maybe 5 or 6 programmers per plugin can pull it off (and maybe not that for something like the remote development plugin). And not all programmers around the world cost $200K per year. However, even if they did, that's $1 million per year to support a plugin.
So, no company or individual out of the entire Python or C/C++ ecosystem thinks that's a worthwhile expense? No group of 5 or 6 companies think that's a worthwhile expense?
As we found with OpenSSL and other open source projects, no, apparently they don't.
Don't bemoan Microsoft's licensing when the problem sits with the "open source community" being cheap bastards.
One thing I _think_ you're saying that I do find important:
It's crucial to have experience in more than one ecosystem and tech stack, as you learn a lot from seeing communities reinvent the wheel and not learn from one another. You get to see common patterns in software development and engineering and, sometimes, you find novel approaches that are completely alien to the engineering ecosystem you started out in.
\* microsoft is well known for it, but Google does it a lot too.
For example, Google Cloud Code which lets you deploy/manage cloud run and k8s from it.
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, but it was truly painful trying to find where in the interface to use the plugin and how to use it.
It reminded me of using VIM as an IDE - not an IDE, a big pile of stuff that isn't integrated. I started using VIM as an IDE when I started programming and I believe it cost me a year of time - I should have gone straight to a consistent integrated IDE.
I prefer a batteries included approach such as the Jetbrains IDE's.
I absolutely do use VS Code - it's always loaded, but I only use it like a simple text editor.
My VScode is tweaked to the languages I need and I can use one editor to switch between them.
And the linting and formatting just works.
It only takes a second but its absolute madness.
https://blog.arduino.cc/2019/10/25/new-arduino-pro-ide-a-clo...
https://github.com/arduino/arduino-pro-ide
I prefer to use Vim as a powerful editor, within Unix as my IDE.
vim rules for me, as a full IDE from the terminal.
Jokes aside, I guess what VS Code needs is to grow a strong community of people who care about the editor as much as what they do using it. Emacs has managed to do that, so it's possible.
That explains Emacs amazing longevity, but as the article points out, Emacs longevity is actually a problem as its keyboard and UI conventions predate the modern conventions that came with Windows and MacOS.
This has an important downstream consequence on the "plugin" ecosystem: since these "plugins" are better seen as small applications running on in a shared, restriction-free OS, they don't need a fixed and restrictive API to interoperate. The entire Emacs is the API, and as long as an elisp app follows conventions and plays nice, it will almost seamlessly interoperate with every other app. And in cases where it doesn't (e.g. you try to use two apps that do roughly the same thing), it's relatively trivial to patch out the conflicts yourself. Having an integrated debugger and REPL is also helpful :).
VSCode philosophy feels more restrictive compared to that.
As for the keyboard conventions, it's true and it impacts the market share, but that's a problem for almost any software that reaches longevity. Conventions come and go, so it shouldn't stop one from learning a tool that keeps proving its worth over decades. And in case of Emacs, if you don't like the default keybindings, you can quite easily patch them up to follow whatever convention you fancy :).
Terminology is a slightly worse problem because you can't patch that out if you don't like it - but then again, it's just a bunch of terms you need to learn; par for the course for any developer.
And honestly one could spend a career learning every editor/IDE in depth without ever accomplishing anything else. Embedded is especially bad as one often must use the IDE integrated into the platform's SDK.
(Under the hood, stuff you change via Customize gets serialized into a file called custom.el. But you don't have to know that to use it.)
The article mentions Excel, for example, coming a few years after that and going strong today.
So I really do think Emacs predating those conventions is not going to be overcome.
I've long felt that this was an obvious and good use of Emacs - as a central coordination point for the entirety of one's computational life, with everything manipulated programmatically from a single programming environment with both rich UI capabilities and a full-fledged programming language. No other project seems to understand the value of such a central point... but still, there are many ways Elisp could improve to make this kind of usage easier.
No. But I do use Emacs Lisp to automate certain tasks and then wrap them up in an Emacs interface -- like highlighting some JSON to submit to an API endpoint, or using ivy to select a Docker container to start or stop.
> You mentioned network connections - do you actually do scripting with Elisp's networking primitives?
Emacs provides an OOTB way to hit API endpoints in the form of 'request'. So it's not just the networking primitives, but the utilities built on those primitives that Emacs comes with.
> there are many ways Elisp could improve to make this kind of usage easier.
Emacs Lisp has had two major warts: speed, and the lack of lexical scoping and CL-like constructs. The latter is largely addressed. The former is being worked on with efforts like gccemacs.
Your answer: Learn Lisp!
Technically true even in spite of emacs, but if every engineer out there learns lisp to write better python wouldn't that be an interesting world.
This is also true for VS Code (with JavaScript instead of Emacs Lisp of course). VS Code is just a bit more organized on the surface, giving it significant advantages over emacs in that regard, but also a bit more closed in culture.
I've been finding that once I changed capslock to become control, the various keyboard commands in Emacs make a lot of sense to me. In fact, far more than I thought they would, to the point where I'm feeling a lot more comfortable and competent performing the shortcuts, which means I remember a lot more of them. (Remembering shortcuts has always been a problem for me because I have various Adult ADHD issues.)
Sure, it's just one person's anecdotal and subjective, experience, but I've found myself using Emacs to edit my code (mostly Terraform and Ansible) much more than VSCode.
- Features that should arguably be built in require searching for, evaluating, and installing a plugin.
- Some plugins spam you with a "What's New" page with each update.
Bookmarking is an example of these two in action: https://github.com/alefragnani/vscode-bookmarks/issues/175
Replace "vs code" with "javascript" and "plugin" with "library" and you've just described the javascript ecosystem.
Some people absolutely took advantage of the situation from a financial standpoint and created a business opportunity for themselves, at the expense of the community.
Batteries included! All you ever need to work with JS.
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)
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.
Effectively, I don't care if I receive a batteries-included product where the batteries are pre-installed and on-demand loaded, vs one where they're permanently installed.
Unlike the FANG companies, Microsoft doesn't tend to rip the carpet out from under independent developers like that.
To avoid left-pad situations
No, they roll them into the carpet and sodomize them like they did with Keivan Beigi and at most just sheepishly say sorry after some public outcry.
You seem to prefer opinionated, where other people like the fact they can pick and choose from various plugins to my their IDE their own, and if they do not like the default implementation of a feature there likely is another plugin that may work for them.
For example there are a couple of git plugins, all of them act slighty different based on the workflow of the users of that plugin, if MS came in and said "No this is how git workflow is in VSCode and no other way is possible" that would turn off alot of users
Further you stated another glaring problem, Jetbrians mikes IDE's plural, specialized for each lang they are targeting, VSCode needs to work with many lang, there is not a VSCode:Python edition, and VSCode:Powershell edition, etc et c etc
It is just VSCode and plugins add the Languages you need / want support for
Cheaper for personal use, and free for students.
https://www.jetbrains.com/idea/buy/#commercial?billing=yearl...
Consultants make at £400 day here, dotnet devs usually more.
If you are a hobbiest, it's cheaper.
And the costs decrease each year.
If you are saying £100, then it sounds like it would offer you money for value, so it's probably not for you.
microsoft already has an IDE like this for their core languages; it's called visual studio. it's kinda bloated, but it's still a great tool for languages that microsoft has deigned to grace with its direct attention. for anything else, you're SOL; the plugin ecosystem is pretty limited for VS. the more VSCode reimplements plugins "natively" (isn't it all JS anyway?), the less it has a reason to exist.
The big thing with Jetbrains is the cost. PyCharm is $9-$25/month and VSCode is free
And then, despite automatically identifying the local python venv, install the linter elsewhere so it doesn't work.
But it integrates it wonderfully when you install the linter yourself, or if you use the bundled pylance.
Careful with the Remote Development plugin. It does NOT have an open source license.
Absolutely everything we use has non-opensource components, unless you try to pursue the path of a purist.
This is really frustrating. Am I doing something wrong?
Note that a new extension, that works alongside the original python extension, has been developed by Microsoft: Pylance. It speeds things up based on pyright, a python type-checker.
For refactoring you can use rope [0] as a VSCode extension.
[0] https://github.com/python-rope/rope
However, I was also having a lot of trouble with environment variables, especially PYTHONPATH. How do you solve that?
Also rope did NOT work well for me. When I tried to refactor (rename) a function definition, it also changed variables in unrelated scopes that had the same name and were not related to the function at all. So I did not gain anything from that which I couldn't achieve using CTRL+F replace.
I haven't used rope extensively, it's too bad that it doesn't work well. It's open source so I guess it needs more contributions.
“Rope is not installed. Install?” - so I need a package in my virtual env just to rename variables?
“Rope is installed. Refactoring failed”.
Then consistent and integrated IDEs are a mix of “everything and the kitchen sink” and “our way or the highway”
Personally I prefered to pay the price of an ugly and patchworky workspace to get something that works like I want to work and without too many things I don’t care about.
It's also about type hinting, refactoring, debugging, etc.
And for the two languages you speak of it just so happens that the support is shipped with VS Code since Microsoft is heavily invested in the development of these languages.
For other's (even Python) support varies widely.
Then you do not really need to install any plugins. Problem solved!
JetBrains IDEs are development environments, meant for editing code, in specific primary language. They really try their best to understand code that user works on (which is a hard problem, because code is frequently invalid while it's being actively edited), and make it as convenient as possible.
VSCode is - in my understanding - essentially, a step over older glorified extensible notepads on steroids. Unlike those older extensible notepads, it does have built-in programming language editing features, but mostly it's still not the core product but rather a job for extensions and language servers to fill that niche.
So for me VSCode wins over editors like Sublime or Atom, that don't have core programming language processing concepts baked in, but still loses to the specialized IDEs where specific language support is a primary feature (like PyCharm or GoLand).
VSCode does not get that kind of love, it is marketed differently and has different core values.
I've used RubyMine and IntelliJ. IntelliJ kept me sane for the thankfully-short time I worked with Java, and I appreciate it. But I can't get past how SLOW RubyMine is. Even on my $4,000 MBP, it just feels sluggish. Maybe that's because I'm at home on Rails, and I can think faster than the IDE, but there's really not much excuse to my mind for being that slow, especially on top-end hardware. It once helped me debug a plugin of plugin of a gem, and I'll be forever grateful for that, but I keep trying it every so often, and failing to part with my cash for it. I pay a lot for software, in general, but that one's just too steep for my taste, when tools like vim, Sublime, and VS Code exist.
I work on a stack that has ruby on rails on the backend, javascript on the frontend, .NET Core apps to do data transformation, and some NodeJS thrown in there, too. I have to switch back and forth between these projects regularly. There is no other tool like VS Code that provides me the flexibility to have snippets and highlighting and the things I need to maintain these projects, while also giving me the flexibility to switch between languages and syntax on the fly without having to wait 20 minutes just for the IDE to load up.
Java, Python, Go, Terraform, Bazel, all in the same IDE at once. Best in class refactoring for all of them. Handles the monorepo surprisingly well (Bazel is a big help here, too).
I had to bump the memory a bit on the IDE, but after hundreds of thousands of lines of code the index gets large.
I used to use VSCode heavily... Emacs before that. But now with IntelliJ I don’t really need much else. The plug-in ecosystem is really nice too.
This is why my experience with VS Code reminds me of Eclipse.
You don't start using Vim as an IDE. It's a waste of time, because like you said IDEs offer a complete product right off the bat. You start using Vim as a text editor, for text editor things, and when you're familiar enough with Vim's plugin ecosystem you may start to enhance your text editing experience with IDE-like features. And you may come to realize that's all you need.
Learning Vim for the sole purpose of tuning it into an IDE is a terrible idea no matter how you slice it. I blame people who hype their Vim setup as a complete IDE even though they started learning Vim as a text editor, not an IDE.
Its predecessors were in order Emacs + single-language IDEs + proprietary IDEs, then Eclipse and finally IntelliJ IDEA CE.
Emacs lost because it failed to update to reasonable modern conventions and because it used a niche programming language.
Eclipse lost because they released a bunch of different bundles instead of a single install (apparently because the contributing companies saw Eclipse as a common base for their proprietary IDEs), it was slow for the time, and had a bunch of unnecessary UI complexity (e.g. it had an unnecessary perspective system that would change the IDE layout depending on language, meaning that you couldn't just customize the IDE and have it apply for all languages, but had to customize each perspective).
IntelliJ IDEA lost because only the core was open source and major parts were proprietary, resulting in reduced 3rd party confidence.
VS Code is winning because they have a major company backing it that mostly doesn't seek to make proprietary IDEs with it except for minor proprietary aspects, uses the most popular language for extensions, avoids unnecessary UI complexity and is also fast and technically good.
Before VSCode the king of this was Eclipse. It was free, so it was everywhere, used by a plethora of companies. 2012-2015, when I was using it for vanilla Java development, knowing it let me get up to speed quickly on the Scale IDE, JBoss development from Red Hat, Mulesoft's MuleStudio, Teiid database virtualization, and Salesforce's IDE. VSCode is taking it's place, IMO; Salesforce has switched to it for its IDE.
2. They like a more lightweight editor. Being able to configure anything relatively easily if you know what you're doing would probably also fill into this.
3. People who primarily use keyboard based navigation and like not having to move their hands as often. I count myself to this group, as I recently discovered doom-emacs and absolutely love the keybindings it has. (vim keys for navigation. Functions are handled by the spacebar and a key combination)
[1] https://github.com/microsoft/vscode/issues/86671 & https://github.com/microsoft/vscode/issues/1012
It's been interesting to watch some of the UX patterns popularized by the editors mentioned in the article creep into Xcode, though. Again, I dislike some, but I'm glad to see evolution taking place, and I need to repeat a mantra I've said many times: "always be learning." That's the only way to remain successful.
I don't actually use a ton of VSCode plugins, but I'll give a shout out for GitLens. It is magnificent. Big thank you to the maintainers.
People said a UI based on web tech was backwards and slow. Turns out it os at least fast enough and enables cloud IDEs that can run in the browser.
That said, I tried Nova from Panic (https://nova.app/) the other day, and the native app performance makes a noticeable difference. I know it's doing less, but I can still search the codebase quickly and the resource use is like 10% of other IDEs.
Most alternative Jetbrains IDEs like Rubymine and Webstorm are just Intellij with a predetermined set of language plugins.
I have Ruby, nodejs and related plugins installed into my Intellij and it works exactly the same as Rubymine or Webstorm.
[0] - https://github.com/neoclide/coc.nvim
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
Let me guess, Theprimeagen?
While Fugitive is very good, I've yet to find a better Git client than Magit, that's actually one of the things that make me reluctant to switch to Vim full time.
> GitHub’s Codespaces also run VS Code as a web app, this time by spinning up an ad hoc development environment.
This probably can be the first time we'll see people use online code platform for real.
Think you nailed the most salient point, quite curious in the corporate battle of wits on Twitter, HN, and other venues. Since HN rules discourage meta discussions, I'm gonna stop here.
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
Especially since it seems VSCode manages those connections better.
It's ok to admit your favorite tech has flaws, everything has them.
With VSCode on the other hand, I have no issues at all: couldn't even tell the project was remote.
I still use emacs (emacs -nw via ssh), but it's nowhere near VSCode's responsiveness and now I cant use GUI emacs. It's definitely a source of frustration :/
This is cool when the machine you are connecting to is more powerful than the one you are sitting on. This is far less cool when the machine you are connecting too is less powerful than your desktop (RPi or Beaglebone, for example).
This uses SSH and SCP to automatically deploy the code to the remote environment and run it with the interpreter on that machine, rather than your own local laptop/desktop. One advantage is that it does not require any special software to be installed on the remote server. I believe VS Code's solution requires a pretty hefty installation consisting of basically an entire copy of VSCode onto the remote server.
The downside of JetBrain's approach... I believe that it requires a local copy of the files in order to perform the "LSP"-like syntax error highlighting / suggestion functionality that JetBrains software is so lauded for. This could be difficult/inconvenient if your codebase is particularly enormous, or if you aren't allowed to mirror it locally.
However, given the amount of support that JetBrains has for this kind of setup, I wouldn't be shocked to see an additional option for something more in the style of "VS Code Remote Development"
0: https://www.jetbrains.com/help/pycharm/configuring-remote-in...
A FOSS build is available at https://vscodium.com/
By packaging it as an extension that isn't licensed like the rest of VSCode.
Also on a related note, if you're using an open source build of VSCode (such as VSCodium) then you cannot use marketplace.visualstudio.com/
https://github.com/VSCodium/vscodium#extensions-and-the-mark...
https://github.com/VSCodium/vscodium/blob/master/DOCS.md#pro...
They want Theia to be a tool to build your own editor and it can be built as a hosted solution (like code-server) or a standalone editor
Edit: I see that the article also mentions Theia but this point about Theia vs VSCode is not mentioned.
[1]: https://theia-ide.org/
You can do something similar with IntelliJ by running npm inside a Docker container with your working directory mounted into it. IntelliJ will happily index the resulting node_modules folder without executing any code on the host.
With remote, I am able to do all coding on a non-infested Linux server with almost seamless usability.
[1] https://github.com/nikaro/devc
Imagine placing the workspace at the root directory of the entire Android source tree, pressing ctrl + shift + F and finding anything in less than a couple of seconds. For C/C++ code, press F12 just ANYWHERE on the code to go to the definition, no matter if it's the entire kernel code, or vendor or AOSP code: it just finds the definition at lightspeed.
For building I use the integrated console. If there is an error or a warning anywhere, you can just click on the console an it takes you to the file with the error/warning. Also it integrates perfectly with Git and has extensions to parse DeviceTree files.
And everything was just much more appreciated while working at home during pandemic.
It sounds like a testimonial advertising, but it's the way it is.
"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
When I used Rider at my last job, it would pick good auto defaults that you could customize based on the project configuration, including automatically generating IIS express configuration values.
Are there more explicit downsides you can mention?
JetBrains' IDEs have built-in update managers. They present you each plugin, giving you a tick-box of which ones to update. The Toolbox app manages the IDEs, allowing to update automatically or not, install pre-releases, and roll back. It's polished.
The IDEs use the established desktop UI norms of toolbar menus.
They come with pre-defined 'Run' templates for many languages/frameworks.
There is a single Event Log for output of updates etc.
The left menu has words so I know what the icons mean, and isn't obnoxiously large due to over-use of large icons.
For me, Emacs is not perfect, but it has always been the most versatile software I worked with. It's very much (and I want it to really be) the everything text editor. I got the interaction model (with a few good modes) burnt into my brain. I find it hard to get used to anything else (I usually also end up installing plugins to emulate Emacs in other editors/IDEs, but they never as good as Emacs itself.)
VSCode does get a lot of things right out-of-the-box: the interface is snappier when doing things like code completions and language plugins are rather consistent with little effort. But that's where it stops for me. At least I understand its popularity.
I'd expect the next uber popular editor to be optimized towards completely different things, though. VS Code is a great all-purpose IDE for enthusiasts and professionals, who are willing and able to dig into pretty complex UIs and complicated concepts. Take the git integration – it frequently breaks (for me), and when it works, it's really very superficial and requires me to really understand what git is doing in the background.
Last year I've tried to teach my dad how to use git, so he can put his python robotics projects in GitHub. It's been eye-opening: All the idiosyncracies and complex ideas that I've grown accustomed to over the years, that's one Eiger North Face of a learning curve if all you want to do is get those Python files on GitHub and have some people collaborate with you there.
It's also pretty hard to discover functionality in VS Code. It wants to be everything to everyone, so it can't expose functionality in a way that specialized IDEs can – and even those tend to be either messy or sort of cryptic. It's really hard to be effective in any IDE without memorizing dozens of keyboard shortcuts, which isn't a problem for software people, because we either like this, or have grown accustomed to it. I guess that's why the Touchbar is wildly popular outside of software engineering and related disciplines – for apps that support it, it exposes functionality directly and in a context-sensitive manner.
Hundreds of millions of people around the world will start programming in this decade as the world is rushing into a future where code is the stuff that most of anything outside pristine wilderness that we ever experience, is at least partially made of or faciliated by, that all social, economic, political activity rests upon.
There is no tooling that would be appropriate for this kind of use case – whatever will end up filling that niche, the casual programmer who doesn't want to get deeply involved with software engineering, but get their semi-complex problems solved without tasking a team of SWEs, whatever will do this will have to be a lot cleverer, easier to use, more discoverable, more intuitive – make collaboration feel much more seamless – and still be very powerful. VS Code with its laser focus on the current developer crowd is probably not very well-suited for this.
Curious if you use the command palette much? It should be a decent replacement for route memorization of keyboard shortcuts: How do I format this document agian? Hm... F1;form;enter done. And git push? F1:gpu;enter. Etc.
I work on vs code and am trying to improve this area so all feedback appreciated!
Yes, definitely (I use Cmd-Shift-P a lot, which should be the same thing? I also use Sublime so that shortcut being the same is valuable), but more for things I need to do relatively rarely, as it's an order of magnitude slower than just pressing the respective key combo, plus requires some mindspace (what would I best type to find this?) – so it's not a complete substitute, but still extremely helpful. I'm not sure how I'd manage without. But, say, toggle comment is something I'd rather not do via the command palette, though, too slow and cumbersome, breaks my focus. It's not that great for discovering functionality, either ("autoformat" doesn't work, but might be the first search term I think of, etc.) – but it really helps with all the things I know are possible but that I use too rarely to remember a shortcut for.
I really like what IntelliJ is doing with the Mac Touchbar – that comes much closer to a substitute for memorizing (some) shortcuts for me. Cursor in a class definition, pressing shift gives me "Rename", "Change Signature", "Move Class", with Cmd pressed I get "Show usages", stuff that's somewhat context-sensitive and actually useful, though there's still lots of room for improvement, lots of useful functionality that isn't exposed that way, there could be more context-sensitivity, but it's a good start. It's something I miss a little when using an external keyboard or VS Code (which doesn't seem to support the touchbar yet). I have to look at the thing of course, but then it's right below the screen, so its not like staring at the keyboard while typing, and being able to "just do" these things without any memorization is nice, a little bit slower than shortcuts, but it doesn't break my focus nearly as much. No idea how one might offer something like this on devices with no touchbar, but I think they're on to something there, especially for people who spend only a small part of their time inside an IDE.
Good to know you use command pallet, I agree that it's not as fast as keybindings, but in my opinion it's a good way to learn about keybindings for future use -- if I search the same thing on the command pallet often enough, eventually I'll look over and see what the keybinding is.
I agree more touch bar functionality would be nice, though you can add that through extensions if you're really interested.
> No idea how one might offer something like this on devices with no touchbar,
What you describe should almost all be available by default via the F-keys already, which is nice because it works across all keyboards without needing to learn new stuff. I personally have by touch bar show just the F-keys when I'm in VS Code.
The extension API is underdocumented. It's very difficult and time consuming to onboard yourself as an extension author with just the MS docs, since they don't cover the entire API and the vast majority of data structures are undocumented entirely. This is really annoying when functions take structures as arguments and have optional fields. Descriptive naming isn't descriptive if it describes how the argument is used by the callee, not what it means to the intent of the caller.
VSC also inherits the core weaknesses of Electron. Not overall performance/memory so much as startup time (just a second ago I had to wait 3 minutes for VS Code to boot because I had too many workspaces open when my laptop's battery died on me). It can't open multiple windows in the same workspace (this is actually a fundamental flaw when debugging any kind of extension that needs to open its own workspace). It's possible to build an extension that uses compiled node modules, which is great for performance and usability, but it's officially unsupported because those modules are only compatible with the node version of a client's VSCode.
But when all is said and done, VSC has shown that it's a great platform and easy to target as an extension author (or easier than others), LSP and DAP are huge milestones, and the architecture itself is just so friendly to extension that it's created a fantastic and lively ecosystem.
But petty gripe: please kill the git username/password fields when I git clone a private repo over HTTPS in the console. I don't like being aggro towards what other devs find cool, but I think hijacking a CLI with an extension incredibly annoying. And I can't find a way to disable that specific "feature" without disabling all of the git integration, which I use all the time.
Is this actually a problem, though? I typically use VSCode as a "focused" text editor; it's for working on a codebase for a long period of time (relatively speaking). A minute or do startup amortized over hours of work is not much of a bother really.
For quick edits, vim is still my go to. Different tools for different needs.
We'd love to hear more about the lack of documentation you're referring to. It's definitely a solvable problem. Could you create an issue so we address the problem? https://github.com/microsoft/vscode/issues
Also on
> But petty gripe: please kill the git username/password fields when I git clone a private repo over HTTPS in the console. I don't like being aggro towards what other devs find cool, but I think hijacking a CLI with an extension incredibly annoying. And I can't find a way to disable that specific "feature" without disabling all of the git integration, which I use all the time.
This can be disabled with the `git.terminalAuthentication` setting.