I find this post along with the comments in "A Picture of Java in 2020" https://news.ycombinator.com/item?id=24551390 to be incongruous with my experience as a professional developer.
My first couple of years writing software I used Vim, then VSCode, then worked in a Java shop and was forced to use IntelliJ. I didn't like it at first, but now after a couple of years I cannot see how I lived without it.
The idea that VSCode is the future doesn't seem right to me. JetBrains products allow you to do so much out of the box, without installing a million plugins that may or may not work. In IntelliJ I can write a half baked statement like `new Foo()`, and then Alt + Enter my way to it being `foo = new Foo();` as a private member variable of the class in no time. If you take time to set up configuration it becomes even more powerful. Even these basics are more difficult in VSCode.
To me the future is IntelliJ for Java and all other languages should seek to have such a nicely integrated experience with an IDE.
I am not even sure I could write Java from scratch in Vim - its really that I'm using IntelliJ, not writing Java. Is this bad? In some pure sense, sure, you are further from the language. But I don't care because I can write and edit code some multiple faster than if I was in VSCode.
From my experience out of the box you get poor performance and you have to spend a lot of time figuring out how to change configuration to improve it as knowledge is scattered in many places and not always up to date. Then it still likes to stall from time to time or sometimes doesn't register key presses properly. It's a poor user experience, but even worse is that alternatives are often worse.
I wish there was an editor with low latency, smart search, some proper file system database, so it doesn't take ages to open a directory and built in VCS support, that works quicker than manually issuing commands in a terminal.
I think the success of VSCode is because you can easily open it in your current directory from the terminal and it will show you your folder etc. without having to setup a project first and that you are ready to type you code quickly after opening. If I had to open PyCharm every time I want to try some Python in a new directory, I would probably start questioning my life choices. Before VSCode I would just use nano or Sublime.
JetBrains products _are_ pretty much the best. I think Android Studio + Kotlin is the best, most impressive IDE experience I've ever had. Mostly because Android Development in general is kinda hard, and Android Studio cleans it all up so nicely for you. It really outshines XCode in this regard.
I've never used CLion but I really want to.
That being said, I think it's clear that VSCode is, and will remain, dominant.
First: its free.
Second: it's simpler.
That alone is enough to make any product dominant. The fact that's it free, simple, and pretty much just works is pretty stunning.
VSCode for Unity Game Development kinda shocks me how you can literally install the IDE while the game is running and successfully attach a debugger. It's pretty wild how reliable it is.
I'm not a VSCode fan boy. I find that it lags on my PC sometimes. I kinda hate the "notifications" that it pops up with. And I don't like the auto update mechanism or the Welcome screen, but overall VSCode (or Codium) is clearly the next level of IDE.
I think Microsoft is going to build some really wild stuff on top of VSCode and Github.
I think there gonna come up with way to leverage the amount of data they can mine out of github repos to write code for you.
I'm pretty sure that's a big reason why they bought github.
Well, I think you're right about performance being a problem, but I have 64 GiB and a 4790k and an NVMe SSD. It's like half a percentage of my pre-tax income and was even less when I bought it.
I don't need efficiency. I need something that, given fuel, gives me power. And as someone who has donated to vim, was an early backer of neovim's bountysource, and loves his terminal: vim is my ion drive, IntelliJ and friends are my conventional rocket.
> From my experience out of the box you get poor performance and you have to spend a lot of time figuring out how to change configuration to improve it as knowledge is scattered in many places and not always up to date.
I don't know if you are talking about IntelliJ or VCS, but IntelliJ can quickly start an empty project. And you don't to spend time to figure out how things work. I mean, there is literally no entry barrier for a bare bone project.
> I wish there was an editor with low latency, smart search, some proper file system database
You are describing an IDE here. Smart search and a proper file system database, it means operating not on a collection of text files but on a project and a code tree, which is the main difference between IDE and Editor.
> I think the success of VSCode is because you can easily open it in your current directory from the terminal and it will show you your folder etc.
I see them as complementary. VS Code shines if you’re jumping between independent codebases for distinct projects, and startup time matters.
But my startup monorepo I keep loaded in IntelliJ for days at a time and have never looked back. For the 1% of time it’s laggy due to a JVM GC or background indexing, the other 99% of the time it’s immensely productive to have e.g. full-stack debug breakpoints that Just Work, well-designed customizable gutters, integrated linting, and more.
IntelliJ isn't really the IDE for dicking around with ideas. Projects or not, it's just too fat. I am an IntelliJ diehard myself and I usually have a copy of Sublime Text open as well, usually to use it as a scratch space, to peek at logs or somesuch, or for playing with code that isn't quite yet in a runnable state.
> From my experience out of the box you get poor performance and you have to spend a lot of time figuring out how to change configuration to improve it
This hasn't been my experience of JetBrains Rider at all - granted that startup does take a few seconds, but after that it seems to fly.
> Then it still likes to stall from time to time or sometimes doesn't register key presses properly
This was my experience with Visual Studio; I used it for over a decade because it is a great IDE - but performance and stability has never been great, and eventually I just couldn't stand the occasional lag any more and jumped ship to Rider. My experience there has been very different - it's rammed with at least as many features as Visual Studio, but has been rock solid, and never lags in use.
The main reason I use VS Code is I tend to work on a lot of mixed-language development. I often have Python, rust, custom DSLs and C++ in the same code base with a custom build system. VScode gives me the flexibility to use all of them to their fullest potential without needing to support the build system.
That being said if were to use Java I would probably not move away from intellij. Last time I tried clion though it was a disaster.
In IntellIJ you have scopes, where you can narrow down the project view to a set of folders, which is useful if you work on monorepos. Scopes affect not only the project view but also file search.
You can disable plugins you don't need, and mark folders as excluded if you don't need them indexed, that makes it faster.
As someone who uses all three of the editors you named, I think that each serves a pretty different purpose in practice. Each aspires to be the be-all, end-all editor/IDE, but that's just unrealistic to me.
For me, I use VIM all day, every day at work (C++), because while it doesn't have the full IDE experience out of the box, it's close enough, and can be brought much closer with various plugins and knowledgeable adjustments. I've stuck with it because "it just works" and I'm use to it. A previous colleague was a big VIM evangelist, so got a running start from him, and now I've tweaked it enough that it works well for me.
VSCode is my general purpose text editor at home. If I'm writing markdown, or fixing some script, or I just need to see what's in that file, I'll use VSCode. It is the obvious, far superior replacement for Notepad, and has plenty of niceties to make it that much easier to use.
But if I'm building something with a lot of moving parts in one of its supported languages, I'll use IntelliJ. I don't often write Java these days, but PyCharm is just a reskin for Python and I think it's great. It does so much junk for you, and it makes testing and debugging so easy. It does trip up my muscle-memory occasionally, but for the most part it's a powerful tool that's great at what it does.
I use vim primarily for around 9 years now, and with ALE as a linter plugin it's integrated with languages I even don't know existed until I need to fix something in it in a foreign codebase.
If I need to go typescript or web, vscode is very tightly integrated with the build toolchains, so the occasional fix in vscode is necessary for me when I need to fix a bug upstream.
I tried migrating to neovim a lot of times, but their syntax highlighting is always so damn broken even with a plain vimrc that I stopped bothering anymore.
Currently, I'm trying to migrate to kakoune because I've heard a lot of nice things, and the ecosystem seems to be better integrated with lsp and rust, but honestly my muscle memory is damn strong, so it's actually kind of a burden at the moment and I'm gonna need a while if I keep pursuing this.
One benefit though that both emacs and vim have is ssh usage. Debugging and reading logs on a remote server is pain sometimes, and my vim profile eases that sooo much up that I saved a shitload of time by using it.
I couldn't stand VScode when I tried it. To be honest I didnt even get it working properly for C development. Visual studio on the other hand is awesome.
IMHO, the main stopper for vim/emacs to go mainstream is lack of packages for preconfigured flavors of vim. E.g. `dnf install vim-perl -y ; vip myprogram.pl` or `dnf install vim-c -y; vic myprogram.c` .
I used to use Intellij for everything (and I'm not even a Java dev). It is indeed very nice and comes with so much out-of-box around languages and popular libraries. However, Intellij is _sooo_ very slow to load and edit with. This is more tolerable if you work on one project. But in the past couple years, I've had to work on many smaller projects, and loading up Intellij for multiple projects meant gigs of RAM disappearing, along with that sluggish start time wait for each project and slow editing.
I really loved Intellij and I wish it could be made to run more efficient. VSCode fills the niche of "loads fast, moving around code is fast, and I can have many instances open at once without crushing my computer"
I guess it depends on the type of project you're working on, but I think these tools still serve separate use cases.
Hardware can fix that. I'm on latest MBA but I see no problem with performance. Recent hardware does have gigs of RAM to waste.
Once IntelliJ is running, which takes less than 10 seconds, projects open instantly. Probably even better on desktop machines.
Frankly VS code isn't good enough yet. It's the best if isn't for JetBrains but for instance, SQL queries are still just a string (unless I've missed the obvious plugin to allow me to auto complete column names and such according to the live database schema) but IntelliJ can highlight, auto complete and check errors once I register my database (also through ssh tunneling).
I do like VS code being faster but feature wise, I only use it to edit server config files through sftp plugin.
In 5 years, maybe JetBrains might feel pressured from competitors.
But it's only less than $15/mo if you pay annually and from 3rd year for their all products pack.
Are the projects related? Or all unique? If related, you can create a uber project and import each directory as a module. I’ve got a project right now with 5 modules - 2 JS, 1 Go, 1 Python, and 1 Ruby (Rails). I’ve found this keeps memory usage down.
Fancy IDEs are lubricants for high-friction languages. If a language is already low-friction, there won't be much benefit to be gained from an IDE, as even a plain text editor will already get you near to optimal productivity in said language.
Personally, I'd rather use a plain-old "code editor" (with at most syntax highlighting, but no snippets, let alone autocomplete), in part because doing so will actively steer me away from languages that weren't designed with the User Experience of writing them in mind.
Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately hold and swing it. That'd be a bad hammer, right? Hammers are hand-tools; it's an expectation that they'll work when used "manually", i.e. with raw human capability alone.
Programming languages are hand-tools as well, in an essential sense. Like mathematics, the "interface" through which we manipulate a codebase is plain, raw text — sequences of symbols. We humans understand source code by reading it with our eyes; and then we write or modify it by editing it the same as any other text. We can do the whole thing on paper, or a blackboard, or even purely in our mind's eye. That's kind of the idea behind having a source code representation of a program in the first place, divorced from a machine code representation — to give us humans a formalism we can intuitively handle. A programming language is something you can think in.
Seen through that lens, a programming language that requires the cybernetic prosthesis of an IDE to read and write it fluidly, is a bad programming language. You don't have an IDE loaded in your head. So how will you think in it? (Usually: by thinking in a vague pseudocode instead; or even, by thinking in a different language than the one you're writing in. Obviously, this is going to be lower-productivity than coming up with a mental model of the problem that can be directly typed into a computer.)
(Before anyone makes a supposition about my language biases: both "complex" and "simple" language designs can be inherently high-friction due to their design choices. Scheme has very little syntax, but it's also high-friction, in that it's easy to get lost in a sea of parens unless your editor helps you along with a feature like Emacs' paren minor-mode. Most modern code editors do have something like that, but it's still a form of lubrication to overcome a point of friction in the syntax; one that some of Scheme's linguistic siblings—e.g. Clojure—avoid by increasing syntax.)
> Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately hold and swing it. That'd be a bad hammer, right? Hammers are hand-tools; it's an expectation that they'll work when used "manually", i.e. with raw human capability alone.
I remember people making similar arguments when cars started to have power steering.
> Programming languages are hand-tools as well, in an essential sense. Like mathematics, the "interface" through which we manipulate a codebase is plain, raw text — sequences of symbols. We humans understand source code by reading it with our eyes; and then we write or modify it by editing it the same as any other text. We can do the whole thing on paper, or a blackboard, or even purely in our mind's eye.
I disagree; programming languages are primarily tools for programming on computers, and expecting them to be skeuomorphic to a particular approach may hold us back, just like expecting a CAD program to work the same as a physical drafting table or expecting a rendering engine to use a TV-like fixed framerate.
Being able to push secondary parts of a program to be foldable, or visible on mouseover but not by default, makes it easier to communicate understanding to other humans. And actually that's a more faithful recreation on how you'd communicate in writing - on a blackboard you might use small text, or footnotes, or a verbal explanation. A mathematical paper is almost never "plain text" in the sense of being a linear sequence of ascii characters and nothing more. A language whose design embraces IDEs can be a better tool than one that flattens everything into the binary of written in the code or completely invisible.
Java doesn't have a lot of friction. In fact, IntelliJ is probably the closest you'll get today to the "golden age" of programming with something like Turbo Pascal.
Also, good luck doing major refactoring with a text editor. In 2020 we can do better than find and replace.
>Seen through that lens, a programming language that requires the cybernetic prosthesis of an IDE to read and write it fluidly, is a bad programming language.
>Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately hold and swing it.
You don't use IDE to be able to use language, you use IDE to increase your productivity. Instead typing whole for loop you just use shortcuts, instead of changing class name in 5 places you just change it in once. You save time.
>We can do the whole thing on paper, or a blackboard, or even purely in our mind's eye.
But do you remember that class `PurchaseHandler` has method `BegingPurchaseProcess`?
> Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately hold and swing it.
Ah, like a jackhammer? One of those huge ones attached to a digger they use to break open the roads?
It’s a right-tool-for-the-job kind of thing. Some roads can be mended with a shovel. Some need a jackhammer.
If you limit your development to “what a human being can hold in their head” you are artificially limiting yourself. The whole reason we use higher level languages is so that the machine can exceed what a human can hold in their head.
I haven’t used IntelliJ, but if it gives Java developers half of the refactoring options and shortcuts that JetBrains Resharper gives C# developers, it must be worth its weight in gold.
C# is the only language for which I have had to deal with large monolithic codebases.
For smaller codebases, I prefer VS Code. Especially now that I go back and forth between JS, Typescript, Python, and occasionally Go and Java. I’m also frequently editing yaml and JSON. Having one editor is more ideal.
All of this is fine if you don't work with others. The point of these tools is to standardize around something to reduce the cognitive load someone has to experience contributing to code that they didn't write. The amount of possible paths are commonly reduced for the reader.
Linting, snippets, autocomplete, are all things that prevent you from bending the nail or breaking off the head which makes maintenance harder for the person who has to find the nail and remove the nail. If I don't have to redo the nail, the cost of the nail and my time are also saved.
This is part of what led to me originally choosing Python in the first place so many years ago. I really liked Haskell but I found it hard to get things done with it. I tried to build out a large project in it, and with a deadline looming, decided to try building the rest out in Python. Python got out of the way for me and made it easy for me to "think out loud" -- perhaps this is what you mean by "hand-tools".
I was a lot earlier in my maturation at that point, but I still think my intuitions were sound. I like languages like Python which lack syntactic noise and make it easier to write compact self-explanatory things. I used to hate JavaScript but with ES7 onwards, I've begun to like it much more because it's easy to write compact, self-explanatory things.
I was forced to write Java for work a few months ago and rudely awakened in a painful manner. Yes, you adapt to it but deep down inside, you know that it sucks and you prefer going back to your better alternative.
I'm not sure what you mean by "Fancy IDEs", but if it's ones that integrate with the language (eg intellij) then I really disagree that there won't be much benefit. The main benefit I find with a good IDE is that it makes your typing follow the constraints of the scope you are in.
A string literal can be any sequence of characters so it's up to you to type them, but when I'm accessing members of a class, I'm not interested in being able to try to access a random string that is not a member of that class.
Re: your thinking comment, I also think it's the opposite. When the IDE follows the constraints of the language, it's more intuitive than when it suggests typing random strings everywhere is fine. That's not how a language works, and neither do I find it constructive to think that way.
It is certainly true that languages designed for simplicity (such as go, clojure, and to some extent python) exhibit far less friction when composed in minimal editors, than [overly?] verbose/complicated languages such as Java.
However, I vehemently disagree with some of your (implied?) points. In particular, some functions offered by IDEs and other codebase management tools are almost equally useful for both simple and complicated languages. For example refactoring tools, or if we really look at the stem, code-base analysis tools that 1. parse the language, and, 2. have APIs for modifications, are some of the "power tools" that could be useful for virtually any programmer.
As an IDE-averse person, I find myself reaching out for the simpler languages far more often, and do actively dislike high-ceremony systems. All the while, I am painfully aware of the limitations of using only a [good] text editor. My main alternative (to mainstream IDEs) is to context-switch between pure code-writing episodes and refactoring/analysis/etc. periods (using other tools, most on the command line or with output to a web-browser).
Also regarding your comparison between written programs and mathematics: I think that comparison is relevant ONLY for low-churn fundamental code (such as core libraries, or generic utility libraries) and rather poor in a LOT of "business logic"/"presentation layer" code. I myself play code-golf and run several _mental_ redesigns/refactorings when working on code that should be solid and not subject to frequent revisions. In such cases, yes, the code should be readable, well designed, and simple to follow (clarity slightly preferred over performance for the core). Nearly formal and exhibiting formal/math-like traits. On the other hand, "business logic" code is inherently unstable and could require numerous revisions purely due to external requirements. Such code usually shouldn't be optimized for tight simplicity. "the first thing that came to my mind"-level clarity with comments can suffice. Common IDEs do help with the latter type of code (while, I think, not much with the former).
Beside serious analysis and modification tools, there is an extra set of features provided by many IDEs, such as lookups (lookup function/library/etc. initiated while looking at code), autocompletion (based on parsed code or just string matching), etc. These are certainly nice, but I don't think they change the landscape much between IDEs and plain text editors (or rather, editor-and-a-documentation-lookup-web–browser-on-the-side).
So, for me, IDEs are certainly valuable even if I don't use them frequently. In a more ideal setup, I would write my code in my preferred editor without much hand-holding and with just the simplest of IDE-like features. And then, separately, do codebase "polishing" with dedicated analysis tools that may or may not look like conventional IDEs.
While editors like IntelliJ are definitely more polished out of the box, something that may not be apparent is that internally they are all standardizing on tooling and protocols put in place by VS Code in the last few years.
Language toolchains are now expected to provide IDE-specific features on their own (by implementing a language server), and so IDEs themselves don't need to focus on making the language better. So the biggest sell of IntelliJ, reSharper etc. won't be relevant for too much longer, since every editor can (or will be able to) e.g. understand Java and provide basic fixes and refactorings.
In practice we're pretty far from that. Most statically typed languages, even fairly recent ones that took on LSP compatibility early, are still better supported by JetBrains' IDEs.
Most language toolchains are held together by small teams of volunteers or corporates (Apple, MS) that sell their own IDEs. They struggle to provide even the basics like solid fast compilers, portability, debuggers that aren't gdb, profilers that work and so on. Look at Go, Rust, Swift. All of them are fighting with basics like performance and language evolution. And now you want them to implement most of an IDE as well? How will they handle that? The only real exception is Kotlin (by JB!), but that was possible because the compiler and IDE plugin are a unified codebase and because they built on the JVM, so they get top quality compilers and profilers, portability layers etc for free.
The key to JetBrains' success is not any particular software architecture, although having language analysis plugins run in-process with direct access to AST structures is an obvious advantage, it's that they're a company that charges money for their tools, which has kept their cost overheads low (very low relative to never-profitable SV startups that snort VC capital like party hounds), and which are building on an already very productive platform to begin with (Java).
This combination means their feature throughput is very high but more importantly, sustainably high. They've been doing this for 20 years and aren't about to hit a tech debt wall where they suddenly need to rewrite their product from scratch.
Contrast this to their primary competitors, Microsoft and Apple.
Visual Studio has a comparable feature set to JB IDEs. But it's Windows only, totally un-portable, hardly supports web dev outside of the .NET stack, and the plugin model is native. They badly struggled with the transition to 64 bit because of this, which in turn meant users regularly hit its internal architectural limitations like project size limits (cuz of the 32 bit address space). VS doesn't scale well because there's no good way to stop plugin crashes taking out the whole IDE. Even though MS have been pushing .NET for 20 years, VS itself doesn't use it. IntelliJ built on Java which hurt them in the early days, but now Java's perf issues are mostly solved and they benefit every day from portable plugins, a seamless 64 bit transition, cross-platform portability, etc.
XCode is under-funded, has very few plugins and can't compete for any task outside of Apple's own ecosystem. It doesn't even try, really.
VSCode is a text editor with plugins. It is at least trying to compete with JB, but I don't forsee much success in the short term, especially if JetBrains pull their finger out on light mode. It at least uses managed languages. But the most mature JB plugins have been developed over a period of decades by now. The feature-set is overwhelmingly huge, and they have hundreds of employees that do nothing else but add them. How much money is MS willing to throw into the VS Code project? Its lack of revenue model limits them, even with a sugar daddy funding them. It's unlikely they can scale to JB size because a free IDE that competes with their own revenue generating VS product is simply not something they will tolerate long term. VSCode is going to be stuck focusing on the JavaScript/web stack for a long time and won't receive a lot of funding to grow out of that.
Other replies have expanded on this quite a bit, so I'll just add my 2 cents:
When using a strongly typed, object-oriented language like Java or C#, Jetbrains tooling, namely the intellisense and refactoring is well-worth the cost.
However I'll still spin up VSCode for most all other languages since the tooling advantage diminishes when using a loosely-typed language like JS or Python.
Also consider that VSCode is free compared to Jetbrains, and the tooling is "good enough" for most cases. Even the C# tooling is passable with the right plugins.
I write Java in vim all day and it's fine. I'm also one of the top code contributors in my org by any metric (LoC submitted, bugs fixed, tech debt reduced, etc.) And everyone else uses IntelliJ.
You devote time to learning your tools and improve the efficiency of the parts that matter, and the tool itself becomes mostly background.
THIS ! As a "professional" you owe it to yourself, to spend some time and actually learn you tools ! Not just "how to get by" but actually schedule time in your week to learn about the tool ! Shortcuts etc !
Conversely, I always hated the bloaty, intrusive ReSharper on VS.NET, and find IDEA very much nicer, even though C# is more naturally ergonomic than Java (but less ergonomic than Scala).
I tried out vscode for python now that I started a new job. I'm on linux for what it's worth. The experience has been massively frustrating coming from pycharm. First I installed the open source version, and found that microsoft publishes plugins that are programmed not to work with the open source version. They don't tell you this, rather, the plugin throws exceptions that some API is missing. I tried out the official version, and instead of whining about not being supported, it now just crashes intermittently. I gave up less than three days in.
I found configuration of code to be pretty annoying as well. Either you write json, having to google for things like how to format keyboard commands, or use their (subjectively) ugly configuration page.
The fact that I can't detach the terminal from the code window without some weird workaround was also something I couldn't come to terms with. I'm back in pycharm again.
> JetBrains products allow you to do so much out of the box
It's all nice and shiny until it takes several minutes to index your whole project structure. Then you can only hate it a little bit more every time you start it.
VSCode is not bloated (for now) with millions of options, I can add extensions and/or disable them whenever I need without losing performance or even creating my own ones without too much effort.
The indexing is what matters. After that, IntelliJ knows pretty much all about your project files. It only takes a minute on first load and reopening it will only scan what's changed which is fast.
I doubt IntelliJ plugins slow down the IDE noticeably, though I do keep the number of plugins activated to minimum for only what I use.
> I am not even sure I could write Java from scratch in Vim - its really that I'm using IntelliJ, not writing Java. Is this bad?
What I see here is the IDE being powerful to make up for a lack of power in the language. Is that bad? Maybe.
I tend to think it's bad because tooling usually does less for making code easy to read than it does for making code easy to write. Furthermore, one of the few characteristics that seems to consistently predict defect rates is codebase size.
On the other hand, increased abstraction can also require more effort to read, and you'll get a lot more resistance in most projects to switching languages than you would to you switching your editor.
I agree, I used VSCode for Python programming, until I found Pycharm is better. I also used it for Go programming, but later found Goland to be better.
But what confuses me is that the article always references it as a "Text Editor", not an IDE. As a text editor it might be the best, but as far as I am concerned, I just don't need "standalone" text editor. I don't have usage for it. I use IDE for programming, and as far as writing text goes, I need that only for writing notes or software documentation, and for that I use Drafts app, Roam Research, or Google Docs.
But I am curious to learn how people use VSCode as a "text editor".
If you spend your entire day in a huge project with a ton of code and work together with a large team of software developers, you'll probably use an IDE. Your workflow probably involves launching the IDE once per day or even leaving it open all the time.
If you do mostly consulting work, small projects, switching between languages with poor IDE support (usually dynamic languages), you'll probably use a smart editor. You'll launch that editor multiple times per day, close it, reopen it, etc.
We should talk more about workflows, there are a ton of them and they're very different in my experience.
I personally use VSCode as a text editor in the sense that you describe. I edit my notes in VSCode with Foam, a similar tool to Roam Research. Similarly my blog is based on Jekyll and Markdown files so I use VSCode to edit those markdown files when writing posts. There are definitely cases where I use VSCode as an IDE for other projects but it works well as a simple text editor too IMO.
I'll add to your Java anecdote: JetBrains editors appear to be the most sophisticated across multiple languages. PyCharm is a pleasure to use with Python, Rust, and Typescript. Perks include catching errors on its own (eg before compile in Rust or TS, and don't even need to run Python's type checker), auto-complete, and refactoring. In comparison, VsCode appears to only understand these languages at a surface/syntax level.
I don't like this situation: I wish there were more competition, but it appears one company has the edge at present. I use VsCode for one-off files, since Jetbrains isn't a good fit for these.
Intellij is always too buggy and slow for me. Things it helps you with - it's a language verbosity problem. Ideally you should just use better language.
And they also stopped bringing any more advanced features, like refactoring from null to Optional for example, or reversing template method.
If we're talking about java specifically vscode and vim would just use eclipse language server which can do most of the things intellij can like refactorings and snippets. And for other languages like python ms language server is even better than pycharm for example.
I can't stand writing C#/Java in VSCode and I can't stand writing anything but them in Intellij/Rider personally.
It's a trade off between speed and feature set.
I'm glad it's one I can decide to make when and where I want to.
Hopefully one day a full featured IDE will be as fast as I want, but until then I'll be switching between VSCode and JetBrains products depending on what I'm doing.
My personal gripe with intellij is how unintuitive the shortcuts are and how much clicking is the default way of operating.
intelligent completion is something like cmd+mayus+space. "find usages" is cmd + f7 (which in osx means cmd + fn+ f7). The "open" dialog for opening a project doesn't even have a default shortcut, it's mouse based and will open a second dialog asking if you want a new window or just reusing the current one. CMd+mayus+f for global search wont work if my focus is on the integrated terminal, I have to click out of it.
I feel like I'm learning to play piano placing my hand in weird chord shapes constantly, and half those things launch an ui pane or menu that I practically need to navigate by clicking even if they sometimes technically allow some kind of keyboard interaction.
It's not like I'm an extreme vim+dvorak user obsessed with having everything in the home row at one button press, but a bit of thought into priorizing shortcuts and placing the common ones in comfy places would go a looong way.
shift-shift is the 42 of intellij editors, open files, rename things, import ordering, search class/function/method definition etc etc.
"shift-shift open" to open projects.
next time it will probably be "shift-shift o"
It also displays the actual shortcut.
Integrated terminal (and all other cases) switch focus to the editor: escape.
For all other cases: you are probably aware that you can change shortcuts. For example to vim shortcuts. Not 100% the same but still. And yes, switching editors take some time get used to.
(I love pycharm, i like VScode for small projects, dont like the un-integrated mess of for example spell check correcting function names?)
> JetBrains products allow you to do so much out of the box, without installing a million plugins that may or may not work.
The problem is that all I need is 2 or 3 plugins. If all I need is a golf cart I don't care that your Lamborghini is amphibious and can fly to the far side of the moon
People have written the same hype driven articles about Sublime, Atom and even IntelliJ. The same articles will continue to be written for whatever comes next. Just use whatever you feel makes you most productive. Having tried VSCode I ended up sticking with PyCharm/Goland.
Before all this, almost twenty years ago, there was JPad Pro another editor that I felt as close to as I feel about VSCode now. It didn't have plugins per se, but you could very easily script new behaviors into it. After that, there was a period of vi usage, before I adopted Sublime. The lesson for me is that VSCode too, will be superseded by something different.
it's not that simple is it? I've been programming for ~40 yrs. I've used a bunch of different editors. I certainly don't know each feature of each one but many features I find to be force multipliers so ignoring them is a disadvantage IMO. I'll be wasting my time doing something manually the could be automated for example.
Unfortunately it's hard to know how to configure every editor and know how to get these time saving features.
A few I get from VSCode (love to hear about other editors)
1. the best Javascript support via integration with eslint
Eslint's plugin system means I get react specific hints and error messages. I'm not used to an editor giving me library related errors. Usually they only give language related errors
2. codespell plugin
This only matters for dynamic languages but it turns out spell checking code can be surprisingly useful. The language it self can't tell me
Lots of people mention this but it's arguably a killer feature. I can't believe that it took until now for an editor to have this. Most previous editors I've used to had to go through the process of making some kind of project to get similar functionality. If I wanted to easily search and replace in a project across files I had to make a project or configure stuff. If I wanted it to find references to other files I'd have to make project or configure stuff. vsc seems to find these things with no work on my part.
4. pretty good file support (renaming and moving files, including the required code refactoring to go with it). Every IDE-ish editor I've used since the early 90s has had some kind of file tree panel but VSC's is the first one I use regularly for more than just opening files.
5. friction-less easily discoverable plugins
I think this is overlooked but consider the Apple iOS app store vs Windows CE. I could install apps on my 1998 Casio Windows CE PDA but it wasn't friction-less like the App stores today are. That difference is huge. Every editor I've used since the 80s has been customize-able but I rarely looked for other people's customizations. It was just too much work. Not only did I have to learn how to install them and get them to run I had to go manually find them. VSC suggests them. I get that can be annoying but given low-discoverablilty or a few annoying notifications I think promoting them is a net win.
That said, I hate that VSC is slow! I work on quite a few hobby projects where I just want to put all the code in 1 file. At about 1000s lines VSC starts acting up, getting janky (on a 12core 64gig ram AMD Ryzen 9 3900XT) and eventually I'm forced to split the file. Sure, better organization is good but my tools shouldn't be forcing it on me when I'm just making something throwaway.
I think the fairer comparison is with Visual Studio 2019, not Visual Studio Code. Visual Studio Code is free, making it highly attractive for a larger audience. The pricing for IntelliJ is not accessible: https://www.jetbrains.com/idea/buy/#personal?billing=yearly
I've also used IDEs that are highly optimized for Java and .NET. I agree it's great for the use case I had.
I have had the same experience. VS Code looks like a fine lightweight text editor plus a marketplace of plugins with variable degree of maturity and interoperability whereas IntelliJ is a mature and polished IDE.
All IntelliJ lacks is two things:
1. Being a lightweight editor with syntax highlighting which IIUC they are / have already built
2. Remote development where the IDE is just the front end running on, say, a laptop and the computation runs on a remote work station
I prefer IntelliJ to VS Code but for me IntelliJ also lacks the ability to:
Disable plugins on a per-project basis. (I currently put up with plugin exception reports for other language plugins in projects for unrelated languages.)
Enable or update plugins without a full restart. (This is getting better but many plugins still need a full restart.)
Sync all plugin settings (for example, AceJump plugin settings aren’t synced).
Split the terminal pane horizontally.
Open a file in a vertical split from the navigator or search everything box. (I want to believe I missed an easy way to do this; someone let me know if so!)
Set alpha keyboard shortcuts in quicklists.
Style the title bar colour on macOS to match the editor background.
Write a quick script to add missing IDE functionality without boilerplate or build tooling.
I can do all of these in vim and Emacs and most in VS Code.
They’re nitpicks and no editor or IDE is perfect. I think I feel the pain points with IntelliJ more acutely because for many of these I can’t fix them myself.
> The idea that VSCode is the future doesn't seem right to me.
VS Code is the future of editors, not IDEs or all developing.
There will always this two sides which live from the box and those who build their own box. And for the later VS Code is nowadays one of the best road to walk.
> JetBrains products allow you to do so much out of the box,
It's also very limited on where you can work with it. It works for the handful most popular languages they support, but what if you get a bit more exotic? What if need something non-programming, like markdown, rst or plantuml? What if I am not satisfied with a certain feature in the IDEs editor or workflow?
If your Box is not supporting it, you need to customize it, and there JetBrains is just not as good as editors like VS Code, vim, emacs.. And VS Code even goes to great lengths to gain the IDE-state of having everything out of the box.
Just wanted to let you know that all those file types have support. Markdown and rst via the official markdown plugin, and plantuml via a free(in both senses of the word) third part plugin.
IntelliJ is a much better experience than VSCode. Without leaving the IDE you can: edit (with autocompletion), static analysis, debug, test, code coverage, version control, profile. All using JetBrains official plugins.
I've switched between IDE's and "lighter" editors like Sublime Text and VS Code so many times now (and I can't get used to vim and co, I'm too young I guess lol).
IDE's helped me so much writing Java code; refactorings, autocomplete, code generation etc are features that never became as good in 'lighter' editors.
Then the JS era appeared, and IDE's couldn't really do much with it - in part due to its unstructured setup, lack of importing code, lack of namespaces. Autocomplete and jump-to-definition was non-existent. I switched to Sublime Text for web work, and relied heavily on the powerful and fast global search and cmd+p navigation for a good while.
Over time, things changed; JS got modules, JS got types (or type inference) through projects like Flow and Typescript, and JS got richer with e.g. JSX. Still mainly used VS Code (by then) for front-end though; heavier editors didn't seem to offer enough added value to warrant the switch.
But every time I did back-end work I would switch back to a proper IDE. Java / JVM languages are things I never did in a lightweight editor. Go (which I use as a back-end language currently) support was rough for a good while in both editors and IDEs, but it's getting there.
In my current job, I handle four languages over two projects; there's the legacy project, PHP and JS / Dojo, and the new one, Go and TS / React. I've fully switched to using an IDE again; intellij's JS / TS support is good enough, and honestly for the legacy codebase I need it. The codebase is nearly 10 years old, and the 'hip' editors simply don't support PHP 5 or 13.000 line spaghetti messes. But intellij does; I configured it for PHP 5.2 specifically (so if I use the shorthand array syntax it flags it up) and ES5, it struggles a bit but it can make sense of the huge files, and it helps me a lot in making sense of it. It's a safety net that the codebase and language itself doesn't give me.
VS Code and co wouldn't come close.
Anyway I still switch to VS Code from time to time for one-off tasks, quick edits, formatting, etc.
I'm using IDEA and VSCode in conjunction (for Kotlin and Typescript respectively) and I find them equal in power. Maybe I'm not a power user, but I reached a point where they even look the same (more or less).
There are 2 minor differences I experience very often: VCCode is blazingly fast compared to IDEA, and VSCode has much more quality plugins than IDEA (at least for those things that interest me).
I'd compare VSCode to Emacs in a sense that the architecture is really simple (all you have is functions that do something) which makes VSCode more appealing to prospective plugin developers.
I'd even go so far as to say that to me VSCode becomes the new Emacs.
Perhaps that is because of the very narrow focus on what IntelliJ does and the functionality of plugins is part of the core system of IntelliJ.
In my view, VSCode is a platform. It's unfortunate that they chose to use Node (its slow) but otherwise, its a great platform to develop extensions for.
For someone just getting into programming, it offers a great stepping stone and it can handle medium sized projects quite well.
The problem is, after installing bunch of plugins it is still no match for IntelliJ. If it was, why would I pay for it...
I want a plugin to parse the SQL query and do auto complete, check for syntax and column/table name errors according to the database I connect to through ssh tunneling but it's just a string in VS code. It also auto completes join columns by checking which foreign keys may match on the table I'm trying to join at the point of typing "JOIN [table name] ".
I want a plugin, so if I open a file, it checks the remote file and make sure it's not modified, so that I don't accidentally overwrite it in case someone has edited the remote file. (Yes, this sounds dumb but non programmers don't do like we do.)
Jump to definition should work like expected, reverse jump to uses from definition should also be there.
Formatting code with so many customizations on many languages including SQL, CSS with a hotkey or against a whole directory. Should the brackets go to next line or not, should there be spaces, should it be tabs or spaces etc. I see there's "prettier" etc but the supported languages and customizability aren't there.
My use case for the IDE should be narrower than others as I only use it for the web development but still it's a few miles ahead of VS code today.
But competition is good. I'm sure JetBrains may start sweating in 3 or so years when things actually start to be competitive but VS code is free and lighter.
Agree.
I am now working on a project that includes development in Android, Java server side, Swift, Xamarin, Unity (c#).
By using Intellij products namely AndroidStudio, Idea, AppCode & Rider - I have a unified experience which makes development so much easier, and fun!
Only con might be the price - but I would not know as its all payed by the corporate I work for - with their IntelliJ licensing server.
> In IntelliJ I can write a half baked statement like `new Foo()`, and then Alt + Enter my way to it being `foo = new Foo();` as a private member variable of the class in no time
This will be in VS Code one day, except when it's there it will be for all languages (some neural code completion engine) and do much more.
My experience of IntelliJ is that it looks nice but it is very complex and offers little compared to Eclipse. For professional reasons I had to learn Eclipse, and now I see that IntelliJ gives a more polished product. But when I need to relearn all that I had with Eclipse, I don't see the point.
IMO Eclipse is dying. Its new release cycle is pain because it fixes bugs only on quarter releases, they don't release patch releases even if very problematic. I encountered a few bugs.
I’m going to save this comment for many years down the line. I don’t agree with your sentiment (having also used VIM and Rider, but happy right now with VSCode), so it’s a sort of personal check-in I can have with my thoughts sometime near 2030.
Not a problem I've encountered, but one that will be solved by the robust extension ecosystem of VSCode. You can apply this to any UX problem you might encounter with VSCode.
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.
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?
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.
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 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 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.
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.
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.
> 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.
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.
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.
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.
You don't need all the plugins. You just need a curated set. And some of the plugins are fantastically high quality.
The Microsoft Python one is excellent, as is the Remote development one.
I'm a fan of VS Code because in spite of it having a plug in system, there are great plug ins there. And that one single great plugin is all that is needed (for that specific purpose)
I'd be more interested in VSCode if Microsoft's strategy was to relentlessly implement the most popular plugins into VSCode natively such that the most commonly used and needed functions were built in and did not require plugins.
The problem with systems that are really just frameworks for other to build on is they become reluctant to build stuff that plugins exist for. The philosophy becomes to depend on the plugins rather than built out needed features. This entrenches the spaghetti pile of plugins.
Plugins are great and necessary - Jetbrains IDEs have plugins. The difference is a philosophical one - are plugins there to provide core functionality, or are they there to provide uncommon use cases? VSCode uses plugins for basics, JetBrains builds basics in - with JetBrains you can never install a plugin and happily work away. With VSCode, the very first task you must carry out is to start managing your inventory of plugins.
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?
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).
> 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.
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.
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.
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.
> 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.
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.
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.
> 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.
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.
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.
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))
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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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.
>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.
I like the enthusiasm, but this article is a little too breathless to be fully believed.
> The most important thing I look for when choosing which tools to use is longevity.
In my time, I've programmed using Director, Microsoft QuickBASIC, FutureBASIC, THINK C, CodeWarrior, BBEdit, TextMate, Visual C++, Visual Studio, Sublime Text, Eclipse, Atom, VS Code, IntelliJ, XCode, and probably a few others I'm forgetting. I don't have any particularly strong attachment to any, except for maybe Sublime (which supplanted TextMate, which supplanted BBEdit).
Instead, what I've found is that IDE evolution is converging such that hopping between them gets easier and easier over time. The shortcuts and mouse behavior is becoming standardized, and the feature sets are getting more similar. These days, I just use whatever IDE is the "main" one for whatever language I'm developing in. Within a day or two, I'm up and running fine.
The only one I particularly enjoy using is Sublime and that's mostly for what it doesn't do than what it does. Sublime is fast and unencumbered, so it stays out of my way when I use it. I strongly prefer it when I'm writing prose for that reason.
I agree. With language server protocol becoming commonplace for auto-complete and static analysis, I don't see a huge difference between various text editors.
I'm in a similar boat, except I used VSCode for two years before switching back to Sublime Text. I remember watching [this funfunfunction video](https://www.youtube.com/watch?v=dIjKJjzRX_E) and thinking how much I related to what he says about becoming addicted to tooling. This was me with VSCode; I was spending a large amount of my work time tweaking it, adding plugins, tweaking plugins, troubleshooting plugins, removing plugins, looking for new plugins, etc.
However, the main kicker that made me switch back to Sublime was that I started it up one day and was astounded by how much snappier and responsive it was compared to my plugin-ridden VSCode. Admittedly, I do miss a lot of the plugins I used to use with VSCode, but at the same time, I'm happy to no longer have to rely on them.
"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.
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.
If you want a text editor with longevity try vim or emacs. They aren't dependent on the benevolence of a greedy corporation. Over time VSCode _will_ be raided by the bean counters at MS and it will begin to track you, give you ads about MS products, and lock you in to their ecosystem.
I'll never understand why a professional developer would give so much influence over their work to the likes of MS, JetBrains, etc.
Sure vim and emacs aren't the easiest to learn but if you're going to write software for a living it is not worth wasting your time with toys like this.
Two decades of vim here, and I switched to VS Code. As a "professional developer", it's just nicer to use, and makes me feel way more productive than ever. I definitely wouldn't call it a toy.
It's not like you have to give up Vim anyway considering the good-enough VSVim plugin gives you most of the Vim basics. Personally I have found JetBrains' Vim plugin to be the best.
You should have switched to emacs. You could have kept the vim UI but got all the stuff (and more) that you get in VSCode. Unfortunately the vim -> emacs path is taken by very few due to religious reasons.
I find comments like this incomprehensible. Are you using a Vim emulator in VS Code? If not, how can you possibly be more productive? People use Vim precisely because it offers a faster more efficient way to write code. What is it about VS Code that makes you more productive?
I'd like to assume you're joking but 20 years of vim doesn't get me anywhere close to the productivity of JetBrains or even VS code on their first years.
Vim first of all has its default set so that only very patient people can live with it. So you need to edit the defaults so much to make it slightly more comfortable, and you need to pick plugins that only some work as expected, mostly not updated in years and they add yet more crazy shortcuts no one can remember and still don't work like modern editors do.
I only use vim to edit config files on servers but VS code can do that these days, vim is losing a position for me as of late. Glad it invented modal typing but it's as ancient as one would guess.
In both cases its open source like Android is open source. The core code is available but its pretty much useless compared to the commercial version. On top of that it is still owned by a corporation who probably don't have their users interests in mind.
It's not that hard to learn a new editor and learning new software is something I enjoy. Even if Microsoft does ruin VSCode, who cares? Vim and Emacs will always be there waiting.
In the meantime, I'm loving PyCharm for Python, Visual Studio for C++, Sublime Text and Obsidian for Markdown, VSCode for Javascript, etc... Different tools for different jobs.
I don’t really understand “influence over your work” here. I agree that there’s a possibility MS will add some kind of monetisation I don’t like in the future... at which point I’ll switch editors.
But as it is, I’m much faster and efficient using VS Code than I am using Vim. It is in no way a “toy”. And it doesn’t influence my work. It’s a text editor!
Readit News
My first couple of years writing software I used Vim, then VSCode, then worked in a Java shop and was forced to use IntelliJ. I didn't like it at first, but now after a couple of years I cannot see how I lived without it.
The idea that VSCode is the future doesn't seem right to me. JetBrains products allow you to do so much out of the box, without installing a million plugins that may or may not work. In IntelliJ I can write a half baked statement like `new Foo()`, and then Alt + Enter my way to it being `foo = new Foo();` as a private member variable of the class in no time. If you take time to set up configuration it becomes even more powerful. Even these basics are more difficult in VSCode.
To me the future is IntelliJ for Java and all other languages should seek to have such a nicely integrated experience with an IDE.
I am not even sure I could write Java from scratch in Vim - its really that I'm using IntelliJ, not writing Java. Is this bad? In some pure sense, sure, you are further from the language. But I don't care because I can write and edit code some multiple faster than if I was in VSCode.
I think the success of VSCode is because you can easily open it in your current directory from the terminal and it will show you your folder etc. without having to setup a project first and that you are ready to type you code quickly after opening. If I had to open PyCharm every time I want to try some Python in a new directory, I would probably start questioning my life choices. Before VSCode I would just use nano or Sublime.
I've never used CLion but I really want to.
That being said, I think it's clear that VSCode is, and will remain, dominant.
First: its free.
Second: it's simpler.
That alone is enough to make any product dominant. The fact that's it free, simple, and pretty much just works is pretty stunning.
VSCode for Unity Game Development kinda shocks me how you can literally install the IDE while the game is running and successfully attach a debugger. It's pretty wild how reliable it is.
I'm not a VSCode fan boy. I find that it lags on my PC sometimes. I kinda hate the "notifications" that it pops up with. And I don't like the auto update mechanism or the Welcome screen, but overall VSCode (or Codium) is clearly the next level of IDE.
I think Microsoft is going to build some really wild stuff on top of VSCode and Github.
I think there gonna come up with way to leverage the amount of data they can mine out of github repos to write code for you.
I'm pretty sure that's a big reason why they bought github.
I don't need efficiency. I need something that, given fuel, gives me power. And as someone who has donated to vim, was an early backer of neovim's bountysource, and loves his terminal: vim is my ion drive, IntelliJ and friends are my conventional rocket.
> From my experience out of the box you get poor performance and you have to spend a lot of time figuring out how to change configuration to improve it as knowledge is scattered in many places and not always up to date.
I don't know if you are talking about IntelliJ or VCS, but IntelliJ can quickly start an empty project. And you don't to spend time to figure out how things work. I mean, there is literally no entry barrier for a bare bone project.
> I wish there was an editor with low latency, smart search, some proper file system database
You are describing an IDE here. Smart search and a proper file system database, it means operating not on a collection of text files but on a project and a code tree, which is the main difference between IDE and Editor.
> I think the success of VSCode is because you can easily open it in your current directory from the terminal and it will show you your folder etc.
IntelliJ is adding this functionality slowly: https://blog.jetbrains.com/idea/2020/04/lightedit-mode/ It's not on par with opening a folder in VCS, but it's a matter of time until the close the gap if they choose to.
But my startup monorepo I keep loaded in IntelliJ for days at a time and have never looked back. For the 1% of time it’s laggy due to a JVM GC or background indexing, the other 99% of the time it’s immensely productive to have e.g. full-stack debug breakpoints that Just Work, well-designed customizable gutters, integrated linting, and more.
I find vscode a horrifying experience that is forced upon me because of poor choices made elsewhere in the org.
I'm slowly picking up vim to replace it but I'd rather just not be forced out of my editor I still use daily (sublime.)
In hindsight I wish I learned vim instead of sublime.
This hasn't been my experience of JetBrains Rider at all - granted that startup does take a few seconds, but after that it seems to fly.
> Then it still likes to stall from time to time or sometimes doesn't register key presses properly
This was my experience with Visual Studio; I used it for over a decade because it is a great IDE - but performance and stability has never been great, and eventually I just couldn't stand the occasional lag any more and jumped ship to Rider. My experience there has been very different - it's rammed with at least as many features as Visual Studio, but has been rock solid, and never lags in use.
https://blog.jetbrains.com/idea/2020/01/intellij-idea-2020-1...
https://blog.jetbrains.com/idea/2020/04/lightedit-mode/
It only appeared this year so it’ll be interesting to see if it gets traction.
You can disable plugins you don't need, and mark folders as excluded if you don't need them indexed, that makes it faster.
For me, I use VIM all day, every day at work (C++), because while it doesn't have the full IDE experience out of the box, it's close enough, and can be brought much closer with various plugins and knowledgeable adjustments. I've stuck with it because "it just works" and I'm use to it. A previous colleague was a big VIM evangelist, so got a running start from him, and now I've tweaked it enough that it works well for me.
VSCode is my general purpose text editor at home. If I'm writing markdown, or fixing some script, or I just need to see what's in that file, I'll use VSCode. It is the obvious, far superior replacement for Notepad, and has plenty of niceties to make it that much easier to use.
But if I'm building something with a lot of moving parts in one of its supported languages, I'll use IntelliJ. I don't often write Java these days, but PyCharm is just a reskin for Python and I think it's great. It does so much junk for you, and it makes testing and debugging so easy. It does trip up my muscle-memory occasionally, but for the most part it's a powerful tool that's great at what it does.
That about sums it up. People use what they are used to. I don't try to convert anyone. I use the tool I like and to each their own.
I use vim primarily for around 9 years now, and with ALE as a linter plugin it's integrated with languages I even don't know existed until I need to fix something in it in a foreign codebase.
If I need to go typescript or web, vscode is very tightly integrated with the build toolchains, so the occasional fix in vscode is necessary for me when I need to fix a bug upstream.
I tried migrating to neovim a lot of times, but their syntax highlighting is always so damn broken even with a plain vimrc that I stopped bothering anymore.
Currently, I'm trying to migrate to kakoune because I've heard a lot of nice things, and the ecosystem seems to be better integrated with lsp and rust, but honestly my muscle memory is damn strong, so it's actually kind of a burden at the moment and I'm gonna need a while if I keep pursuing this.
One benefit though that both emacs and vim have is ssh usage. Debugging and reading logs on a remote server is pain sometimes, and my vim profile eases that sooo much up that I saved a shitload of time by using it.
I really loved Intellij and I wish it could be made to run more efficient. VSCode fills the niche of "loads fast, moving around code is fast, and I can have many instances open at once without crushing my computer"
I guess it depends on the type of project you're working on, but I think these tools still serve separate use cases.
Once IntelliJ is running, which takes less than 10 seconds, projects open instantly. Probably even better on desktop machines.
Frankly VS code isn't good enough yet. It's the best if isn't for JetBrains but for instance, SQL queries are still just a string (unless I've missed the obvious plugin to allow me to auto complete column names and such according to the live database schema) but IntelliJ can highlight, auto complete and check errors once I register my database (also through ssh tunneling).
I do like VS code being faster but feature wise, I only use it to edit server config files through sftp plugin.
In 5 years, maybe JetBrains might feel pressured from competitors.
But it's only less than $15/mo if you pay annually and from 3rd year for their all products pack.
Personally, I'd rather use a plain-old "code editor" (with at most syntax highlighting, but no snippets, let alone autocomplete), in part because doing so will actively steer me away from languages that weren't designed with the User Experience of writing them in mind.
Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately hold and swing it. That'd be a bad hammer, right? Hammers are hand-tools; it's an expectation that they'll work when used "manually", i.e. with raw human capability alone.
Programming languages are hand-tools as well, in an essential sense. Like mathematics, the "interface" through which we manipulate a codebase is plain, raw text — sequences of symbols. We humans understand source code by reading it with our eyes; and then we write or modify it by editing it the same as any other text. We can do the whole thing on paper, or a blackboard, or even purely in our mind's eye. That's kind of the idea behind having a source code representation of a program in the first place, divorced from a machine code representation — to give us humans a formalism we can intuitively handle. A programming language is something you can think in.
Seen through that lens, a programming language that requires the cybernetic prosthesis of an IDE to read and write it fluidly, is a bad programming language. You don't have an IDE loaded in your head. So how will you think in it? (Usually: by thinking in a vague pseudocode instead; or even, by thinking in a different language than the one you're writing in. Obviously, this is going to be lower-productivity than coming up with a mental model of the problem that can be directly typed into a computer.)
(Before anyone makes a supposition about my language biases: both "complex" and "simple" language designs can be inherently high-friction due to their design choices. Scheme has very little syntax, but it's also high-friction, in that it's easy to get lost in a sea of parens unless your editor helps you along with a feature like Emacs' paren minor-mode. Most modern code editors do have something like that, but it's still a form of lubrication to overcome a point of friction in the syntax; one that some of Scheme's linguistic siblings—e.g. Clojure—avoid by increasing syntax.)
I remember people making similar arguments when cars started to have power steering.
> Programming languages are hand-tools as well, in an essential sense. Like mathematics, the "interface" through which we manipulate a codebase is plain, raw text — sequences of symbols. We humans understand source code by reading it with our eyes; and then we write or modify it by editing it the same as any other text. We can do the whole thing on paper, or a blackboard, or even purely in our mind's eye.
I disagree; programming languages are primarily tools for programming on computers, and expecting them to be skeuomorphic to a particular approach may hold us back, just like expecting a CAD program to work the same as a physical drafting table or expecting a rendering engine to use a TV-like fixed framerate.
Being able to push secondary parts of a program to be foldable, or visible on mouseover but not by default, makes it easier to communicate understanding to other humans. And actually that's a more faithful recreation on how you'd communicate in writing - on a blackboard you might use small text, or footnotes, or a verbal explanation. A mathematical paper is almost never "plain text" in the sense of being a linear sequence of ascii characters and nothing more. A language whose design embraces IDEs can be a better tool than one that flattens everything into the binary of written in the code or completely invisible.
Also, good luck doing major refactoring with a text editor. In 2020 we can do better than find and replace.
>Imagine if there was a hammer that was so badly-balanced that—despite being not too hard to lift—you needed to be wearing a powered exoskeleton to accurately hold and swing it.
You don't use IDE to be able to use language, you use IDE to increase your productivity. Instead typing whole for loop you just use shortcuts, instead of changing class name in 5 places you just change it in once. You save time.
>We can do the whole thing on paper, or a blackboard, or even purely in our mind's eye.
But do you remember that class `PurchaseHandler` has method `BegingPurchaseProcess`?
Ah, like a jackhammer? One of those huge ones attached to a digger they use to break open the roads?
It’s a right-tool-for-the-job kind of thing. Some roads can be mended with a shovel. Some need a jackhammer.
If you limit your development to “what a human being can hold in their head” you are artificially limiting yourself. The whole reason we use higher level languages is so that the machine can exceed what a human can hold in their head.
C# is the only language for which I have had to deal with large monolithic codebases.
For smaller codebases, I prefer VS Code. Especially now that I go back and forth between JS, Typescript, Python, and occasionally Go and Java. I’m also frequently editing yaml and JSON. Having one editor is more ideal.
Linting, snippets, autocomplete, are all things that prevent you from bending the nail or breaking off the head which makes maintenance harder for the person who has to find the nail and remove the nail. If I don't have to redo the nail, the cost of the nail and my time are also saved.
I was a lot earlier in my maturation at that point, but I still think my intuitions were sound. I like languages like Python which lack syntactic noise and make it easier to write compact self-explanatory things. I used to hate JavaScript but with ES7 onwards, I've begun to like it much more because it's easy to write compact, self-explanatory things.
I was forced to write Java for work a few months ago and rudely awakened in a painful manner. Yes, you adapt to it but deep down inside, you know that it sucks and you prefer going back to your better alternative.
A string literal can be any sequence of characters so it's up to you to type them, but when I'm accessing members of a class, I'm not interested in being able to try to access a random string that is not a member of that class.
Re: your thinking comment, I also think it's the opposite. When the IDE follows the constraints of the language, it's more intuitive than when it suggests typing random strings everywhere is fine. That's not how a language works, and neither do I find it constructive to think that way.
However, I vehemently disagree with some of your (implied?) points. In particular, some functions offered by IDEs and other codebase management tools are almost equally useful for both simple and complicated languages. For example refactoring tools, or if we really look at the stem, code-base analysis tools that 1. parse the language, and, 2. have APIs for modifications, are some of the "power tools" that could be useful for virtually any programmer.
As an IDE-averse person, I find myself reaching out for the simpler languages far more often, and do actively dislike high-ceremony systems. All the while, I am painfully aware of the limitations of using only a [good] text editor. My main alternative (to mainstream IDEs) is to context-switch between pure code-writing episodes and refactoring/analysis/etc. periods (using other tools, most on the command line or with output to a web-browser).
Also regarding your comparison between written programs and mathematics: I think that comparison is relevant ONLY for low-churn fundamental code (such as core libraries, or generic utility libraries) and rather poor in a LOT of "business logic"/"presentation layer" code. I myself play code-golf and run several _mental_ redesigns/refactorings when working on code that should be solid and not subject to frequent revisions. In such cases, yes, the code should be readable, well designed, and simple to follow (clarity slightly preferred over performance for the core). Nearly formal and exhibiting formal/math-like traits. On the other hand, "business logic" code is inherently unstable and could require numerous revisions purely due to external requirements. Such code usually shouldn't be optimized for tight simplicity. "the first thing that came to my mind"-level clarity with comments can suffice. Common IDEs do help with the latter type of code (while, I think, not much with the former).
Beside serious analysis and modification tools, there is an extra set of features provided by many IDEs, such as lookups (lookup function/library/etc. initiated while looking at code), autocompletion (based on parsed code or just string matching), etc. These are certainly nice, but I don't think they change the landscape much between IDEs and plain text editors (or rather, editor-and-a-documentation-lookup-web–browser-on-the-side).
So, for me, IDEs are certainly valuable even if I don't use them frequently. In a more ideal setup, I would write my code in my preferred editor without much hand-holding and with just the simplest of IDE-like features. And then, separately, do codebase "polishing" with dedicated analysis tools that may or may not look like conventional IDEs.
Dead Comment
Language toolchains are now expected to provide IDE-specific features on their own (by implementing a language server), and so IDEs themselves don't need to focus on making the language better. So the biggest sell of IntelliJ, reSharper etc. won't be relevant for too much longer, since every editor can (or will be able to) e.g. understand Java and provide basic fixes and refactorings.
The key to JetBrains' success is not any particular software architecture, although having language analysis plugins run in-process with direct access to AST structures is an obvious advantage, it's that they're a company that charges money for their tools, which has kept their cost overheads low (very low relative to never-profitable SV startups that snort VC capital like party hounds), and which are building on an already very productive platform to begin with (Java).
This combination means their feature throughput is very high but more importantly, sustainably high. They've been doing this for 20 years and aren't about to hit a tech debt wall where they suddenly need to rewrite their product from scratch.
Contrast this to their primary competitors, Microsoft and Apple.
Visual Studio has a comparable feature set to JB IDEs. But it's Windows only, totally un-portable, hardly supports web dev outside of the .NET stack, and the plugin model is native. They badly struggled with the transition to 64 bit because of this, which in turn meant users regularly hit its internal architectural limitations like project size limits (cuz of the 32 bit address space). VS doesn't scale well because there's no good way to stop plugin crashes taking out the whole IDE. Even though MS have been pushing .NET for 20 years, VS itself doesn't use it. IntelliJ built on Java which hurt them in the early days, but now Java's perf issues are mostly solved and they benefit every day from portable plugins, a seamless 64 bit transition, cross-platform portability, etc.
XCode is under-funded, has very few plugins and can't compete for any task outside of Apple's own ecosystem. It doesn't even try, really.
VSCode is a text editor with plugins. It is at least trying to compete with JB, but I don't forsee much success in the short term, especially if JetBrains pull their finger out on light mode. It at least uses managed languages. But the most mature JB plugins have been developed over a period of decades by now. The feature-set is overwhelmingly huge, and they have hundreds of employees that do nothing else but add them. How much money is MS willing to throw into the VS Code project? Its lack of revenue model limits them, even with a sugar daddy funding them. It's unlikely they can scale to JB size because a free IDE that competes with their own revenue generating VS product is simply not something they will tolerate long term. VSCode is going to be stuck focusing on the JavaScript/web stack for a long time and won't receive a lot of funding to grow out of that.
When using a strongly typed, object-oriented language like Java or C#, Jetbrains tooling, namely the intellisense and refactoring is well-worth the cost.
However I'll still spin up VSCode for most all other languages since the tooling advantage diminishes when using a loosely-typed language like JS or Python.
Also consider that VSCode is free compared to Jetbrains, and the tooling is "good enough" for most cases. Even the C# tooling is passable with the right plugins.
Granted when we write code, we keep in mind whether an IDE will be able to refactor it later.
You devote time to learning your tools and improve the efficiency of the parts that matter, and the tool itself becomes mostly background.
If you think Java + IntelliJ is well-integrated, you should try C# + VS, C# + Resharper.
I am not joking or being facetious - modern C# IDE support is on another level.
And I don't even like C#.
I found configuration of code to be pretty annoying as well. Either you write json, having to google for things like how to format keyboard commands, or use their (subjectively) ugly configuration page.
The fact that I can't detach the terminal from the code window without some weird workaround was also something I couldn't come to terms with. I'm back in pycharm again.
It's all nice and shiny until it takes several minutes to index your whole project structure. Then you can only hate it a little bit more every time you start it.
VSCode is not bloated (for now) with millions of options, I can add extensions and/or disable them whenever I need without losing performance or even creating my own ones without too much effort.
I doubt IntelliJ plugins slow down the IDE noticeably, though I do keep the number of plugins activated to minimum for only what I use.
What I see here is the IDE being powerful to make up for a lack of power in the language. Is that bad? Maybe.
I tend to think it's bad because tooling usually does less for making code easy to read than it does for making code easy to write. Furthermore, one of the few characteristics that seems to consistently predict defect rates is codebase size.
On the other hand, increased abstraction can also require more effort to read, and you'll get a lot more resistance in most projects to switching languages than you would to you switching your editor.
But what confuses me is that the article always references it as a "Text Editor", not an IDE. As a text editor it might be the best, but as far as I am concerned, I just don't need "standalone" text editor. I don't have usage for it. I use IDE for programming, and as far as writing text goes, I need that only for writing notes or software documentation, and for that I use Drafts app, Roam Research, or Google Docs.
But I am curious to learn how people use VSCode as a "text editor".
If you do mostly consulting work, small projects, switching between languages with poor IDE support (usually dynamic languages), you'll probably use a smart editor. You'll launch that editor multiple times per day, close it, reopen it, etc.
We should talk more about workflows, there are a ton of them and they're very different in my experience.
I don't like this situation: I wish there were more competition, but it appears one company has the edge at present. I use VsCode for one-off files, since Jetbrains isn't a good fit for these.
And they also stopped bringing any more advanced features, like refactoring from null to Optional for example, or reversing template method.
If we're talking about java specifically vscode and vim would just use eclipse language server which can do most of the things intellij can like refactorings and snippets. And for other languages like python ms language server is even better than pycharm for example.
I'm glad it's one I can decide to make when and where I want to.
Hopefully one day a full featured IDE will be as fast as I want, but until then I'll be switching between VSCode and JetBrains products depending on what I'm doing.
intelligent completion is something like cmd+mayus+space. "find usages" is cmd + f7 (which in osx means cmd + fn+ f7). The "open" dialog for opening a project doesn't even have a default shortcut, it's mouse based and will open a second dialog asking if you want a new window or just reusing the current one. CMd+mayus+f for global search wont work if my focus is on the integrated terminal, I have to click out of it.
I feel like I'm learning to play piano placing my hand in weird chord shapes constantly, and half those things launch an ui pane or menu that I practically need to navigate by clicking even if they sometimes technically allow some kind of keyboard interaction.
It's not like I'm an extreme vim+dvorak user obsessed with having everything in the home row at one button press, but a bit of thought into priorizing shortcuts and placing the common ones in comfy places would go a looong way.
"shift-shift open" to open projects. next time it will probably be "shift-shift o" It also displays the actual shortcut.
Integrated terminal (and all other cases) switch focus to the editor: escape.
For all other cases: you are probably aware that you can change shortcuts. For example to vim shortcuts. Not 100% the same but still. And yes, switching editors take some time get used to.
(I love pycharm, i like VScode for small projects, dont like the un-integrated mess of for example spell check correcting function names?)
The problem is that all I need is 2 or 3 plugins. If all I need is a golf cart I don't care that your Lamborghini is amphibious and can fly to the far side of the moon
Unfortunately it's hard to know how to configure every editor and know how to get these time saving features.
A few I get from VSCode (love to hear about other editors)
1. the best Javascript support via integration with eslint
Eslint's plugin system means I get react specific hints and error messages. I'm not used to an editor giving me library related errors. Usually they only give language related errors
2. codespell plugin
This only matters for dynamic languages but it turns out spell checking code can be surprisingly useful. The language it self can't tell me
is wrong but codespell will highlight `lastNane`ps: I get that's bad code ;)
3. opening folders
Lots of people mention this but it's arguably a killer feature. I can't believe that it took until now for an editor to have this. Most previous editors I've used to had to go through the process of making some kind of project to get similar functionality. If I wanted to easily search and replace in a project across files I had to make a project or configure stuff. If I wanted it to find references to other files I'd have to make project or configure stuff. vsc seems to find these things with no work on my part.
4. pretty good file support (renaming and moving files, including the required code refactoring to go with it). Every IDE-ish editor I've used since the early 90s has had some kind of file tree panel but VSC's is the first one I use regularly for more than just opening files.
5. friction-less easily discoverable plugins
I think this is overlooked but consider the Apple iOS app store vs Windows CE. I could install apps on my 1998 Casio Windows CE PDA but it wasn't friction-less like the App stores today are. That difference is huge. Every editor I've used since the 80s has been customize-able but I rarely looked for other people's customizations. It was just too much work. Not only did I have to learn how to install them and get them to run I had to go manually find them. VSC suggests them. I get that can be annoying but given low-discoverablilty or a few annoying notifications I think promoting them is a net win.
That said, I hate that VSC is slow! I work on quite a few hobby projects where I just want to put all the code in 1 file. At about 1000s lines VSC starts acting up, getting janky (on a 12core 64gig ram AMD Ryzen 9 3900XT) and eventually I'm forced to split the file. Sure, better organization is good but my tools shouldn't be forcing it on me when I'm just making something throwaway.
I've also used IDEs that are highly optimized for Java and .NET. I agree it's great for the use case I had.
All IntelliJ lacks is two things: 1. Being a lightweight editor with syntax highlighting which IIUC they are / have already built 2. Remote development where the IDE is just the front end running on, say, a laptop and the computation runs on a remote work station
Disable plugins on a per-project basis. (I currently put up with plugin exception reports for other language plugins in projects for unrelated languages.)
Enable or update plugins without a full restart. (This is getting better but many plugins still need a full restart.)
Sync all plugin settings (for example, AceJump plugin settings aren’t synced).
Split the terminal pane horizontally.
Open a file in a vertical split from the navigator or search everything box. (I want to believe I missed an easy way to do this; someone let me know if so!)
Set alpha keyboard shortcuts in quicklists.
Style the title bar colour on macOS to match the editor background.
Write a quick script to add missing IDE functionality without boilerplate or build tooling.
Add a command line run configuration. (There are workarounds but the original feature request remains open after 7 years: https://youtrack.jetbrains.com/issue/IDEA-112256 )
I can do all of these in vim and Emacs and most in VS Code.
They’re nitpicks and no editor or IDE is perfect. I think I feel the pain points with IntelliJ more acutely because for many of these I can’t fix them myself.
Deleted Comment
VS Code is the future of editors, not IDEs or all developing. There will always this two sides which live from the box and those who build their own box. And for the later VS Code is nowadays one of the best road to walk.
> JetBrains products allow you to do so much out of the box,
It's also very limited on where you can work with it. It works for the handful most popular languages they support, but what if you get a bit more exotic? What if need something non-programming, like markdown, rst or plantuml? What if I am not satisfied with a certain feature in the IDEs editor or workflow?
If your Box is not supporting it, you need to customize it, and there JetBrains is just not as good as editors like VS Code, vim, emacs.. And VS Code even goes to great lengths to gain the IDE-state of having everything out of the box.
????
It also integrates with databases, Docker, etc.
IDE's helped me so much writing Java code; refactorings, autocomplete, code generation etc are features that never became as good in 'lighter' editors.
Then the JS era appeared, and IDE's couldn't really do much with it - in part due to its unstructured setup, lack of importing code, lack of namespaces. Autocomplete and jump-to-definition was non-existent. I switched to Sublime Text for web work, and relied heavily on the powerful and fast global search and cmd+p navigation for a good while.
Over time, things changed; JS got modules, JS got types (or type inference) through projects like Flow and Typescript, and JS got richer with e.g. JSX. Still mainly used VS Code (by then) for front-end though; heavier editors didn't seem to offer enough added value to warrant the switch.
But every time I did back-end work I would switch back to a proper IDE. Java / JVM languages are things I never did in a lightweight editor. Go (which I use as a back-end language currently) support was rough for a good while in both editors and IDEs, but it's getting there.
In my current job, I handle four languages over two projects; there's the legacy project, PHP and JS / Dojo, and the new one, Go and TS / React. I've fully switched to using an IDE again; intellij's JS / TS support is good enough, and honestly for the legacy codebase I need it. The codebase is nearly 10 years old, and the 'hip' editors simply don't support PHP 5 or 13.000 line spaghetti messes. But intellij does; I configured it for PHP 5.2 specifically (so if I use the shorthand array syntax it flags it up) and ES5, it struggles a bit but it can make sense of the huge files, and it helps me a lot in making sense of it. It's a safety net that the codebase and language itself doesn't give me.
VS Code and co wouldn't come close.
Anyway I still switch to VS Code from time to time for one-off tasks, quick edits, formatting, etc.
There are 2 minor differences I experience very often: VCCode is blazingly fast compared to IDEA, and VSCode has much more quality plugins than IDEA (at least for those things that interest me).
I'd compare VSCode to Emacs in a sense that the architecture is really simple (all you have is functions that do something) which makes VSCode more appealing to prospective plugin developers.
I'd even go so far as to say that to me VSCode becomes the new Emacs.
Perhaps that is because of the very narrow focus on what IntelliJ does and the functionality of plugins is part of the core system of IntelliJ.
In my view, VSCode is a platform. It's unfortunate that they chose to use Node (its slow) but otherwise, its a great platform to develop extensions for.
For someone just getting into programming, it offers a great stepping stone and it can handle medium sized projects quite well.
I want a plugin to parse the SQL query and do auto complete, check for syntax and column/table name errors according to the database I connect to through ssh tunneling but it's just a string in VS code. It also auto completes join columns by checking which foreign keys may match on the table I'm trying to join at the point of typing "JOIN [table name] ".
I want a plugin, so if I open a file, it checks the remote file and make sure it's not modified, so that I don't accidentally overwrite it in case someone has edited the remote file. (Yes, this sounds dumb but non programmers don't do like we do.)
Jump to definition should work like expected, reverse jump to uses from definition should also be there.
Formatting code with so many customizations on many languages including SQL, CSS with a hotkey or against a whole directory. Should the brackets go to next line or not, should there be spaces, should it be tabs or spaces etc. I see there's "prettier" etc but the supported languages and customizability aren't there.
My use case for the IDE should be narrower than others as I only use it for the web development but still it's a few miles ahead of VS code today.
But competition is good. I'm sure JetBrains may start sweating in 3 or so years when things actually start to be competitive but VS code is free and lighter.
Deleted Comment
This will be in VS Code one day, except when it's there it will be for all languages (some neural code completion engine) and do much more.
I recently bought a personal license for Webstorm and really like it.
if you look at source code of a random IntelliJ/IDEA/... plugin and on similar plugin in VSCode, it's obvious VSCode design is more clearer.
Which _will_ work for it long-term.
Not seeing myself switch to VSCode anytime soon from IntelliJ or Pycharm.
Deleted Comment
1. Use the Community edition for free, which does lack enterprise features but includes everything intellij makes so nice, or
2. Buy a version and just use it indefinitely without upgrading and ever paying again?
Dead Comment
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
With remote, I am able to do all coding on a non-infested Linux server with almost seamless usability.
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/
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...
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.
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.
[1] https://github.com/nikaro/devc
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.
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.
This is really frustrating. Am I doing something wrong?
Careful with the Remote Development plugin. It does NOT have an open source license.
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).
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.
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.
- 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
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.
It only takes a second but its absolute madness.
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.
Then you do not really need to install any plugins. Problem solved!
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.
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.
Replace "vs code" with "javascript" and "plugin" with "library" and you've just described the javascript ecosystem.
This is why my experience with VS Code reminds me of Eclipse.
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.
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.
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))
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.
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.
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.
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.
Sublime is great but it updates once every other blue moon for a reason.
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.
Deleted Comment
Deleted Comment
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.
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.
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.
> The most important thing I look for when choosing which tools to use is longevity.
In my time, I've programmed using Director, Microsoft QuickBASIC, FutureBASIC, THINK C, CodeWarrior, BBEdit, TextMate, Visual C++, Visual Studio, Sublime Text, Eclipse, Atom, VS Code, IntelliJ, XCode, and probably a few others I'm forgetting. I don't have any particularly strong attachment to any, except for maybe Sublime (which supplanted TextMate, which supplanted BBEdit).
Instead, what I've found is that IDE evolution is converging such that hopping between them gets easier and easier over time. The shortcuts and mouse behavior is becoming standardized, and the feature sets are getting more similar. These days, I just use whatever IDE is the "main" one for whatever language I'm developing in. Within a day or two, I'm up and running fine.
The only one I particularly enjoy using is Sublime and that's mostly for what it doesn't do than what it does. Sublime is fast and unencumbered, so it stays out of my way when I use it. I strongly prefer it when I'm writing prose for that reason.
However, the main kicker that made me switch back to Sublime was that I started it up one day and was astounded by how much snappier and responsive it was compared to my plugin-ridden VSCode. Admittedly, I do miss a lot of the plugins I used to use with VSCode, but at the same time, I'm happy to no longer have to rely on them.
"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'll never understand why a professional developer would give so much influence over their work to the likes of MS, JetBrains, etc.
Sure vim and emacs aren't the easiest to learn but if you're going to write software for a living it is not worth wasting your time with toys like this.
Vim first of all has its default set so that only very patient people can live with it. So you need to edit the defaults so much to make it slightly more comfortable, and you need to pick plugins that only some work as expected, mostly not updated in years and they add yet more crazy shortcuts no one can remember and still don't work like modern editors do.
I only use vim to edit config files on servers but VS code can do that these days, vim is losing a position for me as of late. Glad it invented modal typing but it's as ancient as one would guess.
If that is the case you only scratched the surface of vim.
To flip it, I'll never understand why a professional developer won't spend a measly hundred bucks on an IDE that has everything set up out of the box.
Also, VSCode and IDEA are both open source.
In both cases its open source like Android is open source. The core code is available but its pretty much useless compared to the commercial version. On top of that it is still owned by a corporation who probably don't have their users interests in mind.
In the meantime, I'm loving PyCharm for Python, Visual Studio for C++, Sublime Text and Obsidian for Markdown, VSCode for Javascript, etc... Different tools for different jobs.
[0] https://code.visualstudio.com/docs/getstarted/telemetry
But as it is, I’m much faster and efficient using VS Code than I am using Vim. It is in no way a “toy”. And it doesn’t influence my work. It’s a text editor!
Dead Comment