Je installeert Neovim, opent een leeg configuratiebestand en beseft dat je nog geen idee hebt hoe je een LSP aansluit, welke plugin-manager je nodig hebt of waarom Treesitter blijkbaar niet optioneel is. Twee projecten bestaan om je die eerste dag te besparen: LazyVim en AstroNvim. Beide doen het goed. Maar ze doen het op een andere manier, voor een ander soort gebruiker.

Wat starters oplossen — en wat ze niet oplossen

Een nakebare Neovim-installatie is een lege doos. Je hebt een plugin-manager nodig, een LSP-client, een manier om taalpakketten te installeren, fuzzy-search, een bestandsverkenner en een statusbalk — voordat de editor aanvoelt als iets productievens. Dat is geen hyperbool: de originele init.vim-aanpak vroeg minstens een middag. Starters als LazyVim en AstroNvim brengen al die lagen mee en laten je configureren in plaats van assembleren.

Maar het is belangrijk te begrijpen wat ze niet oplossen. Ze leren je de Vim-motions niet. Ze nemen de beslissing niet of je nvim-cmp of blink.cmp voor completion wil, of Telescope of fzf-lua voor fuzzy-search. En ze kunnen niet voorspellen dat Neovim 0.11 — uitgebracht in maart 2025 — de spelregels voor LSP fundamenteel veranderd heeft met vim.lsp.config() en vim.lsp.enable(). Beide APIs zijn nu native: nvim-lspconfig is technisch gezien niet meer verplicht, al gebruiken beide distros het nog als abstractielaag.

Er bestaat ook een derde optie die je minstens even serieus moet nemen: kickstart.nvim. Dit is geen distro maar een enkel bestand — een gedocumenteerd startpunt dat laat zien hoe alles in elkaar steekt. Als je wil begrijpen wat een starter voor je verbergt, lees dan kickstart.nvim naast LazyVim of AstroNvim. Dat geeft context die geen tutorial vervangt.

LazyVim in de praktijk

LazyVim is het werk van Folke Vanhoucke, dezelfde persoon die lazy.nvim schreef — de plugin-manager waar de hele Neovim-wereld inmiddels op draait. Die combinatie heeft een duidelijk voordeel: de architectuur is consistent van laag tot laag. Alles in LazyVim is een lazy.nvim-spec. Plugins activeren via import, uitbreiden via opts, overschrijven via een extra spec-file in lua/plugins/. Je leert één patroon en je bent klaar.

Het systeem voor optionele uitbreidingen heet LazyExtras. Je roept :LazyExtras op en krijgt een interactief menu met tientallen kant-en-klare bundels: lang.rust, lang.typescript, coding.copilot, editor.outline. Een extra inschakelen duurt twee seconden. Achter de schermen worden de juiste LSP-servers, Treesitter-parsers en formatters automatisch geconfigureerd via Mason. Je hoeft niet te weten welke mason.nvim-naam hoort bij welke LSP.

De keerzijde is dat LazyVim zich eigenwijzer gedraagt dan het lijkt. Defaults zijn sterk opinionated: keybindings, buffer-tabs via bufferline.nvim, een bestandsverkenner via neo-tree.nvim, completion via nvim-cmp (recent migrerend naar blink.cmp). Als jij liever Telescope gebruikt dan fzf-lua, of liever helemaal geen statusbalk, moet je dat expliciet uitschakelen. LazyVim overschrijft je niet brutaal, maar het vraagt wel kennis van Lua en van de lazy.nvim-specificatie om echt van koers te veranderen.

-- lua/plugins/telescope.lua — Telescope toevoegen naast fzf-lua
return {
  {
    "nvim-telescope/telescope.nvim",
    dependencies = { "nvim-lua/plenary.nvim" },
    keys = {
      { "<leader>fp", function() require("telescope.builtin").find_files() end, desc = "Find files (Telescope)" },
    },
  },
}

"LazyVim is sneller te begrijpen dan te beheersen. AstroNvim is langzamer te begrijpen maar makkelijker te sturen."

Voor wie vanuit VS Code of een andere grafische editor naar Neovim stapt en zo snel mogelijk productief wil zijn, is LazyVim de betere keuze. De installatie is vijf commando's, de editor laadt vlot, de defaults zijn goed doordacht. Je kunt daarna beslissen hoever je de configuratie induikt.

AstroNvim in de praktijk

AstroNvim v4 is eind 2023 volledig herschreven en heeft sindsdien nog meerdere majors gekregen — v6 bracht treesitter-migratie naar de main-branch en mason-lspconfig v2. De fundamentele architectuurkeuze van v4 staat nog steeds: AstroNvim is niet langer een repo die je clonet. Je voegt het toe als plugin en importeert de specs die je wil. Dat maakt AstroNvim composable op een manier die LazyVim minder expliciet aanbiedt.

De kern bestaat uit drie eigen plugins: AstroCore beheert keymaps, autocmds, en globale opties via één tabel. AstroUI stuurt kleurschema, statuslijn en tabline. AstroLSP is een volledige LSP-configuratie-engine die server-specifieke instellingen, capabilities en on_attach-gedrag centraliseert. Die scheiding is architecturaal schoner dan LazyVim, maar vraagt ook meer van je om te doorgronden.

-- plugins/astrolsp.lua — een extra LSP-server toevoegen
return {
  "AstroNvim/astrolsp",
  opts = {
    servers = { "pyright", "ruff_lsp" },
    config = {
      pyright = {
        settings = {
          python = { analysis = { typeCheckingMode = "strict" } },
        },
      },
    },
  },
}

Het grootste verschil met LazyVim zit in AstroCommunity: een publiek repo met plugin-specs bijgedragen door de gemeenschap. Er zijn meer dan veertig taalpaketten en tientallen integraties. Wil je Rust-ondersteuning met rust-analyzer, rustfmt, crates.nvim en de juiste Treesitter-parsers? Voeg één import toe:

-- plugins/community.lua
return {
  "AstroNvim/astrocommunity",
  { import = "astrocommunity.pack.rust" },
  { import = "astrocommunity.pack.python" },
  { import = "astrocommunity.colorscheme.catppuccin" },
}

Dat systeem is krachtiger en flexibeler dan LazyExtras omdat elke spec volledig overschrijfbaar is. Maar het model heeft ook een zwakte: de kwaliteit van AstroCommunity-specs varieert. Sommige worden actief onderhouden, andere lopen weken achter op upstream-wijzigingen. Controleer altijd de commit-datum van een community-pack voor je hem in een productieve setup gebruikt.

AstroNvim is ook explicieter over Mason: de ingebouwde Mason-integratie vraagt je welke tools je wil installeren, maar installeert niets zonder dat je het aangeeft. Dat is preciezer dan LazyVim, dat Mason-installaties soms impliciet triggert vanuit een extra.

Wanneer je moet stoppen met starters

Starters lossen het bootstrapping-probleem op. Ze lossen het begripsprobleem niet op. Er komt een moment — voor sommige gebruikers na een week, voor anderen na een jaar — waarop de abstractielagen meer in de weg staan dan ze helpen.

Concrete signalen dat je die grens nadert:

  • Je debugt een keymap-conflict en je weet niet welke van de twaalf geïmporteerde specs hem instelt.
  • Een plugin-update breekt iets en je kunt niet achterhalen of het een LazyVim-defaults-probleem is of een upstream-probleem.
  • Je wil vim.lsp.config() gebruiken — de native Neovim 0.11 API — maar de starter overschrijft je setup stilzwijgend via nvim-lspconfig.
  • Opstartsnelheid is een echte bottleneck en je wil precies weten welke plugin hoeveel laadtijd kost.

Op dat punt heeft het meer zin om een eigen config te bouwen, vertrekkende vanuit kickstart.nvim of een leeg bestand. Dat klinkt als een stap terug, maar het is in de praktijk een stap voorwaarts: je leert de lazy.nvim-spec echt beheersen, je begrijpt hoe vim.lsp.enable() werkt, je kiest bewust welke Treesitter-parsers je wil. Beide starters zijn uitstekend als doorloper, maar geen eindstation voor gebruikers die Neovim als kerngereedschap zien.

Dat neemt niet weg dat de meeste mensen dat punt nooit bereiken — en dat is volledig terecht. Als LazyVim of AstroNvim doet wat je wil, is er geen reden om te wisselen.

Veelgestelde vragen

Kan ik van LazyVim naar AstroNvim migreren zonder alles te verliezen? De plugins die je hebt toegevoegd zijn gewone lazy.nvim-specs en zijn overdraagbaar. De LazyExtras-configuratie moet je handmatig omzetten naar AstroCommunity-imports of eigen plugin-files. Verwacht een halve avond voor een gemiddelde setup.

Ondersteunt AstroNvim de nieuwe Neovim 0.11 LSP-APIs? AstroLSP abstracteert de LSP-setup, maar draait intern nog op nvim-lspconfig. De native vim.lsp.config() en vim.lsp.enable()-APIs zijn bruikbaar naast AstroLSP, maar je moet oppassen op conflicten als je dezelfde server op twee manieren configureert.

Welke starter is sneller qua opstartijd? Met een gelijkwaardige plugin-set liggen beide starters dicht bij elkaar — typisch 80–150 ms op een moderne machine. LazyVim laadt plugins standaard lazy (uitgesteld), maar AstroNvim doet dat ook. Het grootste verschil komt van de plugins die jij zelf toevoegt, niet van de starter zelf.

Is NvChad nog een serieuze optie in 2025? NvChad heeft een andere filosofie: minder aanpasbaar, meer visueel consistent. Het is een serieuze keuze als de UI-laag je prioriteit is, maar voor LSP- en workflow-aanpassing bieden LazyVim en AstroNvim meer controle.

Moet ik Treesitter handmatig configureren? In beide starters niet. LazyVim installeert Treesitter-parsers automatisch als je een LazyExtra voor een taal inschakelt. AstroNvim doet hetzelfde via AstroCommunity-taalpakken, of je kunt parsers toevoegen via de treesitter-tabel in AstroCore. Handmatige :TSInstall-commando's zijn optioneel.