Learn Neovim - Custom Config vs Neovim Distros (LazyVim, NvChad, AstroNvim)

#Introduction

After discussing dotfiles management in episode 24 — how to store config in Git and bootstrap new machines automatically — in this episode we face the question most frequently asked in the Neovim community: "Why bother building a config from scratch? Can't I just install LazyVim and be done?"

That question is valid, and the answer is not as simple as "yes" or "no". Many productive engineers use distros like LazyVim, NvChad, or AstroNvim as their daily drivers — and just as many build custom configs from scratch. Both can produce a great editing experience; the difference lies in the tradeoff between setup speed and control.

In real work, this decision is like choosing between a managed service and self-hosting: LazyVim is like using a managed platform someone else has already set up (quick to run, free updates), while a custom config is full self-hosting (total control, but full responsibility). This episode will help you decide which is right for your situation, and more importantly — how to make Neovim a true daily driver, whatever you choose.

#Main Discussion

#What Is a Neovim Distro?

A Neovim distro is a community-maintained, ready-to-use config — a set of choices already made for you: which plugins are installed, what keymaps are used, what colorscheme, even the directory structure. All of it is built on a modern plugin manager (lazy.nvim for all three), so you can still add your own plugins through the provided override mechanism.

The analogy is like Linux distributions: a distro is Ubuntu (everything is already there, just use it), while a custom config is Linux From Scratch (you assemble it yourself). Both are Linux underneath — both are Neovim underneath — but the experience and degree of control are very different.

#Getting to Know the Three Big Distros

LazyVim was created by Folke Lemaitre — the author of lazy.nvim, which-key.nvim, and flash.nvim — so its quality is beyond doubt. It is the most "opinionated": it uses LazyVim as a core plugin providing very complete defaults (keymaps, autocmds, formatter mappings, and more). Customization is done by writing plugin specs and adding opts = {} or config = function() ... end to override its defaults. Because it is built on lazy.nvim, every plugin in LazyVim is already optimally lazy-loaded.

NvChad comes with the philosophy of "beauty and performance" — its look is very clean with nvim-web-devicons and its own theme. Customization goes through the chadrc.lua file and the lua/custom/ directory, which makes it feel like a neatly structured regular config. NvChad is the lightest of the three distros and is widely used as a base for starting to build your own config.

AstroNvim (by C.T. Lin, author of toggleterm.nvim) takes a modular approach: configuration is broken into modules like astrocore, astroui, astrolsp, astrogit. It gives the best balance between rich defaults and override flexibility. AstroNvim has the astrocommunity ecosystem — a collection of ready-to-use plugins that just need importing.

#Direct Comparison

#Pros & Cons: Custom Config

Pros:

• Full control. Every plugin, keymap, and config line exists because you wrote it. No "mystery features" you do not recognize.
• Deep understanding. Building from scratch forces you to understand what is actually happening behind the scenes — a lifelong skill that is useful for debugging.
• Minimal and light. You only install what you actually use, so startup time is very controlled.
• No dependency on upstream. No risk of being surprised by major changes from someone else's project.

Cons:

• Expensive at the start. It takes time and effort to assemble until comfortable to use.
• Manual maintenance. You yourself must update plugins, fix breaking changes, and add new features.
• Can become a "snowflake". A too-custom config becomes hard for others to understand (and sometimes for yourself a few months later).

#Pros & Cons: Distros

Pros:

• Productive immediately. Clone, open, and your Neovim already feels like a modern IDE — LSP, completion, formatting, all working.
• Tested standards. The keymaps and plugin structure are curated by thousands of users; the patterns used have been tested across many codebases.
• Automatic updates. Bug fixes and new features come from the community regularly.
• Large community. Complete documentation, abundant tutorials, and solutions already exist before your problem appears.

Cons:

• Limited control. You must follow the structure they set; changing something very fundamental can feel like swimming against the current.
• Upgrades can break your config. Major releases sometimes require migrating the config you overrode.
• Bloat. Distros install many plugins you may not need — the consequence is a larger config size and more "noise".
• A "black box" if not studied. If you just use it without understanding the structure, you will not be able to adapt when something breaks.

#When to Choose Which?

There is no universal answer — there is context. Use the following questions as a guide:

The honest answer often given by veterans: start with a distro if you want to be fast, but still learn its structure; or start with custom if your goal is to understand Neovim. In this series, you have gone through 24 episodes building a foundation — so the natural direction is choosing custom with the knowledge you have.

#Understanding Distro Customization Mechanisms

So your decision is based on understanding (not just trends), let's look at how customization works on each path. All modern distros are built on lazy.nvim — the only difference is how they wrap the override mechanism. Notice the following comparison:

-- ~/.config/nvim/lua/plugins/colorscheme.lua
return {
  { "catppuccin/nvim", lazy = false, priority = 1000, name = "catppuccin" },
  {
    "LazyVim/LazyVim",
    opts = {
      colorscheme = "catppuccin",
    },
  },
  -- Override keymap bawaan LazyVim
  {
    "folke/which-key.nvim",
    opts = {
      spec = {
        { "<leader>ff", "<cmd>Telescope find_files<CR>", desc = "Cari File" },
      },
    },
  },
}

-- ~/.config/nvim/lua/plugins/astroui.lua
return {
  {
    "AstroNvim/astroui",
    opts = {
      colorscheme = "catppuccin",
    },
  },
  -- Tambah plugin baru dengan pola yang sama seperti custom config
  {
    "catppuccin/nvim",
    lazy = false,
    priority = 1000,
    name = "catppuccin",
  },
}

-- ~/.config/nvim/lua/plugins/colorscheme.lua
{
  "catppuccin/nvim",
  lazy = false,
  priority = 1000,
  config = function()
    require("catppuccin").setup({ flavour = "mocha" })
    vim.cmd.colorscheme("catppuccin")
  end,
},

-- ~/.config/nvim/lua/chadrc.lua
local M = {}
M.ui = { theme = "catppuccin" }
return M
 
-- ~/.config/nvim/lua/custom/plugins.lua
return {
  { "catppuccin/nvim", lazy = false, priority = 1000 },
}

The most important pattern to notice: all three distros still use lazy.nvim specs underneath. Once you understand how lazy.nvim specs work from episodes 9 and 23, using a distro is just a matter of learning where the overrides go — not learning a new concept. This is why the foundation built throughout this series is never wasted, whatever you choose.

#The Migration Path: From Distro Toward Custom

Many distro users eventually "graduate" and switch to a custom config. The process does not have to be black and white. There is a natural gradual path:

1. The distro mastery phase. Use a distro, learn its directory structure, read :checkhealth, take apart the installed plugins one by one. Goal: understand why each part exists.
2. The override-making phase. Start changing keymaps and options through the distro's override mechanism. Feel how customization works without writing everything from scratch.
3. The "uninstall plugin" phase. Disable plugins you never use. The distro becomes lighter and you start to know exactly the composition of your config.
4. The rebuild phase. With knowledge from phases 1-3, initialize a new config from scratch — only with the plugins you actually need, following the modular structure you learned from the distro.

This path shows something important: a distro is not the enemy of custom, but a teacher. Most people who seriously use a distro end up understanding Neovim more deeply precisely because they started from something complete and functional, then took it apart slowly.

#Reflection: Making Neovim a Daily Driver

All the technical discussion above boils down to one goal: Neovim you use every day, all day long. Some principles that distinguish a config that is "used" from a config that is "just made":

1. Consistency is more important than perfection. A config that is used is a config that is stable. Do not keep changing keymaps or plugins every week — muscle memory takes time to form.
2. Focus on workflow, not features. Question every plugin: "does this speed up my actual work?" If not, throw it away.
3. Make it boring where it should be. Keymaps for things you do often (edit, navigation, git, test) must be as simple as possible and not changeable. Innovation is only for areas that really need it.
4. Small recurring investments. Do not wait for "free time" to tune the config. Every time you find a small friction while working, note it and fix it in 5 minutes — this is the compound interest of productivity.
5. Measure the impact on work speed, not startup speed. One keymap that removes three manual steps is more valuable than 5ms of startup.

#Common Pitfalls

1. Distro lock-in. Thinking the config "belongs to LazyVim" so never daring to change its structure. But whatever the distro, that config is ultimately run by the same Neovim — you always have full control through overrides.

2. Config bloat. Whether from a distro or from the habit of endlessly adding plugins, a config containing 100 plugins but only 20 used is a burden. Do periodic audits: throw away what has not been used for at least a month.

3. Mixing customization methods. Changing the distro config through three different mechanisms (editing the distro's core files, adding overrides, and a second plugin for the same function) makes the config hard to maintain. Choose one path — preferably the provided override.

4. Upgrading without reading the changelog. Big distros sometimes release breaking changes. Read the release notes before a mass update, or you will spend the night figuring out why a keymap is gone.

5. Switching distros every month. "This week LazyVim, next week NvChad" is the main enemy of muscle memory. Choose one, master it, then switch with a clear reason.

#Closing

In episode 25 we dissected the comparison between building your own config from scratch and using Neovim distros like LazyVim, NvChad, or AstroNvim. We saw that they are not opponents, but two points on the same spectrum: distros give speed and tested standards, custom gives control and understanding. The best decision depends on your context — available time, learning goals, and work environment needs — and most importantly, both equally demand an understanding of how Neovim works.

A final message for this episode: whatever you choose, make Neovim a daily driver with consistency, not with plugin count. An editor you master well is far more valuable than the most sophisticated editor that keeps you experimenting endlessly.

In episode 26, we will fill one of the biggest gaps of an IDE that we have not yet fully discussed: testing. We will integrate neotest so you can run and navigate tests — a single test, a file, or an entire suite — without ever leaving the editor. See you in the next episode!