diff --git a/website/index.html b/website/index.html index 4d38921004..3f4189cb4d 100644 --- a/website/index.html +++ b/website/index.html @@ -93,7 +93,7 @@ than systems which allocate 2mb thread stacks for each connection. Furthermore, users of Node are free from worries of dead-locking the process—there are no locks. No function in Node directly performs -I/O, so the processes never blocks. Because nothing blocks, less-than-expert +I/O, so the process never blocks. Because nothing blocks, less-than-expert programmers are able to develop fast systems.

Node is similar in design to systems like @@ -104,17 +104,17 @@ Node takes the event model a bit further. For example, in other systems there is always a blocking call to start the event-loop. Typically one defines behavior through callbacks at the beginning of a script and at the end starts a server through a call like EventMachine::run(). -In Node, it works differently. By default Node enters the event loop after +In Node it works differently. By default Node enters the event loop after executing the input script. Node exits the event loop when there are no more -callbacks to perform. The event loop is completely hidden from the user. - +callbacks to perform. Like in traditional browser javascript, the event loop +is hidden from the user.

Node's HTTP API has grown out of my difficulties developing and working with web servers. For example, streaming data through most web frameworks is impossible. Or the oft-made false assumption that all message headers have unique fields. Node attempts to correct these and other problems in its API. Coupled with Node's purely evented infrastructure, it will make a -solid foundation for future web libraries/frameworks. +more comprehensive foundation for future web libraries/frameworks.

But what about multiple-processor concurrency? Threads are necessary to scale programs to multi-core computers. The name Node should @@ -131,9 +131,8 @@ API), but this is something that fits well into the current design.

The git repo