Switching from PhpStorm to Neovim and a terminal-based workflow made my developer life harder. It also made it a lot easier. Both are true, and if you’re a curious IDE user wondering whether to switch, you should hear both sides.
I’ve used Neovim as my main editor for a couple of years now, together with tmux, lazygit, fzf and ripgrep. This isn’t a “Vim is superior” post. It’s an honest look at what it costs, what it gives back, and how to try it without wrecking a week of productivity.
The short version
Neovim is harder to learn and needs looking after. In return you get a faster, calmer editor that looks the same no matter what you add, runs identically on every machine, and does exactly what you tell it to. For me that trade is worth it.
Why I left PhpStorm
PhpStorm is a great IDE, and I don’t want to pretend otherwise. It knows PHP and Laravel deeply, refactoring is excellent and the debugger just works. But over time a few things started to bother me.
It felt heavy: slow to start, busy with indexing, and full of panels and popups I never asked for. Every update moved something. And whenever I SSH’d into a server I was back in an unfamiliar editor with none of my shortcuts. I wanted one environment that I understood completely and could take anywhere.
What makes Neovim harder
The learning curve is real
Modal editing is the first wall. In Neovim you don’t just type; you switch between modes for moving, inserting and selecting, and you edit with motions like ciw (change inner word) or dap (delete a paragraph). It’s powerful, but for the first week or two I was noticeably slower than in PhpStorm, and that’s frustrating when you have real work to ship.
It isn’t only the editor, either. Moving to a terminal workflow means learning tmux for panes and sessions, lazygit for version control, and fuzzy finders for navigation. Each tool is simple on its own, but together it’s a lot of new muscle memory at once.
You maintain your own editor
An IDE is a product someone else maintains. A Neovim setup is closer to a small software project that you maintain. My configuration is written in Lua and pulls in plugins for language servers, completion, formatting, linting, debugging and Git.
That comes with the usual software problems. A plugin update occasionally breaks something, a Neovim release deprecates an API, and a quick tweak can turn into an evening of tinkering. The rabbit hole is real: it’s very easy to spend more time improving your editor than using it.
Watch out for the tinkering trap
Set yourself a rule: only change your config when something actually slows you down. Otherwise “one small improvement” eats your afternoon.
What makes Neovim easier
Speed and flow
Once the motions are in your fingers, editing gets fast in a way that’s hard to go back from. Neovim starts instantly, everything happens from the keyboard, and navigation is a few keystrokes away. I use telescope to fuzzy-find files and search the project, and harpoon to jump between the handful of files I’m actively working on.
The bigger win isn’t raw speed, though, it’s flow. There’s no reaching for the mouse, no hunting through menus and no waiting for indexing. I stay in my head instead of in the tool.
The UI always stays the same
This is the one I underestimated. In a traditional IDE, every plugin brings its own tool window, toolbar icon or notification, and every update rearranges things. The interface slowly fills up.
Neovim doesn’t work like that. Whether I add a debugger, an AI assistant or Laravel tooling, the screen is still just my code, a status line and whatever I choose to open. New features become new commands and keybindings, not new clutter. My editor looks the same today as it did two years ago, and that consistency is surprisingly calming.
Small tools that work together
A terminal workflow is built from small tools that each do one thing well. tmux keeps my sessions and panes alive, lazygit handles staging and commits, ripgrep and fzf search everything, and delta makes diffs readable.
Because they all speak text, they combine. Neovim can call them, scripts can chain them and I can swap any one of them out without replacing the rest. With an IDE, you get whatever integration its vendor decided to build.
The same setup everywhere
Terminal tools run anywhere there’s a shell: my laptop, a Linux server, a remote box over SSH. To make that painless I built dot, a small dotfiles CLI that installs my tools and configuration on a new machine in one command, without needing sudo:
terminal
dot install --profile desktop # full workstation
dot install --profile server # lean setup for serversA new laptop or a fresh server now feels like home within minutes, and because the whole configuration lives in one Git repository, every machine stays in sync.
You own your editor
Every feature in my editor is there because I put it there. That includes AI. I use Copilot for inline suggestions and Claude Code in a split, but I can turn them off globally or per buffer with a single keybinding, and they never attach to files like .env or private keys. I decide what leaves my machine, not a default setting.
Owning it also means knowing it. When something misbehaves I can open the config and see why, instead of searching an IDE’s settings dialog. And it’s lightweight: Neovim with a full language setup uses a fraction of the memory a JetBrains IDE does.
Is switching to Neovim worth it?
It depends on what you value. Neovim is probably a good fit if you:
- enjoy understanding and shaping your tools
- work a lot in the terminal or on remote servers
- get distracted by busy interfaces
- want one setup across every machine you use
You may be happier staying in your IDE if you:
- rely heavily on visual refactoring, database tools or GUI profilers
- don’t want to maintain any configuration at all
- can’t afford a slower week or two right now
How to try Neovim without losing a week
- Learn the motions first. Run
vimtutorand practise for fifteen minutes a day, or enable Vim keybindings in your current IDE. - Start from a starter config. Use something like kickstart.nvim instead of writing everything from scratch.
- Keep your IDE installed. Use Neovim for smaller tasks first and fall back when a deadline hits.
- Add one terminal tool at a time. lazygit is an easy first win; tmux can wait.
- Put your config in Git from day one. Future you, on a new machine, will be grateful.
Frequently asked questions
Can Neovim replace PhpStorm or VS Code?
For most day-to-day work, yes. With the built-in LSP client, treesitter and a handful of plugins you get completion, go-to-definition, refactors, formatting, linting and debugging. What you give up is the polish of things like database browsers and visual refactoring wizards, which you’ll either replace with terminal tools or keep an IDE around for.
How long does it take to learn Neovim?
Expect one or two slow weeks before you’re as fast as you were, and a few months before modal editing feels natural. Running vimtutor and learning a few motions a week works better than trying to memorise everything at once.
Do I need to write my own Lua config?
No. A starter config such as kickstart.nvim gives you a working, well-commented setup in minutes. You’ll probably end up changing it, but you don’t have to start from an empty file.
Is Neovim good for PHP and Laravel?
Yes. Intelephense or phpactor for language support, pint and phpstan through conform.nvim and nvim-lint, nvim-dap for Xdebug and laravel.nvim for artisan and routes make it a very capable Laravel editor, including when the project runs in Docker.
Harder, but easier
Neovim asked more of me up front than PhpStorm ever did, and it still asks for a bit of maintenance. But it gave me an editor that’s fast, quiet, the same on every machine and entirely mine. The hard part was temporary. The easy part is every day.
Curious how my setup fits together? Take a look at dot, where my whole Neovim and terminal configuration lives.