I’ve never been much of an “interpreted” languages guy. I’ve grown up with C, C++ and Objective-C, OpenGL, GTK, Qt and Cocoa, and have always fancied performance over simplicity, compilers and linkers over interpreters, even though I must admit that one can see a certain beauty in low level languages, I still remember that I use to read the Free BSD kernel source code on the bench of my university.
With such achievements as Electron, Atom and especially Node.js
together with its huge package system,
npm, I’ve come to reconsider
especially when it involves a hybrid infrastructure (such as web
services or so).
So I gave Node.js a sceptical look, with its shy 37 classes (as of v6.3.1), I’ve counted them all ;–)
At first look, it reminded me of the C/C++ wrappers I used to generate
for my own C++ frameworks using the excellent SWIG, but with an intent
over the operating system primitives, with classes such as
ZLIB and so on. So far so good.
Also, it has a serious concern on the web, with its
Net classes. The “Hello World” example is, by the way, a web server
implemented in no more than a few lines. At this point, I remembered
the burden of installing the right ruby version in order
to get the right RubyOnRails version that fits the dependencies
needed. As an example, thanks to
rbenv, I have many ruby
installations: one for my Octopress instance, another one, up to date,
for my various packaging scripts. If Gemfile(s) exist, they do not
prevent you from installing many versions of ruby.
Once the “Hello World” example run, after a
brew install node (which
npm), I focused on my current problem, which was first: RPC
calls, then: a web front end to display current calculations and
results. So I dug up the plethora of packages available and choosed
the one I preferred (for the mention, the one that inherits from the
“native” http server implementation, as to know: jayson).
After 30 minutes of googling and reading, I had an RPC mechanism that
worked, using two procedures, namely an addition and a subtraction, as
a proof of concept for more complex implementations, comforted by the
fact, that using Node.js, I have a
Process class (as well as
Stream ones) that can make benefit of different binaries.
When starting a project using Node.js, it is recommanded to start with the following command:
This command prompts for some values and generate a file called
packages.json that contains many information on your project but
also its eventual dependencies. Here is mine.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Many additional fields can exist, refer to the documentation for their
description. What is relevent so far is the fact that my packages
files sates that my project depends on
(which stands for embeddedjs). So the next step is to install these
dependencies that will end up in a directory at the root of your
node_modules (I’ve tried to change its name and
location but it is explicitly stated in the documentation that it is
strongly advised not to do so).
As this point,
npm start will start to interpret
server/index.js. As my full project hierarchy is as follows.
1 2 3 4 5 6 7 8 9 10 11 12 13
So let’s start at looking the client side. In its minimum state it
consists in setting up
jayson as to connect to a host, and to
perform to minimal RPC calls, with a callback that prints out the
result of the call.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39
Readline class that comes with Node.js, we can quickly
implement a very minimalistic console interface that prompts for
operations to be remotly performed.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
So simple. Little is beautiful. Let’s have a look at the server side, which is divided in two parts: an http server running on the port 3000, and a JSON-RPC server running on the port 3001.
Let’s start with the JSON-RPC side which is the simplest one, and very intuitive.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37
In the above snippet, we simply create a server that contains two
sub, that operate on the simplest model
The latest step is to implement a RESTful server which allows you to define routes and layouts to be rendered, just as RubyOnRails does, but in a minimal amount of code.
For this, I have chosen
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
The code is self-explanatory. We setup a router that gets “/” to serve the index.html page (that is the expressjs part), using “ejs” as an view engine (that is the embeddedjs part), and everything else as a 404.html page.
1 2 3 4 5 6 7 8 9 10 11 12
This is a simple as that! Note the use of the
<% include ... %>
directives that allows for partials, other parts of the html document
that are repeated for multiple files (namely index and 404 in our
For the sake of completeness, here is the header.ejs, where we retrieve bootstrap by the help of a Content Delivert Network (CDN), and the footer.ejs that finalizes the HTML page.
1 2 3 4 5
As a conclusion, I am very enthusiast, and very much impressed by the ease of use of Node.js and its packages. I look forward giving Electron a shot and blog about it a little more.