Introduction

My last post triggered quite a few questions. I had no idea so many people read my blog. The emails mostly asked "Why Node?" or "What's good about Node?".

In my previous blog I expressed my frustration learning Node and how I overcame my issues. Perhaps it's time to explain why I'm using Node even when I had every possible option of technologies for the project I just started. So… here I'll try to explain why I use Node and what I like about Node.

NOT an advantage: Wide Recruiting Base

Before I start, I'll make address what I think is a common misconception. I've seen this argument made in multiple places and I could not disagree with it more. The argument for node goes something like this:
Node is great because we can use JavaScript. JavaScript is an easy language that is widely spread and recruiting will become much easier.
If this is your reason to go to Node, I suggest you don't! 

 Here is my opinion. If you are going to transition your organization to Node, you probably need better programmers than you currently have. It is correct that you can find lots of resumes with JavaScript on them, but making a widget pop-up with JavaScript, validating fields in a form, that is the typical tasks of a client-side JavaScript programmer is quite different from maintaining a set of complex backend services.

If you are planning to use Node to build backend services, get the best programmers you can find. For large scale project, Node (and JavaScript) requires more professional engineering discipline. The freedom of Node/JavaScript invites clever and brilliant solutions, but at the same time opens up Pandora's Box for the worst possible engineering practices. Believe me, I've seen them...
If I were interviewing someone to work on my Node server, I would ensure that:
  1. They have a solid Computer Science background
  2. They fully understand the asynchronous model
  3. They are fluent in Test-Driven-Development and embrace it
It may seem a bit strange to start arguments for Node by trying to kill one of the most commonly suggested advantages, but I wanted to address it so that I don't get a ton of other emails wondering why I don't list 'Easy to Program' as an advantage. Bottom line, if you are one of those companies that hire a ton of average programmers and have found that it is easier to find cheap JavaScript programmers… Node is not your answer! I seriously believe that you will be worse off with  Node than Java. Java and other strongly typed languages prevents a lot of errors that now are very commonin JavaScript.

Advantage 1: Code easily be migrated to and from the browser/server

Apart from using the Google Web Toolkit, there is really no way you can avoid JavaScript in a modern web application (and even if you use GWT, you most often end up doing a fair amount of JavaScript). If you have adapted the Web 2.0 paradigm, you would want to distribute some of the computing to the client side.

Using Node, the algorithms and data structures that you build can in theory run both on the client and on the server. With a bit of cleverness (remember, the best programmers) you can make modules context free and play around with where they run.

Using this advantage I can easily optimize performance by taking advantage of all the browsers accessing my application and fine-tune it as I go. This often significantly outweighs the performance disadvantage running my server algorithms through an interpreter.

Advantage 2: Consistently asynchronous

Everything is Node is asynchronous. This is quite powerful as it allows a single incoming request to (conceptually) fork off a set of threads at the same time. In most other environments you program every incoming request serially. This is a performance issue in many cases where the one may easily parallelize the algorithms. Since JavaScript has closures as first-class-citizens of the language, programming asynchronously is straight forward.

I have to say that most node applications, when complex, can be rather cumbersome to read because all of its nested functions, but I found the async.js library to pretty much eliminate this issue (this library is well worth a few hours of study).  With async, the parallelism is clear to see and the code reads like prose...

Advantage 3: It breaks down the boundaries between front- and back-end development

Because both the client-side and server-side development is using the same language, we don't have to separate the front-end developers and back-end developers. This means that a developer (or two developers if you use pair-programming) can work on a feature from start-to-end. This eliminates the waiting for front/back-end to finish. This is of course because we have no impedance mismatch between the two environments (you may still have some that prefer to work on U/I's and there is of course some advantage to have experts here… You still have to deal with browser idiosyncrasies, CSS, HTML, etc., but the boundary can be quite fluid).

This simplifies project management and helps spread knowledge.

Advantage 4: [Context specific] JavaScript is a dynamic language

For many problems, the ability to load code and execute it dynamically can significantly simplify the design. You can store code/functions as first-class objects and execute them upon need. You may even have customer produce JavaScript to be executed by your engine (this of course opens up security holes, but the option is there).

A few things I used to fear, but no longer do

Java has a tremendous number of open source components that you can learn download, learn and integrate. Node.js is rather fresh, so there are not that many components out there. Node is a newcomer and it doesn't have nearly as many battle tested components. This is of course an issue, but I've stop fearing it. It seems the Node community is very vibrant and productive. You can almost always find a suitable component for whatever domain independent problem that these open source components typically solve.

I had little hope that Node would be able to handle cross-open-source-dependencies (Maven does an excellent job of this for Java). However, it seems to me that the package manager of Node (npm) is almost as good (and sometimes better).

Conclusion

In this blog-post I've outlined the advantages that may make me select Node.js as my server environment (I would not always use it). I've also tried to debunk one of the commonly listed advantage, namely that you can get away with inferior engineers when working with Node.
Posted by
4

View comments

Today, I want to introduce the word 'dugnad' (pronounced ˈdʉːgnɑd]) to my friends and colleagues.  

Dugnad is a word from Old Norse and it is wrongly translated as 'volunteer work' in the English dictionary. Dugnad has a much richer meaning and tradition in Norway. Dugnad is when a community comes together to fix a problem in their community. 

When I lived in Norway, it was usually used to describe a common effort like cleaning up a common area in your neighborhood or perhaps your sports club comes together to improve the sports facility.

The word, dugnad, is now used in Norway to talk about the shared effort required to fight the coronavirus.
1

Introduction

I just upgraded to a new Dell Precision Ubuntu-Based laptop from years of using a MacBook. Although for the mosts part, the transition was smooth, one thing frustrated me beyond anything else. The trackpad on the Dell is placed in a location where I constantly touch the trackpad causing my typing to insert in random locations as the mouse is moved.

This blog explains how I solved it.

Disable the trackpad

You can disable the trackpad in Ubuntu using the command xinput.

Introduction

How do you translate traditional API’s into REST? Many applications face this problem. We may already have an implementation that exposes a typical functional API. In the previous post, I discussed some of the essential properties of a REST API. In this post, I’ll take a simple functional API and convert it to REST resources.

A Simple Address Book

Let’s use a simple example of an address book.
1

Introduction

This is the first blog in a series of blogs on REST. In these blogs I’ll try to demystify the REST. I’ll discuss what REST is and some suggestions for how you can design good REST APIs.

First, let me acknowledge some of the sources of these posts. I’ve been teaching REST API’s for one of my favorite clients PayPal over the last year. In the process I’ve had the fortune of working with the PayPal services team.
2

Introduction

Waterfall, agile, iterative, whatever your process, your chance of success can be measured by the number solid feedback loops between the developers and the domain experts.

In this article I’ll try to argue that no matter your process, you have to find ways to insert frequent checkpoints. I’ll argue that agile development makes this easier, but I’ll also give you an insight into how we do this at SciSpike.

Introduction

Over the last 10 years I’ve seen a change in the way the top engineers/architects design, architect and deploy software. This new generation of computer scientists have their eyes firmly focused on quality attributes such as availability, scalability and fail-over-capabilities; issues that are rarely discussed in most enterprises.

Introduction

Over the last few years I've been experiencing conflicts between pure agile development and the need for budgeting. At SciSpike we do everything agile and it works for us. We have a good idea of the velocity of our teams and can often be very accurate in our estimates.

Often, when working on client projects, we don't have metrics or heuristics that we can use to help us with the estimation.

In my previous blog post I praised the open-source database Orient DB. I’ve received many email from people since asking me questions about Orient DB or telling me that they’d love to try Orient DB out but don’t know where to start.

I though it is time for me to contribute to the Orient DB community and write a short tutorial for exactly this audience.
9

Every now and then you come across open source projects that just amazes you. OrientDB is one of these projects.

I’ve always assumed that I’d have to use a polyglot persistence model in complex applications. I’d use a graph database if I want to traverse the information, I’d use a document database when I want schema less complex structures, and the list goes on.

OrientDB seems to have it all though.
6

Introduction

In preparation for a course I'm teaching over the next couple of weeks on OO and Scrum, I spent the weekend reading up on the new books on Agile and Scrum to see if there are points that I need to add to my courses.

During my preparation I read a few books and papers discussing distributed Scrum. They contained good tips, but I felt they missed a few important points. My company partake in quite a few distributed projects, so I though I'd share some of our key lessons.
About Me
About Me
Blog Archive
Blog Archive
Subscribe
Subscribe
Links
Links
Subscribe
Subscribe
Loading