Welcome to part 5! Today we're going to talk about Integrated Development Environments (IDE). You may recall from our Git tutorials that we used Windows Notepad to edit our files that we were tracking in Git. While it's perfectly acceptable to write programming code in Notepad, there are far better tools out there that will help us out.

My preferred IDE is Visual Studio Code, which is the editor I'll be introducing you to today should you choose to follow along. There are alternatives such as Atom, WebStorm, or even Notepad++. There are even terminal-based IDEs such as Vim or Emacs if that's your cup of tea. When I first started JavaScript development I really loved WebStorm. Eventually I decided to embrace my inner geek and dive into Vim. I fell in love with Vim for a long time but configuring it was a pain so I kept my eyes open for anything new. Microsoft released VSCode and after trying it in conjunction with their Vim plugin I realized I could have the best of both worlds; a modern IDE that is easy to configure, and all the macro and hotkey control of Vim. Haven't really looked back since.

To get started, make sure you download and install Visual Studio Code. Once installed you can run it for the first time and you should be presented with a window like the one below.

I have recently opened projects, but if this is your first time using VSCode you won't see any recent projects.
Note: You may have heard of "Visual Studio" before. That is the name of Microsoft's primary IDE used to develop .NET applications in C#, Visual Basic, etc. Do not confuse "Visual Studio" with "Visual Studio Code". They are two completely different applications. In traditional Microsoft style they chose a very confusing and ambiguous name for their new IDE. I don't know why they chose to do it that way but it is what it is. VSCode is a separate prgoram and does not replace Visual Studio.

Some argue that VSCode is not strictly an IDE out of the box. Like Atom, the real power comes in when you install extensions from the rich extension marketplace. I don't necessarily agree that VSCode isn't an IDE out of the box. My reasoning is that right off the bat we have source control integration and a built-in debugger without installing any extra extensions. Technically VSCode's default features are just a set of default extensions that come pre-installed, so really there's no right answer either way.

We'll be diving much deeper into VSCode and some extensions as we continue through the rest of our full stack tutorial here on Chevtek, but for this article I'll go ahead and run through some of my favorite extensions later on. For now though, let's go over VSCode's settings and which ones I prefer. To get to VSCode's settings simply click the little cog-wheel button in the bottom left and navigate to "Settings".

You'll be presented with a very easy-to-use settings interface. From here you can search for specific settings or browse by category to see what's available.

There are too many settings for us to cover them all in this post but you are free to spend some time poking around in there and tweaking things to your liking. For this post we'll go over which settings I changed from their default values. VSCode provides us with a very nice view of all the settings I've changed. Simply click the button in the top right with an image of two curly braces.

This will take you to a JSON view of your settings. You don't need to know what JSON is at this point in time, but the quick explanation is that it's a tidy view of the settings we have changed. Any settings that do not appear in this view are still at their default values.

All the VSCode settings that I have modified from their default values.

Let's walk through some of my settings and explain what each of them do.

"debug.console.fontFamily": "Fira Code"
"editor.fontLigatures": true
"editor.fontFamily": "Fira Code"

A while ago I discovered font ligatures. Basically they are fonts that support some cool characters for common programming operations. For example, in JavaScript it is common to type an equals sign (=) followed by a greater than sign (>) to create what's known as an arrow function (=>). With editor.fontLigatures enabled and the Fira Code font installed, VSCode will turn an arrow function into a single character that is much nicer to look at.

Arrow function font ligature.

Yes this is purely aesthetic and completely unnecessary, but I like the way my code looks with it enabled.

Fira Code font with ligature examples.

The next setting I have set is my color theme. There are hundreds of themes on the VSCode Marketplace. I am particulary fond of a theme I used to use in Vim called JellyBeams. I just like it's dark style with somewhat muted text colors. You are perfectly free to explore all the color themes you wish in order to find your own style.


"editor.tabSize: 2" - A lot of people prefer a tab character to take up the equivalent width of 4 space characters. I however like my code to be tighter and not take up extra space if it doesn't need to so I change my default tab size to 2. I should also note that by default when you press the tab key VSCode will insert spaces rather than an actual tab character. You may have heard of the highly debated "tabs vs spaces" topic before. There are pros and cons to both but the programming community has largely settled on spaces. I really don't have a dog in that fight and use whatever the project I'm working in uses.


"editor.renderWhitespace": "boundary" - As a developer it's nice to know when your files have unwanted white space (invisible characters like tabs and spaces). However, I don't want to see the super obvious white space between words. The "boundary" option shows white space at the front and end of a line, which is perfect.


"editor.dragAndDrop": false - You ever highlight text and then accidentally click and drag that text somewhere? It's annoying and I almost never intend to do it on purpose. This disables that.


"editor.smoothScrolling": true,
"editor.cursorBlinking": "phase",
"editor.cursorSmoothCaretAnimation": true

These settings are subtle but make it a lot easier to see what's happening as you type and jump around a file. I especially like these settings when I'm recording video tutorials. I can fly around a file pretty fast sometimes with the Vim extension and instead of instantly teleporting to a spot in the file you see a fast animation of the cursor traveling. It helps maintain visual continuity.


"editor.minimap.renderCharacters": false,
"editor.minimap.showSlider": "always"

The minimap is a high level view of the overall file you're working in. By default it shows tiny renderings of the characters in the file. It's kind of ugly and you can't read them anyway.

Setting editor.minimap.renderCharacters to false replaces the tiny ugly characters with colorized blocks which look much nicer.

Setting editor.minimap.showSlider to true ensures that the highlighted portion of the minimap column is always visible. It highlights the section of the file you are currently viewing in the editor. By default this highlight fades out until you mouse over it, but the whole point of thel minimap column to me is being able to know where I'm at in a file at a glance.


"files.insertFinalNewline": true,
"files.trimFinalNewlines": true,
"files.trimTrailingWhitespace": true

These settings help a lot with file cleanup when saving a file. On save it will trim any trailing white space from any lines that have any. It will also add one final newline to the file which is a pretty standard thing to do. In addition it will trim any newlines beyond the one final newline so there aren't extra. These settings just help avoid the pain of having random trailing invisible characters and lines that you don't expect.


"workbench.editor.enablePreviewFromQuickOpen": false - By default when you click a file in VSCode it will open in a tab with the title of it italicized. This lets you know that tab is a "preview editor". If you click a different file it will replace that preview tab with the new file instead of opening a second tab. To open a file in a normal editor simply modify it or double-click the tab title. The italics will go away and the editor will no longer be in preview mode.

Italicized title signifies that tab is a "preview editor"
Preview tab is re-used for the next file.

This is great when you're clicking through files in the explorer sidebar in order to find something specific without opening 500 tabs. However, it's not so great when you want to open a file via the quick open feature using ctrl + P. workbench.editor.enablePreviewFromQuickOpen ensures that files opened via ctrl + P are opened in regular tabs that won't be replaced. If I'm opening a file via quick open then it's rare I'm just peeking inside it.

Using ctrl + P to quickly open a file in a non-preview editor.

Those are all the most noteworthy settings I have. The rest are either extension-specific, not worth mentioning, or something slightly more advanced that we'll go over in later parts of our full stack tutorial.

The next thing we can look at are some of my favorite extensions. Here they are in a list:

  • Vim - This is my absolute favorite. If this didn't exist then I probably wouldn't be using VSCode. It's not for everyone though. It definitely takes time and patience for it to be a producivity booster.
  • Jellybeams Theme - My favorite color theme. I found it back when I was using Vim and was happy to see a well done version of it on the VSCode marketplace.
  • code-eol (line endings) - There is no built-in setting in VSCode to see line-ending characters in a file. If you work on multiple operating systems then it's important to know if you're accidentally changing the standard line-ending format unintentionally. This extension will show the line endings for you.
You can see this file has LF (¬) line-endings.
You can see this file has CRLF (¤¬) line-endings.
  • Settings Sync - This extension is great if you work on multiple computers. It synchronizes your settings and extensions with a Gist which is a simple service provided by Github for creating and sharing small notes, but with the benefit of a version history.
  • Live Share - This extension is amazing. It basically turns VSCode into Google Docs where multiple people can work on the same files at the same time. One person can host a session and then others can join. Each client will get a different color cursor and can modify the document live. Great for pair programming and debugging sessions. Speaking of debugging, the extension even synchronizes active debugging sessions letting everyone step through the code together! It even synchronizes open terminal windows on the host so clients can see them; the host can also set shared terminals to be writable so that clients can issue commands. Not only that but it has built-in audio and text chat should you need it.

There's not too much else to cover at this stage. You are encouraged to dive into the settings periodically. As you get used to using your favorite IDE getting to know all it's capable of becomes increasingly helpful. I will definitely be drawing attention to more settings and extensions as we continue forward with the tutorial series.