Hello! I'm Hendrik Lammers, a software developer that loves building beautiful and intuitive user interfaces. Born and raised in The Netherlands, can now be found enjoying durian in Kuala Lumpur, Malaysia. Passionate about UI/UX design, programming, experimenting with new technologies and Vim.



As software developers we spend a lot of time in a code editor, so it is important to choose one that you feel comfortable with and enjoy using. Vim (or Neovim in recent years) has been that choice for me. I love how it allows me to efficiently navigate and edit text while keeping my fingers on the keyboard. Other things that are crucial for me are its speed and the ability to run in a terminal (Seamless integration with tmux). I have been using Vim for more than a decade and have no plans on switching to another editor any time soon. 

Nothing is perfect though; even Vim has its flaws. Let's have a look at some of these, based on my own experience.


## Wasting time on configuration

One of Vim's greatest benefits is the ability to customize pretty much anything you can think of. If there's something you don't like, you can change it. If some functionality is missing, you can add it. There's always something to tweak or improve. However, this flexibility comes with a danger: If you're not careful you can get lost in spending endless hours on your configuration.  
Reflecting on all the time spent configuring Vim, which I could have used to write code instead is kinda regretful. There have definitely been weekends were I planned to work on a side project, but ended up tweaking my `.vimrc` file instead.

I do enjoy tweaking my configuration, so calling it a waste of time might be a bit harsh. It is time that probably could have been spent better though.

One way to avoid spending too much time on configuration is to use one of the open-source setups available, such as [LazyVim](https://www.lazyvim.org). I haven't tried any of these myself as I'm quite happy with my current setup, but I do see the appeal it.


## Plugins for everything

By default Vim looks like a very basic text editor. To get some of the functionality that is included in modern editors by default, you often have to rely on plugins. There are plugins available for pretty much everything you can think of. In the rare case you cannot find a plugin for something, there's always the option to write it yourself.

This provides a lot of flexibility, but it also means that all these plugins (44 in my case) need to be configured and maintained. It is not uncommon for one of the plugins to contain a breaking change after an update, resulting in me having to debug why my editor is not working as expected. Or guessing what is causing the cryptic error at the bottom of the screen.  
More often than not are there multiple plugins available for the same functionality and deciding which one to use can be confusing. For example: Getting LSP and linting working can be quite a challenge due to the fragmented ecosystem.

Of course there is always the option to take a minimalist approach and install as few plugins as possible. No one is forcing you to install a plugin for everything. However plugins are essential if you're looking for a modern editor experience.


## Using a different editor than your Colleagues

While there is a large online community of Vim and Neovim users, coming across a colleague that uses Vim as their default editor is not that common. Especially if you're working at a smaller company. Most people seem to be using VSCode these days.
Of course this is not a huge problem and everyone should be able to use the editor they like. Pair programming however is much easier when both developers are using the same editor. VSCode has an extension that makes it very easy to have a remote pair programming session with another VSCode user. As Vim user you occasionally might have to be flexible and adapt to whichever editor your colleague is using.

Using Vim at work everyday, but not being able to share your passion for it, can sometimes feel a bit isolated as well. Please don't be that guy that keeps preaching to everyone about how great Vim is.


## Vim motions don't work everywhere

Once you have the Vim key bindings engraved in your muscle memory, you want to use them everywhere. Unfortunately the reality is that we have to write text in a lot more places other than our text editors. During my job I have to communicate through Slack, write tickets in Jira or write a document in Google docs. Writing text in these places feels unnatural when you're used to Vim.

Sometimes I write the text in Vim first just to copy and paste it into the other text input. This is definitely not the most efficient way to do things. In a perfect world every text input field would support Vim key bindings.


## Choosing the right editor

When deciding to use Vim as your editor, consider the points mentioned here. I've listed them as downsides, but they won't stop me from using Vim. I don't see them as deal-breakers, but they might be for you. Over the years I've adapted and learned to live with it. Moreover I believe that the benefits of using Vim by far outweigh the negatives.

I expect to happily keep using Vim in the foreseeable future. Every other code editor that I've tried in the past had its own set of problems; often much bigger than the ones mentioned in this article.

For me Vim (or Neovim) is still the best editor out there.


The downsides of using Vim


A few months ago Bram Moolenaar passed away. He is responsible for creating Vim, the text editor that I use on a daily basis. It's not just any editor, but one that I have absolutely loved since the first day I tried it. Having been a Vim user for many years, this unfortunate event seemed like a good moment to take a look back at my journey with this Vim.
Curious to know how long I have been using Vim, I searched the Git history of my Dotfiles repository to find out that the `.vimrc` file was added on June 23, 2013.

Apparently I have been using Vim for over a decade now…


## How did I get started?

I have always been the type of person who wants to use the best tools available, even if I am already using something that is good enough. After reading about this editor called Vim and how it allows you to edit text without having to use a mouse, I got very curious.  
These days YouTube is full of video's demonstrating the possibilities of Vim or Neovim, but this wasn't exactly the case 10 years ago. However I do remember one video quite well, which is this one by Ben Orenstein: [Write code faster: expert-level vim](https://www.youtube.com/watch?v=SkdrYWhh-8s). I found it very impressive and after seeing it I was sold. Vim had to be my new text editor.


## Learning how to use it

I remember quite well the resources that I used to learn Vim. I followed the Vim Tutor, which is an interactive tutorial that comes installed with Vim itself. It can be opened by running `vimtutor` on the command line. This will only teach the absolute basics, but it's sufficient to be able to navigate, edit files and most importantly: exit Vim.  

The next thing I did was print out a cheat sheet ([This one](/images/vim-cheat-sheet.gif)) and have that next to my keyboard all the time. In the beginning I mainly used it to look up the basic things like navigating. Later I also went through every key on the sheet to learn what it can be used for until I had memorized everything. I think that was also the moment I felt confident enough to start using Vim as my main editor.

Another resource from which I learned a lot, was [Vim Casts](http://vimcasts.org/) by Drew Neill. These were short videos, all focused on how to do a single thing with Vim. Especially the videos on how to use Fugitive, a Vim plugin for using Git, were very helpful.

## Making the switch from Sublime

Before this I was using Sublime Text as my main editor. It's an amazing editor and like Vim quite fast as well. I don't recall having any complains about it at the time, but I quickly became so obsessed with learning Vim and using it that I replaced it with Vim as my main editor. This went pretty well for the first few weeks…

Until I got a new job.

Remembering all the key mappings appeared to be a lot more difficult when there's also the pressure of getting used to a new working environment. Even more so when a colleague is sitting next to me staring at my screen.  
I decided it would be better to move back to Sublime Text and give Vim another try after I became completely accustomed to my new job.
Not long after that I discovered that Sublime Text had **Vintage Mode**. This allowed me to use Vim key bindings, while still being able to use all the features from a regular text editor. The best of both worlds. No more stress when I needed to copy and paste something while I was getting help from a colleague.

This transitional period must've taken around 3-6 months. I was using Sublime Text with Vintage Mode at work, while using Vim for everything in my own time. Working in Vintage Mode was quite enjoyable, but also limited compared to what Vim is capable of. I wanted to be able to use all the cool tricks I learned, use Vim plugins and use my own Vim configuration. Once I felt confident enough in both my Vim skills and my job, I decided to take the plunge. I left Sublime Text behind for good.


## tmux

In the beginning I was mostly using MacVim, the GUI version of Vim. As I started doing more and more on the command line, I switched to using Vim in the terminal as well.
While modern terminal emulators have support for tabs and split panes, using it always felt a bit clunky.
That's when I discovered tmux. This is a terminal multiplexer that makes it possible to have multiple terminal sessions in a single screen. 

With a few changes to my `.vimrc` and `.tmux.conf`, the combination of Vim and tmux worked seamlessly. Navigating between Vim buffers and the terminal sessions became effortless while only using the keyboard. I absolutely loved it, there is no way turning back now.


## Using Vim on a daily basis

Vim is my preferred text editor whenever I need to write something on the computer. I use it for writing code, commit messages, notes, and of course for writing this blog. Even when I need to write text in a program that doesn't support Vim bindings, I often write it out in Vim and then copy and paste it into the other application, such as emails or lengthy WhatsApp or Slack messages. Now that I am so accustomed to the Vim key bindings, writing text without them feels unnatural.

These days I use Neovim, which is a fork of Vim that focuses on extensibility and usability. Most modern plugins are developed specifically for Neovim, so I decided to make the switch about three years ago. One of the biggest benefits is that Neovim has support for Lua, making customizing the editor much easier than with Vimscript.


## The future

Even after 10 years it is a great pleasure to work with Vim everyday. The speed and ease at which I can edit text still feels like having super powers. The key bindings are so deeply engraved in my muscle memory, that it is hard to imagine ever using anything else. Whenever I need to write text somewhere that doesn't support Vim key bindings, I feel out of my element.

While I consider myself to be a very proficient Vim user, there is still a lot room for improvement. In both the way I use it to edit text, as well as in my configuration.
This is also what makes it appealing to me: There is always something new to learn or something that could be optimized further.
Using Vim never gets boring, even after a decade.

Thank you Bram for creating this fantastic piece of software 🙏


Reflecting on a decade of Vim


There has always been some inconsistency between the behaviour of array methods in JavaScript. Some of the methods are mutating and change the original array on which they are called, while others leave the original array untouched and return a new array.  
Methods like `map()`, `filter()` and `reduce()` do not modify the original array; they create and return a new one instead. On the other hand, methods like `sort()`, `reverse()`, and `splice()` are mutating and change the original array.

## Mutation is often undesirable

Mutation refers to the act of changing the state of an object or data structure after it has been created. And while is not necessary always bad, it does have the potential of leading to unexpected behaviour and bugs. For this reason it is often recommended to avoid mutation if possible. When working with state in React it is even a requirement: All state updates have to be immutable. The new state must be a completely new value otherwise it won't trigger at re-render.

To use the mutating array methods without changing the original array a common work-around is to first create a copy of the original array before calling the method on it.

```typescript
const original = ['c', 'a', 'b']

// Use spread operator to clone (shallow) the original array
const sorted = [...original].sort()
console.log(sorted) // ['a', 'b', 'c']

// The original array is unchanged
console.log(original) // ['c', 'a', 'b']
```

While this works fine, it would be far more convenient if we didn't have to think about
accidentally updating the original array and making sure to create a copy first.
Thankfully ES2023 brings us a few new array methods that give us the comfort of knowing that the original array stays untouched when they are called. This means it is no longer necessary to copy the original array first.

## ES2023 introduces 4 new array methods

Among the new features in ES2023 are 4 new array methods which do not mutate the original array:

- `toReversed`: Reverse an array
- `toSorted`: Sort elements in an array
- `toSpliced:` Remove, replace or add elements in an array
- `with`: Change value at array index

All these methods return a new array and leave the original array untouched.
The names of the first 3 might look familiar; they are indeed the non-mutating versions of
`reverse()`, `sort()` and `splice()`.
Let's have a look at each of these methods, see what they do and how they compare to their mutating counterparts.


### Array.prototype.toReversed

The `toReversed()` method, as the name suggests, returns a new array with the elements in reversed order. Unlike the `reverse()` method it does not mutate the original array.

```typescript
const arr = ['a', 'b', 'c']
const reversed = arr.toReversed()

console.log(reversed) // ['c', 'b', 'a']
// The orignal array is untouched
console.log(arr) // ['a', 'b', 'c']
```

View [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toReversed) for more details about `toReversed()`


### Array.prototype.toSorted

To sort an array without mutating the original array, the `toSorted()` method has been added. 
If it is called without argument it will return a copy of the array in alphabetical order.

```typescript
const arr = ['c', 'b', 'd', 'a']
const sorted = arr.toSorted()

console.log(sorted) // ['a', 'b', 'c', 'd']

// The orignal array is untouched
console.log(arr) // ['c', 'b', 'd', 'a']
```

Its sorting behaviour is the same as the mutating `sort()` method, so only an array of strings can be reliably sorted by calling `toSorted()` without arguments. To sort anything other than strings we can provide a compare function.

```typescript
const arr = [9, 13, 20, 7]
const sorted = arr.toSorted((a, b) => a - b)

console.log(sorted) // [7, 9, 13, 20]

// The orignal array is untouched
console.log(arr) // [9, 13, 20, 7]
```

View [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toSorted) for more details about `toSorted()`


### Array.prototype.toSpliced

The `toSpliced()` method can be used to remove, replace or add items in an array without modifying the original array. It works similar to the original `splice()` method.

It accepts the following parameters:
- `start`: The index at which to start changing the array
- `deleteCount` (Optional): The number of elements to remove from start index.
- `item1, item2, ...` (Optional): These items will be added to the array at the start index.

```typescript
const arr = ['a', 'b', 'c', 'd']

// Insert new element at index 2
const inserted = arr.toSpliced(2, 0, 'x')
console.log(inserted) // ['a', 'b', 'x', 'c', 'd']

// Remove 2 elements at index 1
const removed = arr.toSpliced(1, 2)
console.log(removed) // ['a', 'd']

// Replace element at index 2 with 2 new elements
const replaced = arr.toSpliced(2, 1, 'x', 'y')
console.log(replaced) // ['a', 'b', 'x', 'y', 'd']

// Original array is untouched
console.log(arr) // ['a', 'b', 'c', 'd']
```

View [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/toSpliced) for more details about `toSpliced()`

### Array.prototype.with

The `with()` method can be used to change the value at a specific index in an array.
It takes two parameters: The index and the value that should be set at the given index.

```typescript
const arr = ['a', 'b', 'c']
const newArr = arr.with(1, 'd')

console.log(newArr) // ['a', 'd', 'c']

// The orignal array is not mutated
console.log(arr) // ['a', 'b', 'c']
```

This can be seen as the non-mutating equivalent of the bracket syntax to replace a value: `arr[index] = newValue`.

View [MDN](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/with) for more details about `with()`

## Can these new array methods be used today?

Even though ES2023 hasn't officially been released yet (May 2023, as of writing), some browsers have already implemented support for these new array methods. However not all major browsers support it yet (Looking at you Firefox). If you want to start using any of the new methods today, it is recommended to use a polyfill like the one from [core-js](https://github.com/zloirock/core-js#change-array-by-copy).

The addition of the new array methods is a very welcome improvement to JavaScript and can help avoid unintentional mutations in our code. I'm looking forward to making this my go-to whenever I need to modify an array. If you prefer writing code that avoids mutations like me, then these methods will definitely make our lives easier.


Get in touch

Hendrik Lammers

Latest articles

Random notes