[skydhash]

VSCode rely on familiar pattern and UX to let you get started easily. But out of the box, it's pretty much notepad level. Vim and Emacs start from the premises that you need powerful tools. And they give them to you alongside the possibility to integrate external tools easily with the editor workflow. With VSCode any integration needs to be a full project. With emacs and vims, it's a few lines of config.

[torben-friis]

What kind of integration is a full project? Integrating language support for example is usually just heading to the plugins section, searching for the language and clicking install on the most mainstream result.

My config for vscode is just like 5 lines to make keyboard travel between panes a bit more vim like, other than that I never needed to change much from defaults.

For neovim the work to make it ide-like is a large list of plugins and its integrations, large enough that I’m comfortable outsourcing the consistency to a distro (lazyvim).

[t_mahmood]

Yeah, now see, you need to do that for every programming language, or tool for vscode.

With Lazyvim you get all at once. And you can ignore many plugins if you want,

Sure it's not ide level, but with proper configuration vim/Nvim is much more powerful than vscode. And thanks to Lazyvim, you can set it up faster

but Nvim or vim even without plugins can do many things that vscode can not do. So without plugins vscode is just an editor, while Nvim/vim are powerful utilities

[torben-friis]

>Sure it's not ide level, but with proper configuration vim/Nvim is much more powerful than vscode.

I’m not arguing against that, I actually moved to neovim and I enjoy it - plus I can now stop worrying that my daily driver will be rug pulled.

I just don’t agree with the idea that neither nvim or eMacs have similar levels of ability to onboard new users. Not when grokking something as simple as closing a tab will get you through a history lesson on the alternate namings of tabs, buffers and windows for example.

[skydhash]

No one is arguing that. Just that VSCode is also complex too. But it’s just that out of the box, there’s nothing special. Then you add a few tools through plugins and that’s the extent of of workflow customization most people stay at. If you want more, you have to start a whole new project, and the complexity of that is high while the return is not as good as you can have with emacs/vim.

With emacs/vim, getting started is fairly easy (there’s a tutorial). The learning phase is linear, but it’s just practice and using the software. Creating your own tool is very easy as you can jumpstart from where other’s plugins are and add your own stuff. In VSCode, it’s starting from scatch everytime.

[skydhash]

There’s a reason almost every good editor (on unix) have the pipe to/from shell feature. With that you have the whole power of the os at your disposal. And in vim, you get the quickfix list for fast navigation according to the output of a grep/build tool.

Someone could make a config to make vim/emacs beginner friendly. But there’s a reason there’s no beginner friendly truck or plane.

[skydhash]

With emacs, you can just use “customize” (for options) and “M-x” (for commands) and never care about anything else. Yes, it’s not as visible as vscode, but it’s very much the same thing.

But once you learn elisp, then you have the power of a full VM at your disposal and not wait for a plugins to exist and hopefully implement your workflow. And adhoc integration (like having ticket number in comments be clickable) is not easily feasible.

[self_awareness]

Your argument is like... "once you learn C++ you have your whole processor at your disposal, you don't need to wait for any software because you can write it yourself."

[skydhash]

That just highlights some confusion about Emacs. It’s more akinto Unix and the shell as a whole. That’s why I said VM. If you know perl and have a whole host of utils from a unix box, you can script the workflow you want quite easily, especially if you have access to the cpan libraries.

The same thing can happen with emacs. There’s a lot of low level interfaces (network, process,…) and some high level ones regarding the UI. Then there’s a lot of utils andd whole software built with those. All modifiable quite easily. As another commenter had put it, you don’t even need to save a file. You just write some code, eval it, and you have your new feature. If you’re happy with it, you add it to your config or create a new module (very simple). So elisp covers the whole range from simple configuration to whole software.

[slaymaker1907]

You absolutely don't need extensions for JS development. It is absolutely NOT notepad level. In my experience with beginners, installing an extension is also incredibly easy compared to getting them to edit some vim/emacs config.

[iLemming]

> incredibly easy compared to getting them to edit some vim/emacs config

Yet, extending just about any functionality of Emacs for an experienced user is far simpler than in anything else - you can write some expressions in a scratch buffer and change the behavior of any command - built-in or third-party. Not only wouldn't you even have to restart anything - you wouldn't even need to save that code on the file system.

There's a strong correlation between perceived difficulty at the beginning and notable simplicity at later stages. Things that are seemingly harder to grok often open up avenues for clarity later. Conversely, things that seem easy to get into, later often become full of bottlenecks and complexity.

Imagine attempting to replace all the knobs, controls, buttons and switches in an Airbus A380 cockpit with a single touch-based display à la Tesla and claim it's now easier to train new pilots, but you've just made them dependent on a system they don't deeply understand, you've traded 6 months of training for a lifetime of brittle expertise.

I am forever indebted to my younger self for investing some time in understanding the grand ideas behind Vim and Emacs, and never, even once, have I regretted my choices. Rather the opposite - I regret wasting a big chunk of my life chasing popular trends aimed at "intuitive use", "easy start" and "it just works™". I would have never developed the true "hacker's mindset" without them.

Undeniably, there's an immense pedagogical value in tools that make it easy for beginners, but there's also a mental trap there. It's ingrained into human nature - the brain simply doesn't like the grit; it naturally gravitates toward comfort and minimal effort - it just wants to remain lazy. Yet there's a compounding effect of initial investment that pays off later. Sadly, we keep trying to find ways to dumb things down.