Why !(!(node.js))

 

No one in his right mind would kill his main character in the third chapter of his suspense/thriller/drama blog about web apps, so the above title is not a mistake. There certainly is an extra set of parenthesis, but I wanted to add emphasis. In the first post I tried to make my personal case for node.js, and in this one I shall look into some of the most used counterarguments.

JavaScript is slow

Inherently, node.js which is based on it, is slow

 

Well, all web scripting languages are slow. That is because they are interpreted languages. Programs written in these languages need a runtime (runtime interpreter to be precise) to work. And the runtime is just a program that reads your file and tries to interpret the commands. It is usually (read: always) written in some high speed compiled language (think C/C++).
Anyone can create his or hers programming language. All you have to do is invent your own syntax, play around with Lex long enough to implement your commands, and there you have it. Throw Yacc or Bison into the equation and you can build you own compiler. More or less. But that is exactly how, some of the languages we are talking about here, are implemented. There is more theory behind all this than it was presented here, but this is the essence. Maybe that is why we have such a proliferation of scripting languages nowadays. They are not that hard to make. Other languages, like Java and Python, are first “compiled” into bytecode (p-code) and then interpreted at later time. These runtime interpreters are often given very posh names like virtual machine or engine. Which they certainly are not. The name is Interpreter, Runtime Interpreter.

JavaScript has a complicated life story. A love child, shoved from one foster family to another, sometimes changing its name in the process. At the end it was cloned. Many times. Each of the big players in the web browser arena created their own JavaScript engine. Node.js is based on Google's V8 JavaScript engine. Supposedly, this engine compiles the code and than optimizes it before execution. This feature is said to make it faster than the competition. I would know, I never checked. However, the fact that node.js is packaged with certain JavaScript engine gives it more stable performances across different operating systems and development platforms. 

On the other hand, high-level compiled languages like C/C++ never made an inroad into web application programming. I have my own theory on this, but I also have my own theory on who framed Roger Rabbit, so it's not such a big deal. But, this is exactly where node.js kicks in. It can call C/C++ modules and libraries. In addition, you can write node.js extensions in C/C++ (more on this in some future post). This way you can have the best of both worlds, versatility of a popular scripting language and speed and stability of compiled language. This is what you need if you want to engage yourself into writing serious network applications.

Low version number

Therefore, it can't be trusted

 

This was one of the my arguments on my first visit to node.js. I mean, if your Firefox browser is version 24.0 and Chrome reached version 30.+, then something must seriously be wrong with the software whose latest version is 0.10.20! Or not?

Software versioning had its ups and downs, with dBASE II being probably the most (in)famous example. dBASE I never existed, and the name dBASE II was given to the first version of the software by an advertising expert with the idea to suggest the software being more stable and reliable than a first release. But those were the 80's and back then everything was allowed. Later, when some rules were established, version 0.something.something usually meant alpha, beta or some other pre-release stage before version 1.0. Open source changed that. Probably mostly because you are more careful when you are using software with version 0.20.13, then some other that comes with version 20.13. Whether you read the disclaimer or not, and most of us don't. Perhaps open source software developers are more honest or more modest than the enemy. And how Firefox and Chrome managed to have more versions each than “Rocky” and “Rambo” together, is a mystery. Film industry showing self-conscience? Hmmmm. The striking similarity is that both browsers are getting slower with each new version. Just like Rocky Balboa.

As for node.js maturity, my worries were put at ease when I found out that the development started back in 2009 (which hardly makes it a new kid on the block), and that big companies are expressing their support for it. Support (wink). Get it?

Frameworks

There are fewer frameworks for node.js compared to other server-side languages

 

Let us first see what node.js really is. The definition on nodejs.org site starts with: “Node.js is a platform...”. A platform. Not a programming language and not a framework. From a technical point of view, it's an executable written in C++ wrapped in JavaScript. Download the source code and peek into it. You will find C++ code in the src subfolder and JavaScript in the lib subfolder. In the src subfolder you will find node_main.cc file.

As for the “web application framework”, I found it particularly hard to define. At the beginning of XXI century the new computer science intelligentsia has started launching a number of new neologisms that are unintelligible for us with diplomas from the previous millennium. Mostly new names for features that existed since the dawn of programming. If you take a look at Wikipedia you will find three very interesting articles comparison of web application frameworks, list of content management systems and list of content management frameworks. In these, you will see that ASP .NET, for example, is listed as framework and programming language in first, as platform in second and as technology in the third list. As well as Java. At first look it all seemed like apples and oranges to me. After a lot of browsing and more than a few test installations, slowly very slowly, my horizons started to widen. But only to my dismay. I figured out where the categorization confusion comes from. The, so called, web application frameworks are actually applications that either: a) help you click-and-create your own CMS, or b) create framework for you web application. They are usually template driven and customizable. Let's throw in an example. Google Blogger enables you to create a blog. You can choose the template and customize it to the great extent, either via GUI or by directly changing the template code. Once done with that, you can add posts to your heart's content and enjoy the statistics about the number of visitors. Still, Google does not call it “blogging framework”. So, I think that the term “development platform”, which is gaining grounds lately, is more appropriate term for this category of software than “web application framework”. However, to avoid confusion (and too much self-indulgence), I'll use already well established terms throughout this blog.

Web application frameworks are built from the ground up and are mutually incompatible, even those that are written in the same language. It is impossible, for example, to combine Joomla and Drupal in one project. And, it's not meant to be. Both are standalone projects that don't share libraries, templates settings or anything else. As none of the other frameworks do. My guess is that this is probably more driven by commercial reasons, rather than development requirements.

On the other hand, node.js is more of Apache or IIS than PHP, Python or Ruby. Consequently, it extends via modules not frameworks. These modules are libraries written in JavaScript and they add functionality. The good thing about this concept is that you can combine modules in your project. Even better is that there is one stop shop for node.js modules and that is npm (Node Packaged Modules). All the node modules are listed here. Very interested category is “Most Depended Upon” which tells you how many other modules are depending on the listed one. If you click on any entry in this category you will see all the modules that are depending on that particular one. As you can see, the module sharing is in full swing. There are a few types of modules for node.js. Ones, like one of the most popular express.js, help organize your application on a higher level. Others, like Derby.js, use templates to create application framework (skeleton) for you. For more, visit npm site, explore and see for yourself if node.js has enough frameworks or not.

Hosting

Not enough support among web hosting providers

 

Node is still not widely (wildly?) accepted among hosting providers. Platforms of choice are usually LAMP or LAPP in the Linux world and IIS with ASP and ASP .NET combined with Access or MS SQL in the MS Windows environment. With the addition of a number of frameworks to facilitate web development. Of course, no one is going to object if you hire a server and install node.js yourself. But that is not what we are talking about here. Providers that offer out of the box node.js support are still relatively scarce. A rather comprehensive list could be found on GitHub. There are some more that did not make it to this list, and all that shows increasing interest in node.js. Interestingly enough, some of the providers even offer free hosting. Either for limited time period or with limited capabilities. I'm trying not to be a freetard all the time. Not that I always succeed. However, for those that would like to play a bit with examples that could be found on the Internet and try them out, free hosting is a nice feature. However limited it may be.

Since I need to delve into finding hosting for example applications I intend to write for this blog, I expect to learn more about it. When I do, what I do will be shared in some future post.

Strange case of Node.js and Web Server

Node.js is running on its own web server and can not use other web servers

 

There is a great deal of misunderstanding as to how node.js really operates. The usual misconception is that:

node.js = Apache + PHP, or

node.js = IIS + ASP.

Hardly. Both Apache and IIS are general purpose (or standalone) web servers. The name says it all, they serve web pages and, in the case of active web pages, their “activity” is controlled by PHP, ASP or whatever server-side scripting language one prefers. PHP and ASP do not (and can not) control behavior of Apache and/or IIS.

Node.js, on the other hand, is a web server in anticipation. It doesn't exist until you write it. As mentioned earlier, it's an executable that enables you to use JavaScript to create the web server tailored to your own needs. In this scenario JavaScript isn't used to control behavior of HTML pages that run on your favorite web server, instead it's used to create and control web server itself. This is a bit simplified version, but not too much. 

There are two other similar projects: Apache MINA which uses Java, and Tornado which is based on Python. This is the perfect cue for my usual rant that, however good competition might be, node.js is superior because it uses the same programing language on both client and server side. Still, I shall try to give a bit more in-depth (and a very honest) comparison of the three. But not here, not now.

IDE support

Insufficient

 

IDE support for node is not lacking lately, in both desktop and web based variety. For desktop, you can find plug-ins for all major IDEs like Eclipse, Visual Studio and NetBeans. For those who prefer online development there are Cloud9, Cloud IDE (a.k.a eXo Cloud IDE, a.k.a codenvy) and Kodigen to name a few. None of them offer my favorite drag-and-drop-double-click-write-code functionality, but what they do makes you quite comfortable. It's the usual: project creation, code completion, running the application and graphical debugging. And a bit more, depending on the IDE. Most of the mentioned IDEs are free with the Pro or Premier edition that cost some money.

There are much more IDEs that support node.js, one way or the other, than I mentioned here, and they are relatively well documented. Still, I do intend to revisit this topic in one of the next few posts on this blog from the prospective of using JavaScript on both sides of the Internet plug.

Conclusion

 

Let us revisit nodejs.org and see their own definition:

Node.js is a platform built on Chrome's JavaScript runtime for easily building fast, scalable network applications. Node.js uses an event-driven, non-blocking I/O model that makes it lightweight and efficient, perfect for data-intensive real-time applications that run across distributed devices.

A rarely concise and marketing-free statement in this business. It says exactly what node.js is in as few words as possible.

So, let's sum it up at the risk of repeating a few things already mentioned. 

JavaScript always features in any top ten languages list on the Internet. Also, take a look at this comparison of programming languages. In the “Intended use” column of the first table only three languages are marked as client-side, server-side and Web. These are Java, c# and JavaScript. That is exactly what we need: both client and server side scripting language that can be used for web development. Alas, it's not all that nice and perfect. Personally, I am not crazy about JavaScript, an interpreted scripting language with garbage collection that can get industrious (berserk?) in the worst possible moment. I dislike the facts that there is no class keyword and that JavaScript is more functional than declarative (more lisp than C++). But that's how it always is you get what you paid for, and JavaScript is free. Luckily, node.js comes to rescue here by enabling you to call libraries written in some language that can behave. And it is also free.

Node.js is not a framework written in JavaScript. The article on Wikpedia perhaps sums it better:

Node.js is a packaged compilation of Google's V8 JavaScript engine, the platform abstraction layer, and a core library, which is itself primarily written in JavaScript.

Node.js contains a built-in HTTP server library, making it possible to run a web server without the use of external software, such as Apache or Lighttpd, and allowing more control of how the web server works.

There is no GUI you can use to change a template and site color theme, and no point-and-click-write-and-publish functionality. You are definitely not going to use it for creating your grandmother's lonely hearts club site, even if it supports online dating. That is CMS and there are web applications (a.k.a frameworks, written in PHP, Python or Ruby) you can use for that. On the other hand, legacy client-server business applications are queueing to be migrated to web platform, and node.js is the right tool for that. Believe it or not, the article about COBOL on Wikipedia states that “In 1997, the Gartner Group reported that 80% of the world's business ran on COBOL with over 200 billion lines of code in existence and with an estimated 5 billion lines of new code annually”. A more recent survey adds even more details to the picture. The bottom line is that a lot of companies are looking for a way to modernize existing COBOL applications by building some sort of web interface on top of them, with the increasing emphasis on distributed systems.

Node is not in “more is better” category. Its ascetic appearance is not appealing to everyone. Strangely, because this is perhaps one of its strongest points. There is no need to read tons of someone else's code or blunder through numerous configuration files and endless list of system variables, which can be quite frustrating. It is always easier to write your own application than to change or customize an existing one. And customizing is exactly what you have to do when you create your application using some web application framework. Not to mention that interpreting a huge number of lines of code on general purpose web server can never be fast. Web application frameworks are excellent for creating CMS, ERP, shopping cart or any subtle variant or combination thereof. A number of excellent frameworks that fit the bill are already on the Internet. But, if you want to create a network application from scratch and use the same scripting language on both client and server side, you use node.js. At least, I would.