Node v0.8.0

I am extremely pleased to announce the release of a new stable version of Node.js.

Compared to the releases of Node version 0.6, the new release will provide a significant improvement in many key performance indicators, as well as clearer embedded APIs and new debugging tools.

In short

With the arrival of version 0.8.0:
')

1. Node has become much faster.
   
2. Node has become more stable.
   
3. You can work with file descriptors again.
   
4. The cluster module has become much more stunning.
   
5. The domain module has been added.
   
6. The repl module is better.
   
7. The waf assembly system has been replaced with gyp.
   
8. Some other changes also happened.
   
9. At the bottom of the blog entry are links to the Node installation files.

Speed ​​performance

In this version, few key changes were introduced in V8 and libuv, which caused a significant performance improvement.

All of the following measurements were made on my laptop with OS X, but the results are typical with respect to observations under SmartOS, Linux and Windows.

# io.js # 0.6.19,   1024  : 19,428793471925395 /  4096  : 59,737156511350065 /  16384  : 83,97010664203543 /  65536  : 97,4184120798831 / # 0.8.0,   1024  : 61,236987140232706 /  4096  : 109,05125408942203 /  16384  : 182,18254691200585 /  65536  : 181,91740949608877 / # v0.6.19,   1024  : 29,96883241428914 /  4096  : 62,34413965087282 /  16384  : 165,7550140891762 /  65536  : 266,73779674579885 / # v0.8.0,   1024  : 57,63688760806916 /  4096  : 136,7801942278758 /  16384  : 244,8579823702253 /  65536  : 302,2974607013301 / 

The difference is considerable. If you write network programs with Node and drive significant traffic, you will notice this improvement.

The speed of reading files has also become noticeably faster:

 # v0.6.19   110948  ( — ) 90141,32   1  ( — ) 11093,69    ( — ) # v0.8.0   158193  ( — ) 63217,16   1  ( — ) 15818,48    ( — ) 

And, of course, the results of the ubiquitous test of the HTTP server “hello, world” show a noticeably higher speed, especially with a large message size:

 $ TYPE=bytes LENGTH=123 bash benchmark/http.sh 2>&1 | grep  # 0.6.19   : 3317,24 ( ) # 0.8.0   : 3795,34 ( ) $ TYPE=bytes LENGTH=1024 bash benchmark/http.sh 2>&1 | grep  # v0.6.19   : 3258,42 ( ) # 0.8.0   : 3585,62 ( ) $ TYPE=bytes LENGTH=123456 bash benchmark/http.sh 2>&1 | grep  # v0.6.19   : 218,51 ( ) # 0.8.0   : 749,17 ( ) 

The difference with the Unicode response is even more noticeable:

 $ TYPE=unicode LENGTH=1024 bash benchmark/http.sh 2>&1 | grep  # v0.6.19   : 3228,23 ( ) # v0.8.0   : 3317,60 ( ) $ TYPE=unicode LENGTH=12345 bash benchmark/http.sh 2>&1 | grep  # v0.6.19   : 1703,96 ( ) # v0.8.0   : 2431,61 ( ) $ TYPE=unicode LENGTH=55555 bash benchmark/http.sh 2>&1 | grep  #v0.6.19   : 161,65 ( ) #v0.8.0   : 980,38 ( ) $ TYPE=unicode LENGTH=99999 bash benchmark/http.sh 2>&1 | grep  # v0.6.19 ^C #      # v0.8.0   : 252,69 ( ) 

The more bytes you transmit, the more work you do, the more noticeable the superiority of Node version 0.8 over 0.6 will be for you .

Most of the productivity growth comes from improvements in the V8. The V8 developers were very responsive to the needs of the Node.js project. Most of the success of Node comes from the ability to build Node on top of such an outstanding VM.

Assembly system

From the outset, Node used the WAF build system, which is based on Python and is similar to SCons. The Chrome project recently switched from SCons to the GYP meta-assembly system. It creates makefiles, or Visual Studio project files, or Xcode files, depending on the system for which it is being built. As part of the Chrome project, V8 is now built via GYP. Using GYP, Node gets the opportunity

• integration with an optimal build system on each platform
  
• ease of integrating the V8 build process into the assembly of the entire Node,
  
• declarative compilation description that improves manageability.

In Node v0.6, GYP was already used for building under Windows, but now GYP defines the build for all platforms. Node's external add-on modules have just begun the transition to GYP, and the node-gyp module is attached to npm. In future releases, node-waf will be officially announced as non- recommended. If your module now uses wscript, please switch to gyp as soon as possible.

Stability growth

The transition from libev and libeio to libuv in version 0.6 turned out to be somewhat destabilizing for many internal parts of Node. There was a reason to make this sacrifice: libuv is the obvious choice of cross-platform asynchronous I / O library , and Node.js performance is impressive under Windows and under Unix. However, the transition from version 0.4 to 0.6 was far from smooth for many users: the libuv library was inferior to Node in age, which affected early releases.

But at present, with very few exceptions, if your program for v0.6 does not go to v0.8, then it is easy to make all the necessary changes to it in the obvious way. Libuv has significantly developed, and as a result Node 0.8 wins in simplicity and efficiency.

For details of changes in individual APIs, see the wiki article on switching to a new version .

Returning File Descriptors

In the Node 0.4 version, there was a listenFD method, with the help of which servers could “listen” to a specific file descriptor already attached to some socket or port. In version 0.6, this functionality was removed - mainly because it was strongly tied to Unix, so it could not be easily transferred to the new cross-platform libuv framework.

But since most often listenFD was resorted to as a method that allowed servers from several Node processes to access the same underlying resource, a cluster module was added for this purpose. Nevertheless, a number of other methods of using listenFD were left with nothing, and that is why some programmers could not use Node 0.6 .

In version 0.8, the previous functionality will be provided by the new server.listen ({fd: number}) parameter .

Another possibility from Node 0.4, not falling into 0.6, was the ability to pass arbitrary file descriptors as stdio to the child process using the customFds array . In Node 0.6, the customFds array can be used to inherit stdio from the parent process, but not to transfer arbitrary handles or file descriptors to the child stdio. Also, there was never a way to transfer something larger than the standard trinity in, out, err , so programs that were waiting for some special open fourth file descriptor failed in that.

In version 0.8, we added the stdio array to the child_process.spawn parameters . Transfer as many file descriptors, handles, and so on - the child process will see them as file descriptors, moreover, they are open.

More powerful cluster

The cluster module in 0.8 is so improved compared to 0.6 that you can simply call it newly written. Its API mainly maintains backward compatibility, but not completely. (Read more in the wiki article about switching to the new version .)

With the exception of these (very small) API changes, if you used a 0.6 cluster, then your program will work in 0.8, but at the same time act faster and behave better. And if you do not pay attention to the merits of the new features of the cluster 0.8, then you are in vain.

There are so many of them that you can’t retell it here. Go read the API documentation .

Domains

The original idea of ​​“domains” was to combine several different I / O operations in order to have some context in case of an error.

Since Ryan has been discussing this opportunity with Node users during the NodeConf Summer Camp last year, the implementation of the “domains” has been returned several times. The problem to be solved is more or less understandable, however, most attempts to solve it either led to a serious drop in productivity, or some difficulties were manifested in particular cases.

So to 0.8 we have come with a very limited version of the implementation of this idea. By default, it is turned off, you can use it at will, when used, it has little effect on performance (and does not affect it in case of non-use). There are plenty of examples in the API documentation , so read them - and you can start an improved catch of bugs and crashes of programs.

The domain module is still considered experimental. We are waiting for your feedback, so please use it and let us know what you think about it.

Repl, readline, TTY

The repl, readline and TTY modules have been significantly pulled. The interfaces between these three modules are cleared and corrected, removing a lot of unpleasant points of contact and simplifying the use of these modules when debugging your programs.

All these nuances sometimes seem such trifles, but these trifles in repl greatly improve life. Personally, I liked the following the most:

1. If you type fs or net or path , the module of the same name will be automatically loaded.
   
2. If you type npm install ... , a useful hint will be displayed.
   
3. There will be no more nonsense in the case when a long line is transferred along the border of the screen, and in it there is also a Backspace to press. Everything will be processed correctly.

Looking to the future

As was the case with the previous even versions, the version 0.8 family will support the stability of the API and ABI throughout its lifetime.

In the 0.6 family, new releases will occur as critical bugs or security holes are fixed until the end of 2012. However, version 0.6 will not be the focus of the development team.

Issues 0.9 will begin in the next couple of weeks. The focus in developing v0.9 is this:

• HTTP implementation. The http module is essentially used in the real world, but it needs descaling and refactoring. Particular attention will be paid to the coordination of interfaces, to increase productivity, to improve the correctness of work in a number of special cases.
  
• Thread API The intent of the streaming API lies in the core of Node. However, as in the case of HTTP, the growth of its capabilities was gradual and clumsy, so now the module will have to be cleaned. Now it is difficult to work with it correctly, especially with regard to error handling.
  
• Libuv streams The libuv handles interfaces will be refactored to accommodate the rest of the code and between platforms.

In addition, in some areas, Node.js can be improved so that the engine has gained internal self-consistency, spoke in JavaScript without an accent, and improved performance. None of these ideas has yet been cast into the flesh, but here is a list of some ideas on our planning horizon:

• You should go from buffers to typed arrays. Buffers will continue to work, but since native JavaScript is typed arrays, it is logical to move in their direction, they declare the preferred API.
  
• Currently, SSL performance leaves a lot to be desired. The interface from Node to OpenSSL turned out to be somewhat unsophisticated, there are quite a few possibilities for its improvement.
  
• The VM module needs significant improvement. It does not have emulation tools for the javascript browser context, which is inadequate.
  
• The crypto module still uses some very outdated APIs. In version 0.8, it accepts buffers in many places (at last!), But still does not provide a streaming interface like other parts of Node.

At this stage, the Node feature set is largely complete. When cleaning inside , something can change, but, as you can easily see, we are not planning to introduce any significant new opportunities. The scope of our work has been outlined, and it is time to continue focusing on improving the stability and performance of basic functions, thereby maintaining the innovativeness of your programs.

And finally, for those readers who are interested in what has been added after version 0.7.12, the usual list of changes in this issue is:

June 25, 2012, version 0.8.0 (stable)

• V8: upgrade to version 3.11.10.10
  
• npm: upgrade to 1.1.32
  
• iowatcher declared not recommended (Ben Noordhuis)
  
• windows: updated program icon (Bert Belder)
  
• http: MUST NOT have a body warnings are sent to debug () (isaacs)
  
• Content blog.nodejs.org placed in repository (isaacs)
  
• Correction # 3503 in stdin: resume () in pipe (dest) (isaacs)
  
• crypto: fixed SetKey () error message (Fedor Indutny)
  
• Added command line flags --no-deprecation and --trace-deprecation (isaacs)
  
• fs: fixed fs.watchFile () method (Ben Noordhuis)
  
• fs: fixed fs.readfile () method in case of pipe processing (isaacs)
  
• Renamed the node_use_system_openssl GYP variable to match the rest of the code (Ryan Dahl)