Why I Switched from VSCode to NeoVim (and Why You Might Too)

Sandip Gyawali — Fri, 11 Jul 2025 03:14:00 +0000

I used VSCode from the beginning of my career — for about 4 to 5 years. It had everything I needed: themes, a polished GUI, and a vast extension ecosystem. But over time, it started to feel... slow and clunky. I found myself wanting more control, less bloat, and something more lightweight — maybe even a bit more experimental than VSCode. That’s when NeoVim entered the picture. At the same time, I had also been using Linux (Fedora with the i3 window manager) for a while, which naturally pushed me toward more minimal, keyboard-driven tools.

At first, I dismissed it. Terminal based? Vim Keybindings? Manual plugin setup? I was scared. But after watching a few videos and references, I decided to give it a shot. What followed was a week-long rabbit hole of configuration, key mapping, plugin exploration — and eventually, a workflow that made VSCode feel sluggish and noisy in comparison.

What Made Me Switch

Here’s what drew me in:

⚡ Speed: NeoVim launches almost instantly. No Electron overhead, no lags.
⌨️ Modal editing: At first weird, but now addictive. I rarely touch my mouse anymore.
🔌 Full control: With Lua-based configs and plugin managers like Lazy.nvim, I could tailor everything to my liking.
🎯 Focus: Working in the terminal eliminated distractions. It’s just me and the code.

It felt like i was superior and god with some divine power.

My tmux and Neovim Setup:

Plugin Manager: Lazy.nvim — fast and declarative.
Theme & UI: Catppuccin
lualine.nvim for a clean, themed statusline.
bufferline.nvim to navigate between open files easily.
neo-tree.nvim as my file explorer with icons, git status, and fuzzy finding.
Telescope for everything else — searching files, buffers, and more.
mason.nvim to manage language servers and formatters.
nvim-lspconfig for TypeScript, Lua, and more.
none-ls (formerly null-ls) to run formatters like prettier and linters like eslint_d.

Some of the Performance Changes that i Noticed over VsCode.

Feature	VSCode	NeoVim
Interface	Graphical, mouse-driven	Terminal-based, keyboard-first
Performance	Can be slow and resource-heavy	Lightweight and extremely fast
Customization	Limited to GUI settings and JSON configs	Fully scriptable and deeply customizable via Lua
Plugin Ecosystem	Easy one-click installs via Marketplace	More control, but manual setup via GitHub plugins
Editing Workflow	Traditional typing with optional Vim extension	Native modal editing for speed and precision
Learning Curve	Beginner-friendly, works out of the box	Steep at first, but highly rewarding

Resources That Helped Me

If you’re curious, here’s what helped me dive in:

Github Library: https://github.com/nvim-lua/kickstart.nvim
LazyVim: https://www.lazyvim.org/
Youtube: https://www.youtube.com/watch?v=m8C0Cq9Uv9o&t=516s

Conclusion

Switching to NeoVim felt like stepping out of my comfort zone — and into complete control. I don’t think everyone needs to make the switch, but if you’re frustrated with the performance or limitations of VSCode, NeoVim is worth exploring. It's lean, powerful, and once you get used to modal editing, it’s genuinely hard to go back.

Have you tried NeoVim or thinking of switching? I’d love to hear your experience in the comments!

If you liked this post, follow me on Dev.to, GitHub, or Linkedin — I’ll be sharing more tips as I go deeper into NeoVim and terminal-based dev workflows.

Writing Scalable Express.js Backends with the Dependency Inversion Principle.

Sandip Gyawali — Wed, 09 Jul 2025 15:13:27 +0000

In this article, I’ll explore how the Dependency Inversion Principle (DIP) can be applied to build efficient and scalable Node.js backend systems.

Recently, I set out to write a clean and maintainable Express.js backend using the MVC (Model-View-Controller) architecture, incorporating some of the SOLID principles along the way. During that process, I stumbled upon the Dependency Inversion Principle and realized how powerful it can be—especially when working with unopinionated frameworks like Express.js.

In this post, I’ll break down what Dependency Inversion is, how it fits into the architecture of a Node.js backend, and how it can help us write more modular, testable, and flexible code.

Let’s dive in!

First initialize the package.json in the file as

mkdir express-di-project && npm init

Make sure you have node and npm installed in your system.

Install the packages and dependencies required for the Application.

npm install tsyringe typedi express

After Installing we get the package.json file as
follows

{
    "name": "express-di-project",
    "version": "1.0.0",
    "description": "A Node Server",
    "keywords": [
        "js",
        "ts",
        "typescript",
        "javascript",
        "express",
        "node"
    ],
    "type": "module",
    "scripts": {
    },
    "dependencies": {
        "express": "^5.1.0",
        "tsyringe": "^4.10.0",
        "typedi": "^0.10.0"
    },
    "devDependencies": {
        }
}

Up-to this step the step and configuration part has been completed. Now we focus on the modules that can be used to implement the Dependency Inversion Principle.

Add the tsyringe and typedi modules to the helpers/helpers.di.js file in the project.

// dependency injection modules
import {
  autoInjectable,
  inject,
  injectAll,
  container,
  registry,
} from "tsyringe";
export { Service as Model, Container as Context } from "typedi";
export { Router } from "express";

export const Container = container;
export const Service = autoInjectable;
export const Controller = autoInjectable;
export const Injectable = autoInjectable;
export const Route = autoInjectable;
export const Inject = inject;
export const InjectAll = injectAll;
export const Module = registry;

Here,
1.Service / Injectable / Controller / Route
→ All are aliases for autoInjectable from tsyringe.
Automatically injects dependencies into the constructor of a class.
No need to manually register or resolve them.

@Injectable()
class UserService {
  constructor(private repo: UserRepo) {}
}

2.Inject
→ Used to manually inject a specific token or dependency into the constructor.
Useful when the type can't be inferred (e.g., interfaces or custom tokens).

constructor(@Inject("CustomRepo") repo: IRepository) {}

3.InjectAll
→ Injects all registered instances matching a token.
Great for plugin systems or processing chains.

constructor(@InjectAll("Handlers") private handlers: Handler[]) {}

4.Module
→ Alias for registry from tsyringe.
Registers a group of classes or instances for DI in one go.

@Module([
  { token: "UserRepo", useClass: UserRepository },
  { token: "Logger", useValue: console },
])
class AppModule {}

Container → The global tsyringe container instance. Manages all registered dependencies.

Container.resolve(UserService); // Manual resolution

After a brief understanding of the modules we go for the implementation section.

We divide implementation in 3 parts:
1. Defining a class with a service/auto-Injectable.
2. Using the defined class as a injection for the other class.
3. storing the instances in the registry and managing through the container/state.

Step 1:
-> Define a class/service-class and add the decorators to the class.

import { Service } from "../helpers/helper.di.ts";

@Service()
export class PingService {
  constructor() {}

  async ping() {
    const metaData: Record<string, unknown> = {
      message: "Server Connected",
      status: HttpStatusCode.OK,
    };

    return metaData;
  }
}

Step 2:
-> Using the Service() instance as the dependency in the other class. Here, we inject the class so that during the run time the application pulls the instance from the container/state.

import type { Request, Response } from "express";
import { PingService } from "../services/service.ping.ts";
import { Controller, Inject } from "~/helpers/helper.di.ts";
import { catchAsync } from "../middlewares/catch-async.ts";

@Controller()
export class PingController {
  constructor(@Inject("PingService") private service: PingService) {}

  public ping = catchAsync(async (req: Request, res: Response) => {
    const response = await this.service.ping();
    res.status(200).json(response);
  });
}

Step 3:
-> Defining a module which acts as a registry for the application in the project.

import { PingController } from "../controllers/ping.controller.ts";
import { Inject, Injectable, Module } from "../helpers/helper.di.ts";
import { PingService } from "../services/service.ping.ts";

@Module([
  {
    token: "PingService",
    useClass: PingService,
  },
  {
    token: "PingController",
    useClass: PingController,
  },
])
@Injectable()
export class PingModule {
  constructor(@Inject("PingRoute") public route: PingRoute) {}
}

Now, Using the instance of the services and controllers via the container/state in the application.

import "reflect-metadata";
import express, { Router, type Application } from "express";
import { Container, Injectable } from "./helpers/helper.di.ts";

@Injectable()
class App {
  private app: Application;

  constructor() {
    this.app = express();
    this.main();
  }

  private main(): void {
    this.middlewares();
    this.config();
    this.routes();
  }

  private config(): void {
    this.app.disable("x-powered-by");
  }

  private middlewares() {
    this.app.use(express.json());
    this.app.use(
      express.urlencoded({
        extended: true,
      })
    );
  }

  private routes(): void {
    this.app.use("/ping", Container.resolve<Router>("PingModule"));

  public listen() {
    this.app.listen(3000, (err) => {
      if (err) {
        process.exit(1);
      }
      console.log(`Listening to the server ${3000}`);
    });
  }
}

(function () {
  Container.resolve<App>(App).listen();
})();

Here, the container is the state from which we are getting the singleton instance of the controller, module and services.

TLDR;

So, By this approach we a implement scalable architecture in the nodejs/expressjs application.

Let's Connect

If you enjoyed this post and would like to stay updated, feel free to connect.

Github: https://github.com/SandipGyawali
LinkedIn: https://www.linkedin.com/in/sandip-gyawali-615681211/
Twitter: https://x.com/SandipGyawali3

DEV Community: Sandip Gyawali