NODE在服务器上运行的比JavaScript多得多。
那是NODE的办法，对不对？现在你可以写服务器端和客户端的JavaScript代码。
你将不会再那么辛苦的在学习和不同环境间跳跃。当你不得不从客户端转移到服务器端或从服务器端转到客户端时，这个转换是极其痛苦的，充满血和泪。
我希望你能注意到我的讽刺。
NODE使用JavaScript仅仅只是一个取舍点（对有些人有利，有些人有害）。几乎可以肯定的是，这对于它的成功是有很大贡献的，但是太多了，以致于将NODE的根本点和目的经常丢失。如果这对你来说是显而易见的，那么你可以不用读此文了。
说你喜欢NODE是因为你能在服务器端写JavaScript代码就像说你喜欢红 Lotus Elises是因为它们是被漆成红色一样。不是每一个人都喜欢红色，而且就算每个人都喜欢，这也不是让这个车被得很“好”最重要的理由。
NODE与目前的动态语言现状有着本质的区别。它是由对效率的极度痴迷而产生的。在线程与连接之间经典1对1模式之间的不满让它有能力处理显著增长的用动态语言为web应用写的并发等级。
阻塞和IO问题
不管WEB还是其它应用的瓶颈都是IO引起的。
应用一般都是由数据库，文件系统，网络，或这些介质结合起来来传送/接收数据的。通常，这些信息的传输速度比直接在内存中操作的速度要慢。CPU的过量使用似乎不是你的问题。
第二个问题是我们开始处理问题的方法。从历史的角度上理解电脑，我们能有序地思考。这就是电脑思考问题的方式，对吗？你提供一大堆的指令，然后电脑从上到下有序的执行。你的第一个程序大概像下面这样子：
// print
console.log("Enter your name: ");
// block execution to retrieve data
// keeping the process tied up awaiting the
// data's return
var name = console.read();
// manipulate data and report
console.log("Hello " + name + "!");
但是如果你能以非阻塞方式做的话
// print
console.log("Enter your name: ");
// make a request for the data, but allow the process to
// be free to do other things, providing a bit of code
// to run when the data is retrieved.
console.read(
// When we are notified we have a
// response, manipulate data and report
function(err, name) {
console.log("Hello " + name + "!");
}
);
让你的进程阻塞、等待数以百万计的时钟周期将很浪费时间和资源。为了处理额外的请求，某些情况下你必须使用进程管理器来管理这些线程。为了让web逐渐更具媒体交互性，我们不断地减少每个请求的大小，虽然这些不断增加的请求是由每个单独的客户端发起的。这让为什么请求与进程之间1对1关系很难衡量变得很明显。
站在历史的角度上，我们让自己能够更简单地以第一种风格来说服我们的程序，但我认为第二种方式也是一样的，如果没有太多，像人类一样进行敏锐的判断。
像人类一样思考
作为人类，你知道信息流的异步本性。你凭直觉知道，这仅仅只是没有效果和实用性来阻止每次你需要检索或传达信息时所做的所有事情。
作为一个开发者，你每次向经理或股东询问一个项目的详细情况时，你会简单地坐着然后安静地等待回复吗？不，你当然不会。你移步到下一个你能取得进展的事情上，欺骗一个单方面很充分的重要任务。一旦信息复原，你继续相关的任务。
举个更通俗的例子，你在开车，你旁边坐着你的朋友，你需要知道明天的天气预报。你会刹车，不管交通秩序然后面向你的朋友问他明天天气会怎样吗？你会沉默的等待（除非后面的人按喇叭）直到他为了查询了天气情况？你当然不会，当他告诉你天气情况时，你会继续与他聊别的东西。
在这种方式下，NODE的非阻塞/异步模型在第一次传递时并不需要变得异质。
为什么不用线程
线程是困难，繁重，且大材小用的。
他们确实解决了平行的基本问题，但他们提出一个围绕着线程安全和易变性的全新问题。如果要实施的话，对于动态语言来说它们通常很复杂且很难解决。
在NODE中，除了你的代码，所有东西都平行运行着。
对于你来说，所有事情都可以通过平行来解决。但是由于你的代码永远不会平行的运行，且通常都在单线程中，线程安全和易变性就没有了。这给一般用例的平行化带来了好处，不需要给开发者额外的复杂度。
我认为NODE处理平行化的方法再次反应出我们人类过程思考的方式，并不是并行的，但是高效的多任务。
某某语言也有非阻塞服务
我确信肯定是有的，当你想用不会导致阻塞的第三方包模型时它很可能是有用的。非阻塞被开发社区以哲学方面的思想应用。这是规则，而不是例外。
此外，围绕着异步性的事件循环和支持性基础通过低级语言很好的实现了（V8，libev，libeio等等）。其他许多语言的非阻塞服务将利用这样的库，但创造性的是用它们的动态语言实现。在这种情况下，当与NODE的实现相比时，性能是需要特别关注的。
没有语言或平台是离开权衡的，但我希望实现NODE作为实用性问题的解决方案和有意思的学术研究这个想法。
Testing