I recently posted about my experiences developing Node.js apps with Node Tools for Visual Studio: the good and the painful, and why I decided to try something else. I kept hearing good things about Sublime Text over the years, so I thought this would be a good opportunity to try developing with just a good text editor and an ecosystem of command-line tools. Over the course of the first few days, I organically added plugins and utilities as needed to make my development life as comfortable as I could. This is the setup I ended up with:
Editor and plugins
As foreshadowed by the title of this post, I chose Sublime Text 3 as my editor, having heard positive things about it over the years but never really having had much reason to use it very heavily since the vast majority of my text-editing tended to be either C# (for which I used Visual Studio) and T-SQL (for which I used either Management Studio or LinqPad). Out of the box, the “navigate to anything” functionality worked great and symbol-based navigation and autocomplete worked pretty well, too. The biggest thing I felt I was missing was JS hinting/linting, so I installed JSHint for Sublime and configured it. It works almost exactly as one might expect, although I felt it was a bit awkward to have the warnings and errors appear in the command palette instead of in a tool window, but that’s just how ST3 works. I kind of missed Intellisense and tinkered with Tern for Sublime, a plugin that is supposed to integrate TernJS into ST3, but it didn’t provide sufficiently complete information and definitely caused the UI thread to hang occasionally, so I gave up on it. For Git, I’ve always felt that the command line is the best interface, so I just used Posh-Git. The command line interface for NPM is super simple, so that was an easy transition as well.
Running and debugging
You might be wondering how one would debug code without the benefit of an IDE like Visual Studio. I have good news, because there are many options available that will not leave you resorting to the “stone knives and bearskins” of printing debug information to the console. I settled on a pair of NPM modules: node-inspector and nodemon. With node-inspector installed globally, you can simply start a Node.js process with the –debug option, then run node-inspector, which attaches to the Node.js debug process and itself starts a web server which you open in Chrome. At this point, you can debug your Node.js app using the Chrome debugger, which as you’re probably already aware, is a very capable debugger. As a side note, I just recently learned about the existence of ironNode, an Electron-based debugger for Node.js. If I returned to this configuration, I would probably give that a whirl.
The good and the painful
Overall, this was a pretty good setup. I felt happier with this configuration than I did with NTVS. I had lost Intellisense and Azure integration, but found equally capable replacements for everything else. I also gained a much snappier editing experience along with a debugging session that would automatically refresh every time I saved changes in my project, and I shed the awkward “build” process and poor ES6 support in Visual Studio. I was content and probably would have stuck with this setup, but then I had to open my big mouth and mention this setup to a fellow developer, who responded with something along the lines of, “Sublime Text is so 2012. Atom is the new hotness.” I’d heard of Atom, but had originally opted for Sublime Text because of the often-cited speed advantage, but those words haunted me. I resolved to compare Atom to my Sublime Text setup to see if it was worth switching. I’ll describe what I found in my next post.
Latest posts by Falafel Posts (see all)
- Matching Complex Query String Rewrite Rule in IIS - March 22, 2017
- Using Google Services in UWP C# Apps – Part 2 - February 7, 2017
- Using Google Services in UWP C# Apps – Part 1 - February 6, 2017
- Redis Caching in the Google Cloud Platform - February 3, 2017
- Entity Framework with Google Cloud SQL - February 2, 2017