As a DevOps engineer, I recently reached a significant milestone: I switched code editors for the fifth time in my career. When I first began writing code, I quickly settled on using Vim. Despite its reputation for being fast and efficient, what drew me to Vim was the endless possibilities for customization through plugins, abbreviations, hotkeys, and scripts. As a result, I spent significant time customizing my setup. Over time, my customization had become so extensive that it was difficult to understand. My customizations also made it difficult to switch to a different editor, as I had grown accustomed to my unique Vi environment. After switching to a Mac, I painfully transitioned from Linux GVim to MacVim, essentially the same thing, so I don't consider that an actual switch. My next move was to Sublime Text, as I was beginning to work with Python and wanted to avoid navigating VimScript to reconfigure my editor. With the help of the Vintageous plugin, Sublime Text provided me with all the familiar hotkeys I was used to, and the built-in language plugins helped me quickly become proficient in the Python language. A year later, as I began incorporating TypeScript into my stack, I switched from Sublime Text to Visual Studio Code (VSCode). At the time, VSCode was the only lightweight editor that could handle both Python and Node.js and had Vim hotkeys. As I continued to use VSCode, I noticed that the editor was becoming increasingly slow. The transition from Sublime Text to VSCode was particularly noticeable due to the latter's electron-based architecture. Over time, VSCode's performance only worsened as more unnecessary features were added, and the electron framework became increasingly slow. Eventually, I grew tired of the sluggishness and began searching for an alternative. To my surprise and delight, I discovered that the community had addressed one of Vim's main issues in the past few years by eliminating the need for VimScript. Now, plugins can be written in any language, and developers have taken advantage of this by porting several JavaScript plugins from VSCode to the faster Neovim. After a couple of weeks of adjusting to the transition, I again found myself using an editor that doesn't drain my laptop battery and runs faster than I can lose interest in writing code. I wish someone else would do the same with Docker (and maybe Notion).

This story contains new, firsthand information uncovered by the writer.

Custom Log Processor Integration – Fluentd vs Vector.dev

Understand NeoVim Modes Once and Navigate Them Like a Pro — Here's How

Read My Stories

Too Long; Didn't Read

Make resilience your competitive advantage

Transitioning From VSCode to NeoVim

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Will DevOps Cease to Exist? My Honest Opinion

5 Vim Plugins I Can’t Live Without for Javascript Development

A Beginner's Guide to Vim

Changing to Neovim

My neovim setup for Go

Will DevOps Cease to Exist? My Honest Opinion

5 Vim Plugins I Can’t Live Without for Javascript Development

A Beginner's Guide to Vim

Changing to Neovim

My neovim setup for Go

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps