Building web applications: Experimenting with Node.js

I will begin by saying that I am not (yet) a web application expert or programming veteran. I am just someone who enjoys coding and thinking about how things work. My first exposure in creating web applications is with Ruby on Rails back in January 2016. I have used it since then and I built a web application with few other students for a class at Wesleyan University. I decided to experiment Node.js very recently, and I am currently still learning what it has to offer. So, please take this musings with a grain of salt, as it is just my early thoughts about Node.js and reflections of my experience of learning the framework.

Just earlier this week, I started picking up Node.js ( along with the Express.js ( framework. Learning the framework was actually quite enjoyable (as opposed to confusing, which happens a lot when I learned a new language/framework). I realized that it is probably because I already have some experience in JavaScript and Ruby on Rails. It really helps me to grasp the concepts of Node.js fairly quickly.

I have to say, knowing JavaScript fundamentals really helped me in learning Node.js. Unlike my experience in learning Ruby, I do not have to learn a new grammar and syntax in order to start writing code. Objects, functions, arrays , inheritance and even regular expressions work in the way that I am used to. Yet, I have to say working with Node.js is very different from working on JavaScript on the front end. I might be familiar with the core language, but the concepts in which the language is used are different. Granted, concepts like event loops and the way Node runs a single thread of asynchronous calls are no stranger to pretty much anyone who has worked with JavaScript, but the concepts of creating routes, or rendering views are entirely new concepts in JavaScript.

However, that concepts are exactly why having Ruby on Rails (especially Rails) background certainly helps. In learning Rails, I am introduced to the MVC (Model-View-Controller) architechture. When I create a new Rails application, there are lots of files generated, but some of the important ones are the assets/controllers directory, assets/views directory and config/routes.rb. All the Ruby files under the controllers in the controllers directory are responsible for the logic of the applications, the views directory is accountable to how the pages look, and the routes.rb file specify and register all the routes of my applications. Now, for Node.js, when I create a new app using Express, I notice some familiar looking directories, such as routes and views. As expected, the routes directory is where I will register all the routes for the application, and views directory contains all the view templates that needs to be rendered. Express comes with a baked-in template engine called Jade, and that was what I used to write my first few examples in Node.js. As with the controllers, Node.js does not have a separate controllers directory, but since everything is in JavaScript, the logic of each route can be written after the route is declared in the routes directory, which certainly makes sense to me. There are indeed some major differences between the two frameworks, but they are similar enough so that I do not have to learn the whole Node.js from the very beginning.

It is interesting as to how during the learning process, I kept finding myself comparing the things that I do in Node.js with the equivalent commands in Rails. Writing something like,

$ express medium_demo

in the command line for a Node project is like writing,

$ rails new medium_demo

in Ruby on Rails project.

Basically what both line does is calling the Express/Rails framework to generate a directory called medium_demo, that contains all the necessary files for the web applications. It is the first thing you do when you start a Node/Ruby on Rails project.

However, there are also some commands that I wished it was also included in Node/Express framework. Ruby on Rails has this very powerful command called,

$ rake routes

which basically allows me to list all the registered routes that I have in my application, along with the controllers that are associated with it. It is one of my favorite commands when I develop a web application using Rails, since it helps me get back on track if I need a path to a certain page/controller. In Node and Express, I have tried to look for similar commands there weren’t any. I have to either 1. look for another npm package, or 2. declare a JavaScript function that does what I want. I just wished something as important as listing all the registered paths/routes should be built in to the framework.

I could go on with few other examples I learned thus far, but I realized this post is getting long and I’d rather keep this scribble short and sweet.

In a nutshell, I must say I had a great first impression with Node.js and its features. Having the entire stack written in JavaScript means it is an easier learning curve, which is certainly a plus. With that said, the learning curve for someone who started from nothing might be quite steep. Yet, if you have a strong JavaScript background, or other web development framework, the concepts of Node.js should be pretty straightforward to pickup. There are a lot of great things that were said about how well it handles multiple concurrent connection requests and how it can deal with large amounts of I/O. All I can say is that I am excited to give Node.js a shot, hopefully I can build something that I can proudly share by the end of this summer.