5 ms·

It kind of depends on how we are defining IDE. Every developer I know who doesn't use an IDE uses either VS Code, vim or emacs with a bunch of plugins which app

It kind of depends on how we are defining IDE. Every developer I know who doesn't use an IDE uses either VS Code, vim or emacs with a bunch of plugins which approximate IDE functionality (but are much more customizable and configurable which I suspect is what they like about it). At the end of the day every IDE is just a text editor with plugins too. It really comes down to whether you want something that just works (and probably forces you to do some things THEIR way on some margin) or you want to tweak your dev environment to be just right for your workflow.

bccdee 5y ago
Yeah, that's true. For me, it'd be somewhat irritating to work without LSP features like "jump to definition," "hover to view doc string," or even tab completion. Arguably, these are IDE features. But when it comes to higher-level features like build tooling or even grepping, I'd much rather work from a command line. Something like tab completion can't exist outside the editor, but as soon as features can exist as separate tools, bundling them together begins to feel like a limitation. Having separate tools means you can discard the ones you don't need, which is part of what leads to fully-featured IDEs feeling so bloated to me.
- thinkharderdev 5y ago
  True. I've been slowly moving towards VSCode from IntelliJ over the past year or so and that has mostly been driven by better Scala LSP implementation (Metals has gotten immeasurably better over that time). And even when I used IntelliJ exclusively, I more or less used it as a text editor with code completion/jump to definition. I still used a separate terminal for git, builds, etc. I think there are also certain efficiencies that come with bundling as well though. You end up with a bunch of things specifically designed to work together so they in some cases are better than the generic, composable tools. I still find myself firing up IntelliJ from time to time because sometimes it just seems to work better (faster, more responsive, etc) even though the feature I am using technically exists in VSCode + Metals.

bccdee 5y ago

Yeah, that's true. For me, it'd be somewhat irritating to work without LSP features like "jump to definition," "hover to view doc string," or even tab completion. Arguably, these are IDE features. But when it comes to higher-level features like build tooling or even grepping, I'd much rather work from a command line. Something like tab completion can't exist outside the editor, but as soon as features can exist as separate tools, bundling them together begins to feel like a limitation. Having separate tools means you can discard the ones you don't need, which is part of what leads to fully-featured IDEs feeling so bloated to me.

thinkharderdev 5y ago
True. I've been slowly moving towards VSCode from IntelliJ over the past year or so and that has mostly been driven by better Scala LSP implementation (Metals has gotten immeasurably better over that time). And even when I used IntelliJ exclusively, I more or less used it as a text editor with code completion/jump to definition. I still used a separate terminal for git, builds, etc. I think there are also certain efficiencies that come with bundling as well though. You end up with a bunch of things specifically designed to work together so they in some cases are better than the generic, composable tools. I still find myself firing up IntelliJ from time to time because sometimes it just seems to work better (faster, more responsive, etc) even though the feature I am using technically exists in VSCode + Metals.