- The licence twist behind VSCodium
- Seven editors at a glance
- Same editor, different build
- Other desktop editors
- Vim-style and terminal editors
- IDEs built around one language
- What you'll miss, and what you won't
- What about AI in your editor?
- Switching as a team
- A one-week editor trial
- Frequently asked questions
Leave VS Code if you want something lighter, a build with different licence terms, a workflow that lives in the terminal, or an IDE shaped around one language. Native and terminal editors suit people who prize speed and little setup, language-specific IDEs suit heavy refactoring, and community builds suit anyone who wants licensing and telemetry settled.
VS Code's own page says rich language support, precise navigation and integrated debuggers keep you close to your code. So if you're a developer looking around, it's rarely because it can't do the job. It's more likely the licence, the telemetry, a wish for something different, or a language that a specialist IDE handles better.
This page groups the alternatives by that reason, so you can skip straight to the one that fits.
The licence twist behind VSCodium
VS Code's source code is available under the MIT licence, but the download you get from Microsoft carries Microsoft's own software licence terms. The code and the product you install aren't licensed the same way.
That gap is the reason VSCodium exists. It's a community-driven, freely licensed build of the same editor, and its page says telemetry is disabled in what it ships. If your only complaint is the licence or the data your editor sends home, this is the smallest possible move: same editor, different build.
Before you change anything bigger, ask yourself whether that's the real itch. If it is, you can keep your habits, your shortcuts and most of your setup. If it isn't, read on. The groups below go from the smallest change to the biggest, so stop reading at the first one that solves your problem.
Seven editors at a glance
| Editor | Group | Licence note |
|---|---|---|
| Helix | Terminal | Open source |
| JetBrains IDEs | Language-specific | Some free for non-commercial use |
| Neovim | Vim-style | Open source |
| Notepad++ | Other desktop | GNU GPL |
| Sublime Text | Other desktop | Commercial |
| VSCodium | Different build | Freely licensed |
| Zed | Other desktop | Open source |
Same editor, different build
The gentlest switch of all. If you depend on particular add-ons, check that the extensions you'd miss most are available for this build before you move.
VSCodium
Because it's built from the same source, your habits and most of your settings come with you. The difference is in the licence and what the build sends home.
Other desktop editors
If you'd like a different desktop editor rather than a different build, these three are worth a look. Open your largest project in each and see which one stays out of your way.
Notepad++
Its use is governed by the GNU General Public License. Try it on the small, quick edits you make every day before deciding whether it can carry a whole project.
Sublime Text
Its page says it can use your GPU when rendering the interface on Linux, Mac and Windows. Judge the rest by opening a real project in it.
Zed
Its page describes it as open source. If you want AI help only when you ask for it, test how it feels with AI left switched off for a few days.
Vim-style and terminal editors
If you spend most of your day in a shell, or work on remote servers over SSH, a keyboard-first editor means one less window and one less context switch. Expect a learning curve: that style takes a few weeks to feel natural.
Helix
A terminal text editor written in Rust. It's the one here that's explicitly built for the terminal, so try it over SSH as well as locally.
Neovim
A hyperextensible, Vim-based text editor with Lua plugins. If you like building your own setup piece by piece, that plugin system is the reason to try it.
IDEs built around one language
If most of your work sits in one language and you do a lot of refactoring, a dedicated IDE can know that language more deeply than a general editor with add-ons. The trade is that you may end up with different tools for different languages, each with its own settings to learn. If you mostly write one language for a living, that's rarely a problem; if you hop between five, a general editor may still suit you better.
Want AI doing the heavy lifting in your marketing?
I build the systems that handle the boring 80 percent, so you get your week back. Done properly, with the human kept in.
JetBrains IDEs
JetBrains lists a separate IDE for each language, IntelliJ IDEA for Java and Kotlin among them. Match it to the language you write most days, and ignore the rest of the family.
What you'll miss, and what you won't
You'll probably miss a favourite add-on or a shortcut at first; resist recreating everything on day one. A switch is a good excuse for a clean start, and panels you never opened, add-ons you forgot installing and settings copied from an old blog post can all stay behind. If the newcomer offers a keymap that mimics your old shortcuts, decide on purpose whether to use it or learn the native ones.
What about AI in your editor?
AI help has become a reason to stay or leave in its own right. Some developers want it everywhere; others want it nowhere near their code. Zed, for one, describes AI as optional. Decide which camp you're in before you trial anything, and check how each candidate handles it, because a default you dislike will nag at you every day.
Switching as a team
If you work alone, change editors whenever you like. On a team, think about shared settings, formatting rules and the onboarding notes new starters follow. Nobody has to use the same editor, but the project should build, test and format the same way whatever people type in. Put those rules in the repository, not in one person's editor config, and a switch stops being a team-wide event.
A one-week editor trial
Switching editors is a habit change more than a software change. Give it a week of real work, not a weekend of tinkering, and judge it on day five rather than day one.
- List the shortcuts, add-ons and settings you'd hate to lose.
- Open a real project, not a hello-world, on day one.
- Run your usual debugger, tests and version control from inside the new editor.
- Recreate only the setup you miss, as you miss it.
- Keep your old editor installed, but try not to open it.
- At the end of the week, note what slowed you down and what you didn't miss.
If you end up staying put, a fresh look can still help. Our round-up of editor themes is an easy way to make a familiar tool feel new.
Want your tool on this list? Featured spots and reviews here are paid partnerships. Here's how to partner with me.
Frequently asked questions
Can I bring my own AI key to VS Code?
Yes. It lets you pick from several AI model providers or bring your own key.
Is Notepad++ available on a Mac?
No, it's made for Windows. If you're on a Mac, Sublime Text is worth a look, since it supports Mac alongside Linux and Windows.
Can I try JetBrains IDEs without paying?
Several, such as WebStorm, are marked free for non-commercial use. For work projects, read the licence terms on JetBrains' own site first.
Which JetBrains IDE is for Python?
PyCharm is the one JetBrains lists for Python. Its other IDEs each target a different language.
Does Neovim work with my Vim config?
It says it's fully compatible with Vim's editing model and Vimscript v1, so most Vim setups should carry over. Load your own config on day one to be sure.
Does Helix have a plugin system?
Not yet. Its FAQ says there's currently no plugin system, though the team intends to add one eventually.
