First Impressions: Node.js
In this article I wanted to share my initial impressions working with Node.js coming from a .NET developer.
Node.js has become one of the most popular technology for tech companies to develop their services in. This past weekend I decided to explore what makes it so appealing and how it is to work with compared to my experiences working as a .NET developer these past few years. I have some experience working with front end frameworks such as Angular (JS, 2+), so JavaScript isn’t new to me, but developing backend services will be a new experience. I decided to go with the pure JavaScript for this exploration so I can get the full experience of what most node developers work in.
My sample project would have a simple goal, to build a RESTful service using Node.JS that can connect to a MongoDB database and return the results as a service should. This seems like an typical type of service in a micro-service architecture.
Here are my thoughts:
Meh : Strongly-typed vs. Weakly-typed (for backend)
Not surprising was that my weirdest experience was to code in a weakly-typed system. While I’m not a stranger to this type of development, having experience developing in JavaScript in AngularJS, this seemed a lot different because I didn’t have the opinionated design that AngularJS had. Developing in node felt like I was in the wild-west, where I had to understand how each library treated JavaScript. Not having the code complete to experiment and explore the objects made discovery a lot harder to figure out what I needed to do. Although in some cases the package provided TypeScript definitions which VS Code was able to pick up and apply to regular JavaScript files automatically.
Good: Blazing Fast Development
What I found amazing writing code in node was just how blazing fast developing was. Without the code constraints of defining models, or type information, or bulky application configuration such as dependency injection, I was able to build full functioning features very quickly. What amounted from less than 100 lines could build you a REST API. The code was easy to follow, as there was no IoC pattern to obfuscate the code. I understand that as applications become bigger, maintenance will be harder to manage, but it is refreshing with how little code you actually really need to write to actually do something.
Meh: Modules
I was pretty stumped when it came to figuring how to properly use and import modules. In C# every code file consists of a class which you can use to encapsulate an object or static methods. To import you would just reference that class and it’s properties and functions. In JavaScript, functions are treated as first class objects. A common case is the thing you import into your class is actually just a function. This creates further ambiguity as to how you should be writing your modules, should you be returning some object, or a function that creates an object, or something else.
Meh: Require() vs. Import
In regards to how to actually including modules that I built, I ran into the issue of what method I should use for importing them. Require (Great medium article) is the “node” way of including modules into your code. It would look something like this var express = require('express');. Import is a ES6 standard that is currently marked as experimental by Node.js at the moment. Including a module would look something like this import express from 'express'; What I found out the hard was is that Node.js doesn’t support import out of the box, and you either need to enable the experimental flag on build or to use a transpiler like Babel or Webpack to make it readable by Node.js.
Good: Amazing Library Support
I will say that NPM is an amazing tool, and that JavaScript has a vibrant open source ecosystem. As I explored various example projects and templates, I noticed just how many useful libraries were created and actively maintained by the community. Many of these libraries had pretty comprehensive documentation, which is probably in part of the constant developer input.
Meh: Library Choice Overload
Just looking to find a RESTful API framework resulted in 10+ frameworks to choose from. Back in C# you’ve pretty much for WebAPI and that’s about it. Having choice is a double-edged sword, where you have the ability to pick the greatest design fit if you know what you’re looking for, or you could experience choice overload where I found myself trying to weigh which framework to go off of with little or no actual impact on what I was actually trying to do.
Meh: Out-of-Date Examples
As I tried to figure out how some of these libraries work, I tried to browse for examples only to constantly find really out-dated code snippets. Trying to emulate these solutions without type assistance had me scratching my head what was going on when things didn’t work and my code was broken. Only until I looked at the date did I realize snippet was from 5 years ago, and the API for the library had drastically changed since then. People are right when they say that JavaScript libraries change like the seasons, and takes a bit of effort to learn these libraries if documentation is not kept up-to-date.
Final Thoughts
I would say that working in Node.js had it’s pleasant surprises as well as surprising issues. It offers a blazing fast development experiences that I can see for micro-service architectures where code is much simpler due to the architecture taking up the complexity, as well as POC projects that need quick and simple implementations. I plan on revisiting Node.js sometime to incorporate TypeScript to see just how much adding types may affect my development experiences — will adding types really slow down development that much, or is Node.js that much more streamlined. Node.js has a great future ahead of itself and I would love to see how it advances in the future.
