Just Because Its New Doesn't Mean Its Good (neovim) | Prime Reacts

The central fight is over how to interpret “new” in software: novelty isn’t automatically progress, and the more useful question is “why would you choose this for this situation?” rather than “why don’t you use my favorite alternative?” That framing matters because it shifts debates from tribal editor wars into practical tradeoffs—what problem a tool is optimized for, and what compromises come with it.

A big chunk of the discussion centers on neovim versus Vim and Emacs. One side argues that neovim represents a “newer” innovation path: it modernizes the Vim experience by leaning on Lua for configuration and extension, and by bundling modern editor capabilities such as LSP client support and Tree-sitter integration. Emacs is treated as the older, already fully customizable benchmark—often even more moldable in practice—because it offers deep customization through Lisp and a mature ecosystem (including features people associate with Magit and Org mode). The disagreement becomes less about raw capability and more about feel and workflow: Vim/neovim is praised for “raw dog” speed and crisp terminal responsiveness, while Emacs is described as feeling slower on larger projects and more oriented toward a different interaction style.

The conversation also challenges the “why not” style of criticism that dominates tech culture. Instead of asking why someone doesn’t use a preferred tool, the better approach is to ask why a specific choice fits a specific context. That’s used to critique how people dismiss others for using different editors, languages, or frameworks—like asking why someone doesn’t use Rust instead of Go—when the real question should be what constraints and goals drove the decision.

Another thread disputes whether neovim’s Lua-based approach is inherently “worse” than Vim’s modal model or Emacs’ Lisp. One participant argues Lua is more approachable than Lisp for most newcomers, since many people already start with C-like syntax patterns and find Lua’s learning curve gentler. Lisp’s functional/recursive mindset is portrayed as less natural for beginners, even if Lisp is old and theoretically powerful.

Finally, the debate expands beyond editors into a broader “progress vs fashion” lens, using React as an analogy: frequent version churn doesn’t guarantee meaningful improvement, and sometimes changes reflect shifting programming preferences rather than better outcomes. The discussion then pivots into a networking analogy (TCP vs UDP) to argue that what was “superior” in the past can become outdated as conditions change—reliability assumptions, throughput needs, and modern protocols like HTTP/3 and QUIC. The takeaway is consistent: time, constraints, and implementation details determine what works best, not age or popularity alone.