JavaScript NodeJS 适合用来做什么？
正在考虑要不要去学 node.js，想问下有经验的朋友，它最适合做什么？
"Real time"，"No Block"貌似是 node.js 的特点，不过对于没事写写“传统”小项目的我来说，sinatra 以及 rails 已经够满足自己的需求了。
看了作者 Ryan 的视频，也看过简单的聊天程序的例子，除了这些以外还有什么实际的例子吗？
个人觉得写 API Service 和后台服务很合适。我们公司内部有好多项目在用。最近为了对 iDaily 增加又拍云存储的支持（作为一个单独服务对现在的 CloudFront 数据进行并行上传），写了一个简单的开源 node api 实现。
如果一个应用： 1.前端面对大量并发 2.后台还要“缓慢的”和“复杂的”SQL 查询，或者还要连接到外网服务比如 Fackbook API，总之就是 IO 阻塞
这种场景你用 sinatra 就不行，假设只有一个 sinatra instance，那么前一个 request 的 SQL 查询没处理完并反馈给用户页面，后一个 request sinatra 就处理不了，这样在后端数据库能接受 100 个并发查询的时候，你前端一个 web server 只能并发一个查询，那么后端的数据库并发能力就被浪费了，前端的 sinatra web server 就成了瓶颈，而不是数据库了！这时你用 node 就非常好，因为 node 就可以一股脑把请求扔到数据库，前端再也不是瓶颈。
你在网上应该会看到大量的这种评测： 假设每次数据库查询用时 1 秒 ab -i 100 -n 1000 => 1100 秒 rails 或 sinatra 场景 ab -i 100 -n 1000 => 11 秒 node 场景（如果 eventmachine 估计就是 12 秒吧）
一般这种场景主要是 api，当然还是新浪微博那种最典型。我不知道一个下限，但如果你只是一个小博客，node 完全没意义，用 rails 多简单啊。
上面说了那么多，其实我 node 一点也没搞过（没实际项目只能算 0）。不过 ruby 的 eventmachine 我搞过，速度非常快，原理和 node 一模一样，如果你不想学 node 的话，你可以学 em。EM 的 api 有点别扭，你可以参考 https://github.com/igrigorik/async-rails ，这是个 fiber + em 的大并发实现，跟着他的模式写，应该比 node 舒服多了
#4 楼 @clc3123 大赞！ #3 楼 @dave 4 楼算是帮我回答了：） #6 楼 @fantasyday 做 prototype 是很方便。Express 确实是参照 Sinatra 来实现的。不过我个人觉得“小”项目（或大项目里的很多小块）用 Node 也是合适不过。以 API 来说，除了 @dave 说的好处，轻巧、占资源少都是其优点。实际 Rails 项目中，用 ActionController 来实做 API 经常会觉得有点过重。
其他小到如简单的网页抓取，用 Node 来替换 Mechanize 也很合适。多线程编程变成了简单的遍历和 callback。
当然非阻塞只是它的优点之一而已，如 4 楼的例子，即使是 Node 来实现，如果实际任务完成后要反馈给 request，那还是要 callback 至请求端或以串行的方式来处理的。这种情况为了避免阻塞，Rails 或 Sinatra 也完全可以用后台任务的方式来处理的，同样能把那 1100 秒降为 11 秒。换句话说，不阻塞请求是因为对每一个请求进行 fire and forget 的缘故。
Node 一方面到处都是 callback（与上面的 callback 不是同一回事），与 Ruby 和其他很多语言中的习惯流程有很大区别。另一方面，在处理非阻塞 IO 时真是太方便（我们的实例中，一个 mp3 在解码后会同时上传到 S3、又拍云、自己的服务器，这种操作中确实是把处理时间由 a+b+c 变成了 max(a, b, c)，同时又直接返回给 api 调用端通知已经开始处理，好处多多）。
用纯粹的 eventmachine，效果和 node.js 差不多，eventmachine, erlang, node.js 三者的效果貌似都非常接近，我折腾了一圈，最终决定用 node.js 用在公司的一个项目中用来响应大量实时的请求，需要大并发，实时响应，目前用下来，就是一开始种种 callback 不习惯，习惯了以后，还是很好用，代码量也不大，关键是自己要明白，要控制住，效能上，目前还没有上实际的环境受过真正的压力，有待进一步调教
node 和 EM 都是用 c++ 写的 EM 看文档上打算用 c 重写，为了性能和兼容性啥的。但是 EM 的插件真的没有 node 多，支持和社区也没有那么多。写 Rails 的人，JS, Ruby 都熟悉随便哪个都能很快上手。
Erlang 最近学了一下，要写业务逻辑负责的东西，我看还是算了吧，支持的库也没有 Rails 或者 node 多。
但是他的分布式能力和 cpu 多核利用能力天生的。搜索了一圈。erlang 做的最多的就是聊天室了，还有消息服务器。其实就是聊天室的底层的服务。就这样。为通信行业所生的语言。
用 go lang 吧 ;)
个人观点，nodejs 适合了解 javascript 的人短时间做出一个适应大量负载的网站。想要在高并发领域更加深入，还需要 erlang, haskell 这样的重型武器。
node 也可以当后台的 parser，这个 http://stylesror.github.com 就是用 node + jade 渲染成 html 的：）
@clc3123 是的，他不是 web server，但是应用程序如果支持多线程，你 web server 才有机会去并发处理多请求。你 web server 多线程，像 Rails 应用，跑一个 instance 怎么跑都只能同时处理一个请求。
两个 sinatra 配置项：
lock Places a lock around every request, only running processing on request per Ruby process concurrently. Enabled if your app is not thread-safe. Disabled per default.
threaded If set to true, will tell Thin to use EventMachine.defer for processing the request.
#29 楼 @zhenning #27 楼 @sunzheng91 哈哈哈 我还想问爬虫为什么不用 Ruby 呢 EventIO，字符处理，正则，HTML 解析都是灰常方便的哇！
#32 楼 @sunzheng91 #30 楼 @hooopo 上面提到的几个点，我都没觉得是优势。使用 python 的原因是因为有些库会稳定一点。如 BloomFilter 的使用。
#40 楼 @jialezhang 对 Spider 感兴趣的话，之前我看到http://www.skorks.com/2009/07/how-to-write-a-web-crawler-in-ruby/，觉得不错
