Nodejitsu

Save time managing and deploying your node.js app. Code faster with jitsu and npm

IBM doesn't care about node.js people

About the author

Name
Location
Worldwide
nodejitsu nodejitsu

I've been working with and contributing to the node.js community since 2009. I've authored a lot of modules, I've help recruit a lot of good people into the community, and I'm fortunate enough to have regular communication with all the core members. I remember when node's FS module required three nested asynchronous calls with insane arguments to actually read or write a file. I remember having to beg people like Ry, Isaacs, Polotek, Mikeal, binary42, inimino, Jan, and Tim Caswell ( to name a few ) to teach me the basics. I remember when node was an obscure project with little support or documentation. Since my first days in 2009 I've done everything I can to help promote and improve the usage of node.js.

For all of these reasons I list above, I become considerably disappointed when I see an article like this appear on IBM Developer Networks. I can understand that node.js is still a relatively new technology ( it's not even v1.0.0 as per SemVer yet ), but that is no excuse for an industry leader like IBM to allow such a blatantly misleading article to appear on their site. It's not my intention to single anyone out, but it's apparent that the author of the article has a limited understanding of node.js, has performed a trivial amount of research, and most importantly has no understanding of how open-source projects work in the age of Github.

Normally if I encounted such an unresearched and misleading article on the internet I'd just ignore it. Unfortunately, I can't ignore this. IBM is a serious name that people trust. To have an article on IBM.com spreading misinformation about node.js is wrong. IBM needs to update or remove this article. In this blog post I will distill and address the main points which are "wrong" in IBM's article


Not understanding open-source in the age of Github

A major recurring theme I noticed in the article was a complete lack of mentioning any node.js module authors, any github repos, or anything about npm and the npm module repository. node.js was built on Github. It is one of the first major open-source projects to begin it's lifecycle on Github. Anyone who has committed to node.js or created a node.js module uses Github. There are numerous listings and rankings of node.js module authors and node.js Github members. There is a vibrant IRC room ( #node.js on irc.freenode.net ) with 600+ active members. There is a mailing list with 100s of messages per day. I follow 500+ node.js developers on my Github activity stream. There is an incredible amount of project activity based around Github.



Incorrect / Confusing Terminology

Early in the article I found this line explaining how node.js works internally:

"...node solves the problem by changing how a connection is made to the server. Instead of spawning a new OS thread for each connection (and allocating the accompanying memory with it), each connection creates a process, which doesn't require the memory block to go with it."

The ambiguity and glossing over of the word "process" is wrong. This is bad technical writing.

I asked Isaacs ( author of npm ) if he could clearly explain why this is wrong and his response was:

[17:21] <isaacs> Marak: i don't even know where to start

Moving on...

"Yes, node is a server program. However, it is definitely not like Apache or Tomcat. Those servers are stand-alone server products, ready to install and deploy applications instantly. You could be up and running with a server in a minute with these products. node is definitely not this. Apache can add a PHP module to allow developers to create dynamic web pages, and programmers using Tomcat can deploy JSPs to create dynamic web pages. node is definitely not this."

Ahh! This is where I start to lose it. The author doesn't understand that node is much more then just a web-server. The http server in node is a part of ONE module out of twenty-five core modules and currently 2000+ npm modules. The analytics on npm are a bit terrifying. We are seeing ten new packages released per day. Why did you not mention npm at all?



At the risk of having a stroke, I continue reading...

"At this early point in node's life (currently on version 0.4.6), it is not a ready-to-run server program, where you can expect to install it, drop your files into it, and have a fully functioning web server. It still requires a non-trivial amount of work to get even the basic functionality of a web server up and running after installation is complete."

You can't just drop in pages and starting build node.js web apps in seconds? I disagree with this assertion. I'll explain towards the end of my post, until then let's move on to the next section in the IBM article titled "How node works", first paragraph:

"Server-side JavaScript is a relatively new concept, one which was written about a couple of years ago here on developerWorks when discussing the Aptana Jaxer product (see Resources)."

Umm? Server-side javascript has been around since 1996. WTF does Jaxer have to do with how node.js works?



At this point I start to fear I might have an aneurysm.

Asserting invalid facts as truth

Enough of the nitpicking, let's jump down to the author's conclusion about what node.js is good for and bad for.

What does the author think node is good for?

He asserts node is good for A RESTful API and a Twitter queue. These sound pretty reasonable to me. No objections here.

Then he goes on to state:

"A company that has a large distributed website (think Facebook or Flickr), could decide to devote entire boxes to simply serving up images. node would be a good solution for this problem because the company can use it to code an easy file retriever and then handle tens of thousands of connections. node would look for the image file, return it or a 404 error, and do nothing else. This setup would allow these types of distributed websites to reduce the number of server boxes they need to serve static files such as images, .js files, and .css files."

Hrmmm? Last time I checked binary file support in JavaScript was not that great. I've also heard Ry talk about node's performance in regards to serving static files compared to other well-developed tools as as nginx. The conclusion is you shouldn't use node if all you need is a static file server.

What does the author think node is bad for?

"Dynamically created pages"

"Currently, node doesn't provide a default way to create dynamic pages. For example, when using JavaServer Pages (JSP) technology you can create an index.jsp page that contains loops in JSP snippets like <% for (int i=0; i<20; i++) { } %>. node doesn't enable these types of dynamic HTML-driven pages. Again, node isn't ideally suited to be a web page server, as Apache and Tomcat are. Therefore, if you wanted to provide a server-side solution for this in node, you'd have to code the entire solution yourself. A PHP programmer wouldn't want to program a PHP converter for Apache every time they deployed a web application, but at this point, that's what node would require you to do..."

Do you have any idea how node works? There are literally 20x different node.js templating engines that support pretty much every single style of markup you'd ever want. I understand you really like Apache and Tomcat, but your understanding of node is just WRONG.

"...Therefore, if you wanted to provide a server-side solution for this in node, you'd have to code the entire solution yourself."

Express? Connect? Geddy? webservice.js? I guess these projects haven't been being worked on for over a year. Someone should definitely step up and build a node.js MVC framework, I think there might only be 30x of them available now.



"Relational database heavy applications"

"node is designed to be fast, asynchronous, and non-blocking. Databases don't necessarily share these goals. They are synchronous and blocking, as calls to the database on writes and reads block until a result is generated. So, a web application that requires a lot of database calls, a lot of reads, and a lot of writes with every request would be a bad match for node, since the relational database itself would be negating many of the strengths of node. (The new NoSQL databases are a better match for node, but that's another topic entirely.)"



Don't make broad assertions about node on topics such as "relational database heavy applications". This is highly ambiguous and leads me to believe the author doesn't understand the finer points of application architecture and design. There are several non-blocking implementations of most SQL and NOSQL databases in node.

Why would I ever design an application in node.js that performed "lots" of database I/O on every single request? It sounds like an uninformed opinion based on experiences in a narrow field of software development.


Lack of Research

There is no excuse for this. If you are going to put an article up on IBM.com, you should spend more than an afternoon researching it. I didn't start blogging about node.js until I had already built a project and published it to npm. I didn't dare start blogging about the node.js ecosystem or usage until I had been with the project for almost a year.

It is irresponsible to spread incorrect information like this on such a well respected channel ( IBM developer networks ).


Unfair comparisons to legacy technologies

I feel I've touched on this a few times already, but it should be apparent that the author has a particular bias for his favorite technologies. He compares node.js unfairly to technology which he obviously has a vested stake in. If you want to promote your own technologies, that is fine by me. Just don't spread misinformation about node.js in an effort to make your technology look better.


Conclusion

IBM should pull the article or ask the author to rewrite it. The article is providing a dis-service to any new developers who might stumble along it as their first introduction to node.js.

Artwork courtesey of http://memegenerator.net/