In theory you need nothing more than TextEdit (or Notepad) for programming. In practice, you need some help – at least syntax coloration and indentation. That is, you need a code editor.
Early on in my web development life I tried a couple of full-fledged IDEs – NetBeans and Eclipse – and later on did a little with IntelliJ, but IDEs have always seemed excessive for my needs, and hence cumbersome. My previous home laptop couldn’t really hack the system requirements to run them smoothly, either. Since then, I’ve used three code editors enough to have something to say about them: GitHub’s Atom, Adobe’s Brackets, and Visual Studio Code.
I settled on Brackets maybe as much as two years ago, because of the implicit recommendation of one (or maybe more) of the developer bloggers I follow. It has worked really well for my home development, but its limitations became an issue at work. At that point I put out my personal ad: FWD ISO PCE.1
Commence web searches. After a few weeks using Atom I found Code, and there I expect I will stay. The features I miss from Atom and Brackets (one from each) are both in the active open issue list for Code, so while right now it’s a compromise, I have hope it won’t always be.
What follows is my perspective on the good and the bad aspects of each of these tools. All three editors have syntax coloring, code folding, matching bracket highlighting, multiple panes in the editor, multiple cursors, the ability to enclose text in brackets or quotes by highlighting it and typing the opening half, the ability to open individual files that aren’t in the project folder, a lively ecosystem of extensions to customize them for your needs, and potentially useful, potentially irritating autocomplete.
Brackets:
git pros and cons: No direct integration. Asks you with a popup what you want to do with files that are open in the editor but changed on disk because of switching branches or pulling a commit.
brackets and quotes: Circumstantial – for example, automatically closes HTML tags and brackets in HTML files, but not quotation marks. Closes brackets and quotation marks both in JavaScript files. Can be limited or disabled in preferences.
other pros: Best of the lot for find and replace, including multi-file, multi-line regex find and replace. The only one that does that right! Pops up a preview of images when the src attribute is hovered over (provided the link is absolute or has a path relative to the current project folder).
other cons: Only one window permitted, and one open folder per window. Code folding can be a little buggy. Its death knell: regularly blacks out to the point of needing force quit when minified JS files are in the project folder or open in the editor.
features I never used: Inline editor (e.g. edit CSS for a class from within the HTML file), live preview.
Atom:
git pros and cons: Highlights files that need git commitment in the sidebar. Makes phantom changes to files that cause your commits to be a few real changes lost in a sea of faux changes (blank line replaced by blank line… what, Atom?). Changing git branches while files are open does not work how I would expect – the open version is prioritized, whereas I would want it to close if the file doesn’t exist in the destination branch and change if it does but is different. Or at least ask. The git problems were Atom’s death knell.
brackets and quotes: Always closes these, but not HTML tags.
other pros: Allows multiple windows and multiple folders open within a window, the latter being a feature I was completely spoiled by after using Atom only for a couple of weeks.
other cons: Awkward, user-unfriendly find and replace – I never did see a way to selectively replace out of a batch of finds other than doing them one at a time.
features I never used: Code snippets.
Visual Studio Code:
git pros and cons: Excellent understanding of git; behaves the way I would expect when changing branches. Allows you to do most git operations within the editor (commit, push, pull, create and switch branches) – really only need to go outside it to merge. Gives you a separate sidebar where you can see all the files in need of commitment, view the changes from the previously-committed version, stage them and write your commit message.
brackets and quotes: Almost always closes these – except for brackets within quotation marks (single quotes inside double quotes, for example, are still automatically closed). Does not close HTML tags. Can disable automatic closing in preferences.
other pros: Multiple sidebars for file tree, git work, extensions, search, and debugging. Multiple windows allowed. A dev I know says Code has the best multiple cursor implementation of any editor he’s tried.
other cons: Multi-line, multi-file search and replace really doesn’t work at all. Can only have one folder open per window. [But both of these have active open issues on the GitHub repo.] Sometimes difficult to get focus into the editing window and out of the sidebar.
features I never used: Integrated debugger.
1 front-end web developer in search of perfect code editor.