Completely agree. Sure, any editor can be paired with static analysis tools to make sure I probably didn't break things, but only a full IDE can just handle the refactor for me so that I don't have to spend time searching, fixing, and checking to begin with.

No, I don't need or use all the IDE features. I don't use the integrated shell, I don't use the git integration, I don't have it handle my packages. I don't see a need for these things when I always have multiple terminals open anyways, but proper code intelligence is not something an editor+plugins can provide like a real IDE can.

Sounds like you're unaware of LSP (Language Server Protocol). "Proper code intelligence" is absolutely something that an editor+plugins can provide, and LSP means that intelligence can be developed once and used with many editors, rather than "integrating" the editor with the code analysis so your choice of one dictates your choice of the other. LSP is just one of those things that makes sense, turning something quadratic into something linear.

I don't care at all if someone prefers IntelliJ over Emacs (that's a pure matter of taste) but the idea that it's impossible for an editing environment that isn't delivered as a single, integrated monolith to expose powerful language-specific tools such as interactive lints, large scale refactorings, debuggers (check out DAP for the debugging equivalent of LSP), etc was never true as a technical matter and is increasingly untrue in the real world.

One of the best developments in dev tooling in recent years is that it is starting to be seen as the norm for new languages to provide canonical language server implementations. Long may that trend continue.

Language server protocols are just re-inventing IDEs, but instead of using shared memory and interacting with the compiler directly you have to use an inefficient JSON pipeline.

No, the choice of a client/server model was a design decision, one that is not unique to LSP and is also used by some IDEs for various reasons (see, for example, JetBrains Rider). Performance is absolutely fine - the only data that needs to be transferred is that needed to drive the UI, which is trivial over a local socket. Had that not been the case, there are plenty of ways LSP could have been designed as an in-proc library interface and remained just as open as it is.

What makes LSP not 'integrated' in the sense of the I in IDE is the fact that it is decoupled from the editor, allowing one editor to work with many language servers and one language server to work with many editors.

> No safe refactorings (moving classes? good luck), completely random code completion, 0 awares of available libs/SDKs, and so on.

Seems like you haven't used VSCode in a long time. It is my primary everyday editor for Typescript, and it has all of those things you listed: I can move a class to a separate file in one click, code completion always follows type system, it is aware of all packages that I have in package.json and offers to import them, and so on.

The IDE/editor distinction really doesn't have as much meaning as it once did.

Try to use it for python or c++ and you will see the problem. I switched to clion as I work in node, python and c++. vscode python support is bellow average and c++ support is bad. clion works great for all those environments.

My biggest problem with vscode is lack of UI configuration. You can have only one panel which is huge waste on big screen. Some useful features compete for screen space (outline vs. project explorer, project explorer vs. debug window etc.). This makes me way less productive than using heavyweight configurable IDE.

I use VS Code on a daily basis. It's my go-to tool for config-based projects (Kubernetes), simple and quick HTML/CSS editing, and the likes.

I've tried it for more serious development for Rust, Python, and TypeScript. While for Typescript the inference is barely acceptable it complete sucks for Rust/Python.

I use vscode daily and recommended it, but to be fair, it's heavily optimized for typescript. The feature may be not available for other language such as java.

This is true, but it demonstrates that VSCode extension model supports this, and nothing stops extension developers from attaining the same level in any other language. Hence my point about IDE/editor distinction.

Sure, why would it not be possible. Intellij and Eclipse also implement all their language support in plugins so why wouldn't VSCode.

But the thing is this is all hypothetical - it is possible if somebody invests those thousands of hours into it. But so far it did not happen for most languages and Intellij IDEs are still vastly superior to VSCode for e.g. Java, Python or C++ development.

Fair point, though I'm skeptical whether extension can achieve the same level (and performance) without vscode optimized for that.

The TypeScript support is implemented as an extension.

Referring to them as "the crackheads" might be a barrier gaining understanding of their choice of tools. :-D

My guess is that was intended as hyperbole, like saying you think they are "crazy" for doing so. Still, I'm thinking you'd be more likely to get interesting feedback by stepping it down a bit.

>I think it's just Dunning–Kruger effect on a scale.

I find it incredibly pompous that you believe that people who have been writing C++/C even Java for decades in editors like Emacs, Vim or even Sublime don't know what they are doing. The IDE vs Editor argument is nearly as old as Emacs vs Vim.

I've seen people who have been on vi/emacs for decades. They truly have zero idea of what an IDE can do.

As a personal anecdote, I've seen people switch from vi to IDEA after a pair programming session. In that session they learned that IDEA has full understanding of the frameworks, configurations, code annotations and bindings etc. that we used in a project, and that you don't need to spend 15 minutes furiously searching in files for stuff when you have to change something in two or more places.

Easy. They don't know what the hell they are doing.