diff --git a/website/node.html b/website/node.html index 71cfa866ba..d62f3f9995 100644 --- a/website/node.html +++ b/website/node.html @@ -31,6 +31,7 @@ body { #toc a { color: #777; } h1, h2, h3, h4 { + color: #B0C4DE; margin: 2em 0; } @@ -39,8 +40,8 @@ h1 a { color: inherit; } pre, code { font-family: monospace; - font-size: 13pt; - color: #bab; + font-size: 14pt; + color: #dcd; } pre { @@ -83,9 +84,9 @@ a:hover { text-decoration: underline; }
listen(8000)
.
-File I/O is also preformed without blocking.
In fact, not a single function in Node blocks execution.
-There isn't even a call to run the event loop.
-
-Programmers using this environment will find it difficult to design -their systems ineffiencely. It's impossible to make a database call from a -web server and block other requests. +
Programming in Node is different. Instead of commanding actions, Node +scripts defining behaviors. The entire program is centered around I/O +events.
Check out the API documentation for more examples.
Node is free to download, use, and build upon.
-There are many methods to write internet servers but they can -fundamentally be divided into two camps: evented and threaded; non-blocking -and blocking. A blocking server accepts a connection and launches a new -thread to handle the connection. Because the concurrency is handled by -the thread scheduler, a blocking server can make function calls which -preform full network requests. -
var response = db.execute("SELECT * FROM table"); -// do something- -
An evented server manages its concurrency itself. All connections -are handled in a single thread and callbacks are executed on certain -events: "socket 23 is has data to read", "socket 65's write buffer is -empty". An evented server executes small bits of code but never -blocks the process. In the evented world callbacks are used -instead of functions - -
db.execute("SELECT * FROM table", function (response) { - // do something -});+
+I/O is hard and almost no one gets it right. +This is an attempt to make you to do it right by taking away all those +sharp, dangerous tools called threads. + +
+Node is forced evented programming—so by default you are doing the +right thing. +Well, actually, Javascript +itself is forced evented programming. Node brings Javascript, in the way +it was meant to be, out of the browser. + +
+There +is a major difference in the latency between memory and disk I/O. It looks +approximately like this: -
-l1 cache ~ 3 +l1 cache ~ 3 (CPU cycles) l2 cache ~ 14 ram ~ 250 disk ~ 41000000 network ~ 240000000-
purely evented interfaces rule out a lot of stupidity +
Disk and network I/O need to be treated differently than simple memory +operations. But POSIX obscures the latency with system calls like + +
close(file_descriptor);+ +
For a TCP file descriptor, this is a round trip message to a remote
+computer that can cost billions of CPU cycles. For a hard drive file descriptor,
+close()
could mean a couple million cycles of disk spinning.
+The man pages don't even mention that a call might be preforming very
+long I/O operations. This ambiguity in POSIX is propagated into higher APIs.
+
+
In the Node API all I/O happens on the event loop and thus requires a +callback of some sort. Calls to access foreign database do not look like +simple side-effect free functions. The programmer does not need advanced +knowledge of POSIX to know that I/O is being performed because it looks +differently. + +
Some find event programming cumbersome. +I find threaded programming +cumbersome—it's not a good abstraction of what is really happening. +Because of this bad abstraction it's confusing and difficult to get right. +Threaded programs only look good in the simpliest and most trivial +situations—in real-life applications events lead to better +architecture. -
Javascript is without I/O. In the browser the DOM provides I/O, - but non-browser javascript interpreters have only non-standardized - functions to allow them print to console or access the network. -
Contemporary computer infrastructure has two irreplaceable - languages: C and Javascript. C is the language of operating systems. - POSIX, the universal operating system API, is defined in C. So while you - can interface with operating systems in Java and Haskell, those - languages access must make system calls in C. Similarly, Javascript is - the language of the web operating system. In place of POSIX is the - DOM. You can wrap Javascript, you can compile to Javascript, but in the - end browsers must be interfaced with in Javascript. Portable low-level - systems tend to be written in C and portable web-level systems are - written in Javascript. -
onLoad()
is
-provided to notify the user when all the included modules are loaded.
-Each file can have its own onLoad()
callback.
-onLoad()
will always be called exactly once for each file.
+has a policy of never blocking, the callback onLoad
can be set and will notify the user
+when all the included modules are loaded. Each file/module can have an onLoad
callback.
To export an object, add to the special exports
object.
@@ -447,14 +433,12 @@ Each file can have its own onLoad()
callback.
The functions fail
and deepEquals
are not
exported and remain private to the module.
-
In addition to include()
a module can use
-require()
. Instead of loading the exported objects into the
-global namespace, it will return a namespace object. The exported objects
+
require()
is like include()
except does not
+polute the global namespace. It returns a namespace object. The exported objects
can only be guaranteed to exist after the onLoad()
callback is
made. For example:
var mjsunit = require("mjsunit"); - function onLoad () { mjsunit.assertEquals(1, 2); }