In the previous blog post, I provided a general overview of some the key differences between the two frameworks. With this out of the way we’re ready to get started writing an application. However, there are some key decisions to make regarding what development tools to use as well as getting the execution environment set up.
Selecting an IDE/Text Editor
Before I could write a line of code, I needed to decide on an IDE/Text Editor that I wanted to use to write my application. As a C# developer, I was spoiled with the number of features that Visual Studio offered a developer that allowed for a frictionless and productive developing experience. I wanted to have this same experience when writing a Node application so before deciding on an IDE, I had a few prerequisites:
- Debugging capabilities built into the IDE
- Unobtrusive and generally correct autocomplete
- File navigation via symbols (CTRL + click in Visual Studio with Resharper extension)
- Refactoring utilities that I could trust; Find/Replace wasn’t good enough
While I love Visual Studio, I find that its JavaScript editor is more annoying than helpful. Its autocomplete often gets in the way of my typing and it will automatically capitalize my symbols without my prompting. Add to the fact that since I was working with a new framework and was already spreading my wings, I wanted to expose myself to another tool for learning’s sake.
Given my preferences above, I decided that JetBrain’s Webstorm would fit my needs:
- Webstorm offers a Node debugging experience that rivals VS’s. One can set breakpoints, view locals and evaluate code when a breakpoint is hit.
- The IDE’s autocomplete features (although not perfect) offer not only the correct symbols I’m targeting but often times would describe the signature of the function I was intending to call.
- By indexing your project files on application start, Webstorm allows for symbol navigation via CTRL + click. I was even able to navigate into node_modules files.
- When refactoring code, Webstorm will search filenames, symbols and text comments, providing a safe way of refactoring code without (too many) headaches.
While not at the same level as Visual Studio’s C# development experience, Webstorm offers the user the next best thing, allowing for an environment that offers a familiar developer experience. Although there are other (free) options available (Sublime Text, Atom, Visual Studio Code) I found that with these editors, I had to do more work to set up an environment that would allow me to develop at a productive pace.
Embracing the Command Line
Due to the power of Visual Studio as a tool and its ability to abstract away mundane operations, your average .NET developer tends to be a little wary of using the command line to perform common tasks. Actions such as installing dependencies, running build commands and generating project templates are handled quite well in Visual Studio through wizards and search GUIs, preventing the user from having to know a myriad of tool-specific commands.
This is not the case when working with the Node ecosystem and its contemporary toolset. Need to install a dependency via npm? A quick `npm i -S my-dependency` is required. Want to run a yeoman generator to scaffold out an express application? You only need to download the generator (if you don’t have it) using the same npm tool, run the generator with `yo my-awesome-generator` and walk through the prompts. How about a build command? Assuming you have an npm script set-up, typing `npm run build:prod` will do, (even though this is just an alias for another command line command that you will have to write). In Node development, working with that spooky prompt is unavoidable.
While it might feel tedious and a step backwards as a developer, using the command line as a development tool has many benefits. You generally see the actions that a command line command is performing which gives you better insight into what is actually happening when you run `npm run build:prod`. By using various tools via the command line, you have a better grasp of which tool is meant for what purpose. This is in comparison to Visual Studio where at first blush, one equates Nuget, compiling via the F5 key and Project Templates to Visual Studio as a whole, not grasping that each of the commands you perform are separate toolsets and dependencies that Visual Studio invokes. Having better insight into your toolchain can help in troubleshooting when a problem arises.
Running Your Code
The final step in writing a Node application is preparing your environment to run your Node code. The only thing you will need to run your application is the Node runtime and the Node Package Manager (included in the same download and installed alongside Node).
Node.exe is the actual executable that will run your Node application. Since Javascript is an interpreted language, the code you write is passed to this executable which parses and runs your application. There is no explicit compilation step that a user must perform prior to running a Node application. Furthermore, unlike applications written in a .NET language, Node programs are not dependent on a system-wide framework to be present. The only requirement for your code to run is to have the node.exe on the system path. This results in the deployment story of a Node application to be simpler and allows for cross platform deployment that is not yet readily available to .NET applications.
The neat thing about Node is that if you type in the `node` command without any file parameters, you get access to the Node REPL right in your console. While this is great for experimentation or running/testing scripts, it’s a little lacking and I’ve only used it for simple operations and language feature tests.
While node.exe is what runs your application, npm is what will drive your application’s development. Although the “pm” might stand for Package Manager to pull in your project dependencies, it’s more of a do-all utility that can run predefined scripts, specify project dependencies and provide a manifest file for your project if you publish it as an npm module.
Summary
Oftentimes with new frameworks and technologies, I have experienced frustration in getting my environment set up so that I could write code that runs at the click of a button. However with Node, the process is very straightforward, simply requiring one to install the runtime and package manager which are both available as an MSI that can be found on Node’s website. From there, you can run your Node program by accessing the command line and pointing to your entry file. In all honesty, the hardest part was deciding on an IDE that offered some of the features I became accustomed to when working in Visual Studio.
In the next and final post in this series, I will provide my overall experience with writing a Node application, detailing some questions I had surrounding application structure and testing, as well as giving a summary on my feelings on the runtime.
Super Development 
Leave a Comment