JavaScript on the server: Growing the Node.js Community

Cloud9 IDE and Mozilla have been working together ever since their Bespin and ACE projects joined forces. Both organizations are committed to the success of Node.js, Mozilla due to its history with Javascript and Cloud9 IDE as a core contributor to Node.js and provider of the leading Node.js IDE. As part of this cooperation, this is a guest post written by Ruben Daniels and Zef Hemel of Cloud9 IDE.

While we all know and love JavaScript as a language for browser-based scripting, few remember that, early on, it was destined to be used as a server-side language as well. Only about a year after JavaScript’s original release in Netscape Navigator 2.0 (1995), Netscape released Netscape Enterprise Server 2.0:

Netscape Enterprise Server is the first web server to support the Java(TM) and JavaScript(TM) programming languages, enabling the creation, delivery and management of live online applications.

This is how the web got started, all the way back in the mid-nineties. Sadly, it was not meant to be then. JavaScript on the server failed, while JavaScript in the browser became a hit. At the time, JavaScript was still very young. The virtual machines that executed JavaScript code were slow and heavy weight, and there were no tools to support and manage large JavaScript code bases. This was fine for JavaScript’s use case in the browser at the time, but not sufficient for server-side applications.

Still, there are two obvious advantages that support this idea of using JavaScript not only in the browser, but on the server as well:

Skill reuse. Developers only have to learn a single programming language that they can use for both client and server-side programming. Front-end developers can leverage their existing skills to build server applications too.

Code reuse. The opportunity to write your code once and be able to run it on either client or server, opens up great opportunities. The most obvious example would be reusing code to validate forms, which you have to do on both sides anyway. But there are many more exciting opportunities to be explored, e.g. the ability to dynamically decide where to render your UI (client or server, or a mix) based on device capabilities.

Over the past decade and a half, many projects have tried to reintroduce JavaScript on the server, but again and again there was very little uptake.

A New Hope

Then, Node.js happened. Node.js is the first implementation of JavaScript that people get genuinely excited about. Why is that? What makes Node.js different from previous attempts?

As it turns out, previous attempts dismissed one core, powerful and often overlooked feature of JavaScript: its single-threaded nature. JavaScript is single threaded in the browser. Nevertheless, previous server-side JavaScript implementations did have regular threading the way every server-side language does, like Java, Python or Ruby, for instance.

Node.js deliberately took a different path, the path more in line with browser JavaScript: Node.js is single threaded, and event based.

This has two advantages: it avoids concurrency issues and it supports the construction of super efficient high-performance servers.

Programming with threads is hard. Very hard. When things happen at the same time concurrency bugs can occur easily (e.g. two threads modifying the same piece of memory simultaneously), which are incredibly difficult to reproduce and fix. Courses are taught at universities to teach students how to avoid concurrency problems using locks, semaphores etc. Concurrency is difficult, it’s best to avoid it when possible — Node.js enables you to avoid concurrency by not supporting it at all, at least on a process level. In a Node.js process, only one thing happens at a time.

Servers built with Node.js are typically super fast and can handle thousands, tens of thousands, even hundreds of thousands of concurrent connections — something very difficult to achieve with threaded servers. How can that be?

It’s all based on the observation that server threads in typical web application servers spend most of their time doing nothing — just idly waiting for the result of a database query, waiting for the disk to spin and return a file that’s requested or waiting for data to come over the network. For every single connected client there’s a thread just sitting there, idly, using up resources.

Node.js servers work differently. Node.js uses asynchronous APIs for operations that require I/O such as fetching a file or sending a database query. This is exactly the same way AJAX calls work in the browser, as well as other recent asynchronous HTML5 JavaScript APIs such as various database APIs (IndexedDB and WebSQL) and Geolocation. All these APIs don’t want to block the browser thread, because it may take half a second or even multiple seconds to retrieve the results, which would freeze up the browser. Instead, they simply trigger the call and pass a callback function to be invoked when the results come in. In the mean time, the browser thread can keep rendering the page and do other things. This is exactly how any I/O API works in Node.js.

The Node.js Community

The Node.js community has been growing rapidly over the past years. More and more companies build their servers with Node.js, especially for servers that require real-time communication and therefore have to handle a lot of simultaneous connections. As the real-time web grows, so will the use of Node.js.

Therefore, it is time to make Node.js more accessible to the developer community. To do this, Node.js needs a few things:

Tooling

Good documentation

A community website with in-depth articles and tutorials

Training

At Cloud9 IDE we have set ourself the goal to build the best possible IDE for Node.js development. After all, Cloud9 IDE itself is a prime example of what we envision as the future of web development: Cloud9 IDE uses JavaScript front to back, using browser Javascript on the client and Node.js on the server.

Using Cloud9 IDE you can try out and play with Node.js without having to install anything. You can create Node.js projects, run, debug and deploy your project right from the IDE.

In collaboration with partners in the Node.js community, we are now launching three more initiatives:

Nodebits.org is the new community website for Node.js developers with the latest news, in-depth articles and tutorials.

NodeManual.org is the new one-stop source of Node.js documentation. The MDN of Node.js development, if you will.

Technical Evangelist & Editor of Mozilla Hacks. Gives talks & blogs about HTML5, JavaScript & the Open Web. Robert is a strong believer in HTML5 and the Open Web and has been working since 1999 with Front End development for the web - in Sweden and in New York City.
He regularly also blogs at http://robertnyman.com and loves to travel and meet people.

19 comments

jon

node.js is awesome unless your running it on windows
we need more tools and utils built for windows to work with node.js
projects like npm need to be re-built with windows inmind and not just “porting” over to windows

Are you implying that node.js’ only usage is serving data through http?

Why would we disregard its usefulness on the desktop? It comes with filesystem access and te ability to communicate by other means than http. In all seriousness, why wouldn’t you use it for you general local scripting needs?

I can think of a ton of reasons to want to run it on windows, most of which don’t mean running it in production. Most computers today run windows. Do you really think someone learning a language/framework (or whatever Node is) is going to be happy that they can’t even set it up locally?

I’m sure 90% of people who learned php did so on their windows machines, and probably most of those had php installed locally so they didn’t have to edit files across a network.

I’m a mac person myself, and tend to deploy things on linux. I would never give up the ability to have a full development environment that runs locally.

When I decided to learn Node.js a few months back it did not have a decent Windows port. It came down to… either wait for a port or just join the Linux bandwagon. Believe me, it took just about a week to install Ubuntu on VMWare under Windows and learning a few basic commands to get going.

Jon’s absolutely correct. Node.js is a great tool, but there is just not enough support for developing with it in a Windows environment.

Not to get into a Win v Linux battle, but the only reason I would develop solely for Linux is if I consciously chose to write a program for 20% of computer users. As a business owner, why would I choose to eliminate approximately 80% of my potential user base? I love Linux, but I have to turn a profit or Im out of a job.

Yesterday in my IT class from MUST University, I learned that Netscape Enterprise Server is the first web server to support the Java(TM) and JavaScript(TM) programming languages, enabling the creation, delivery and management of live online applications.

Wow, i have come to love Nod.js. I just started learning it a couple of days back and I think strongly that for what i have come to understand, the future of backend development anchores in Node. I have been programming in javascript for a while now and I think i will not waste more time revising php but will just concentrate of javascript and Node. Thanks to you master Ryan Dahl for you ingenuity.