How Flowtype moved me from Webstorm to VS Code

I’m going to be honest, writing tests is not my favorite thing to do (but it doesn’t mean that I don’t do it). I remember at some point for instance, I had to check whether a function rejected a particular value or not and I found myself writing something like this:

expect(typeof(var)).toEqual('number')

That was it. It felt like I was writing my own tiny, unevolved type checker — like reinventing the wheel, while hating wheels in general. Pretty soon I realised instead of just doing it myself, I should have shortened the process and started to use a static type checker. I chose Flow since it fitted right in with my current setup.

One of the main advantages I was hoping for was to receive instant feedback on my code by checking changes and analysing its correctness — I wanted something that not only spotted errors, but that also offered some level of intellisense. Flow does this by integrating with your code editor. This is when the role of editors started to matter, and Webstorm started to suck.

The Frustration

Flow-bin package: installed.

Configuring project and Webstorm: done.

Type annotations: added.

Result: simply sluggish.

Webstorm code analysis became considerably slow after adding Flowtype in addition to Eslint check. Sometimes it took to up to six seconds on my Quad Core i7 (16GB RAM, SSD) MBP to show all of the errors and warnings. I’ve always been a big fan of JetBrains and never was less than satisfied with their products, but this was a deal breaker. Using Flowtype on Webstorm was so unbearable that I had no choice but to look around for an alternative.

At this point there had already been constant noise around VS Code in our office. The community also had been praising it for its swiftness for the last two years, so I knew I needed to consider it when it came to performance. Much to the surprise of my colleagues, I turned a blind eye to VS Code and kept living my miserable life with Webstorm for a while.

The hesitation

While VS Code is free and open source which is more than ideal; for me, it was the thought of going back to Microsoft that stopped me from making the move straight away. To be honest, working with Microsoft brings me back to some dark memories. Coding experience and how things look is so important to me and when it comes to Microsoft, we’re talking about a company that thinks it’s ok to have multiple rows of tabs on a panel and ship it out there for billions of people to see.

The horror of tabs

This mess was taken to another level with classic Visual Studio. I found myself going through wizards, ticking check boxes and selecting rows of tabs (their favourite) like an MS Office user rather than a developer.

This is a real screenshot from one of visualstudio documentations

I remember there was once a menu somewhere labeled as something similar to ‘convert this web solution to an mvc solution’. Simply by clicking it — without typing any code or having any control whatsoever — it would perform some kind of magic and god knows what it would have done to my codebase behind the scene.

The jump

So two months ago, I bit the bullet and decided to download VS Code. I just very carefully visited https://code.visualstudio.com/ and downloaded the editor (If you miss the word ‘code’ you will end up in https://www.visualstudio.com/ where you will most likely see smiling people in suits giving you a thumbs up). I have to say VS Code was nothing like my experience with classic Visual Studio. It was so minimalistic, in an enjoyable way that keeps you focused on the code and nothing else. Just look at these settings for instance, nicely presented as a JSON:

VS Code settings.json

It is nothing like what caused my old Visual Studio trauma. Setting up Flowtype was simple(ish) and instant validation was fast. Your type errors are reflected in your ‘Problems’ list (⌘ Numpad 0) which makes them super easy to just spot and resolve straight away.

Spotted type error

The result

Overall after one month I feel positive about my move (and £70 richer). Apart from some occasional annoyance (such as no support for multiple terminal tabs, offering a cheap dropdown instead) VS Code has been a much faster and more pleasant coding companion. You might prefer to stick with Webstorm, and if so leave a comment below and let me know why it works well for you. For me though, I’m afraid it’s too late. With VS Code, I think this is the beginning of a beautiful friendship.

Recommendations

• If you’re like me and come from Webstorm, I suggest you install ‘IntelliJ IDEA Key Bindings for VS Code’ and you’ll feel at home straight away. However, this may not cover all the shortcuts (for instance I used to hit double shift to look for a file and now in VS Code I do the same with cmd+shift+a or simply F1).
• You may realise that your Eslint errors in VS Code’s ‘Problems’ list (⌘ Numpad 0) starts with a low number and then as you open more files, more errors pile up on the list; this is basically its VS Code incremental approach. In other words you will never have a full global list of your Eslint errors unless you open all files. You can address this issue quite easily by creating a task to check all your files and updates your ‘Problems’ list. Then you run that task once in awhile and update the list and get on with your life (coding). The process is explained in section four of this article.
• Configuring Flowtype and Eslint on VS Code can be a little bit tricky. As much as Flowtype checking was smooth, in my experience Eslint checking didn’t seem to be responsive at all and it took me a while to set it right. For setup/config details check out this article by Sean Groff.