这是一个创建于 3539 天前的主题，其中的信息可能已经有所发展或是发生改变。
对于前端转后端的童鞋来说,可以直接用前端语言写后台,这个是优势
对于其他童鞋来说,用NodeJS有啥优势呢?
有什么非用Node不可的理由么?
 |
1
dalang 2015-02-27 13:10:25 +08:00
主要还是性能吧，速度快，占用资源少。如果对性能要求不高，我觉得就没到非 node 不可的地步。
|
 |
3
otakustay 2015-02-27 13:30:41 +08:00
NodeJS强在IO性能上，这点确实不是Ruby可以比的
现在很多系统，瓶颈都在IO而不是CPU了，NodeJS在同样精力进行运维的情况下，IO性能强过主流静态语言Web框架是没啥问题的 |
 |
6
datou552211 2015-02-27 13:43:32 +08:00 via iPhone
因为它用的是js
|
 |
7
jarlyyn 2015-02-27 13:56:13 +08:00
1.性能
2.js.前后端一致，可以共用很多库。 |
 |
8
youxiachai 2015-02-27 14:18:27 +08:00
主要是对js有爱..... 扯其他的都没用....特别是扯性能的....
|
 |
9
zhaoweikid 2015-02-27 14:27:24 +08:00 via iPhone
没有非用不可的优势
|
 |
10
kalasoo 2015-02-27 14:30:37 +08:00
入 Node.js 坑前，可以看一下 io.js
|
 |
11
typcn 2015-02-27 14:31:55 +08:00
Java 不是性能最差的吗？
各种测试结果都很高 实际使用起来倒数第一 |
 |
12
acthtml 2015-02-27 14:34:05 +08:00
对我而言
ruby的优势是ror nodejs的优势是js 但是都没有万能的php好用。 |
 |
14
WildCat 2015-02-27 14:42:26 +08:00 via iPhone
个人感觉 nodejs 的内存占用不比 Ruby 小。
|
 |
15
marshalchen 2015-02-27 14:42:56 +08:00
性能的话是rails的劣势，不是ruby的劣势。
node的优势只在少数场景下比较明显，整体没太多优势，只是多了种选择而已。 |
 |
16
Mirana 2015-02-27 14:49:22 +08:00
异步的io把，假如同步的框架并发1000个请求挂掉了，那么node应该还没挂掉
|
 |
17
skywalker 2015-02-27 14:55:27 +08:00
> 有什么非用Node不可的理由么?
没有。 论写程序的舒服程度，肯定不如Ruby；论性能，不如Go；论并发性，应该不如erlang。 但是大部分的项目其实要求都没有这么高，找个写着舒服的吧。 |
 |
18
momo5269 2015-02-27 14:56:51 +08:00
|
 |
19
66beta 2015-02-27 14:58:25 +08:00  1
nodejs被拿来跟各种语言比，每个语言都在某个点上战胜它
反过来，也就是说，node的综合性能是最强的 抵制java PHP万能 |
 |
20
jprovim 2015-02-27 15:08:29 +08:00
Rails vs NodeJS
Ruby vs JavaScript 拿一個 Programming Language和 Framework比較, 是沒有意義的. 如果非要這兩個比較的話, * Rails的話, 框架成熟, 畢竟是05年的有將近10年產齡的老產品. * 前端上手Node快, 不用2次學習, 開發快. 當然了, 具體怎麼選擇, 還是看整個團隊擅長什麼. |
 |
21
scarecrow 2015-02-27 15:18:36 +08:00 1
又是语言之争，没有最好的只有最合适的。
ruby 优雅灵活，一旦喜欢上让人欲罢不能 nodejs 前后端一套解决方案，用着省心。 顺便说一句，相比性能，开发效率，快速验证想法更重要是，很多产品还轮不到你考虑性能问题的时候就挂了，性能问题只是意淫而已。 |
 |
22
kleetaurus 2015-02-27 15:27:55 +08:00
Node.JS的优势：
1. JS通吃前后端，学习语言的时间成本比较低； 2. 处理效率非常高（基于Google v8引擎、非阻塞I/O）。 |
 |
25
tabris17 2015-02-27 16:11:51 +08:00
学习成本低
|
 |
26
hahastudio 2015-02-27 16:18:19 +08:00 1
Node.js 让不会区分语言、框架的人也能用
|
 |
28
miyuki 2015-02-27 16:23:58 +08:00
会 javascript 的可以很快，不，立即上手
|
 |
29
robertlyc 2015-02-27 16:24:11 +08:00
一个回调 就抹平了性能优势
开发效率才是优势 |
|
30
otakustay 2015-02-27 17:24:59 +08:00
@esyed 同运维环境下，进行相同简单的优化，node的IO比java的nio强应该是没问题的
我的意思就是，不要node就放那跑，而java从代码到jvm等一系列优化全用上去比。我们假设都是一个相关领域做了2-3年的人来做这事，node的IO超java是妥的 |
 |
32
esyed OP @kleetaurus JS是门非常丑陋的语言
|
|
33
esyed OP |
|
34
scarecrow 2015-02-27 19:53:16 +08:00
|
 |
35
joyee 2015-02-27 21:21:28 +08:00 3
从 Ruby on Rails 转移到 Node.js 的 Linkedin 就有给出过他们转移的理由……摘录一下
How LinkedIn used Node.js and HTML5 to build a better, faster app http://venturebeat.com/2011/08/16/linkedin-node/ 概括：Linkedin 的移动端服务器完全迁移到了 Node.js 上，主要是规模优势+I/O优势，用ROR的时候15台服务器，每台机子15个instance，转移到Node之后每台4个instance，并且能够处理的流量翻倍。 Ruby on Rails vs. Node.js at LinkedIn http://www.infoq.com/news/2012/10/Ruby-on-Rails-Node-js-LinkedIn 概括：这篇的数据是Node.js某些场景下快20x倍，从30台服务器缩减到3台，前后端团队可以合并提高开发效率。Linkedin的性能提升一部分是因为原来用Rails写的服务器用的技术太老（虽然当时是前沿）加设计不合理，单线程还阻塞的的Mongrel在需要跨数据中心做请求的情况下内存泄漏得跟筛子一样。另外指出拿Node.js和ROR比不太合理，一个是low-level的服务器，一个是完整的web框架 |
|
36
joyee 2015-02-27 21:25:26 +08:00 2
和Java比较的话，Paypal的经验比较有说服力，因为他们不是重写（毕竟不管换不换技术一般重构都会带来提升的），而是Java和Node同时开发一个系统，最后选择了Node
Node.js at PayPal https://www.paypal-engineering.com/2013/11/22/node-js-at-paypal/ 1. 降低前后端沟通成本，方便培养全栈工程师 2. 一开始只在原型使用 Node.js，效果很好，于是后来直接应用于生产环境 3. 一开始 express 路由 + nconf 配置 + grunt 构建，但 express 写法太灵活缺乏一致性不适合多团队环境，造了一个 Kraken.js 帮助大型团队进行开发 最初应用于生产环境是流量最高之一的账户概览页面，安全起见 Java 和 Node.js 两个版本同时开发。 开发速度： Java 团队5人，Node 团队2人，Node 团队在延迟2个月才开始的情况下3个月内赶上 Java 团队的开发进度： * 在人数更少的情况下，Node开发速度是Java的两倍 * 代码量少了33% * 文件数目少了40% 性能： Java使用基于Spring自创的框架，Node使用自创的Kraken.js和express，dust.js以及其他开源库，3条路由，每条大约包含2~5个API请求 * 每秒完成的请求数是Java的两倍 * 响应时间快了35% 这篇有更详细的介绍 How Paypal is being revolutionized by Node.js & Lean UX http://www.nearform.com/nodecrunch/release-the-kracken-how-paypal-is-being-revolutionized-by-node-js-and-lean-ux/ 其他一些比较有趣的 War Story： How We Built eBay's First Node.js Application http://www.ebaytechblog.com/2013/05/17/how-we-built-ebays-first-node-js-application/#.VPBikeEc9-W Node.js + Cocktails: Scaling Yahoo! http://finance.yahoo.com/video/node-js-cocktails-scaling-yahoo-051216550.html |
|
37
esyed OP @joyee Node 团队在延迟2个月才开始的情况下3个月内赶上 Java 团队的开发进度, 是Node高手打败Java菜鸟么? 貌似Java开发体系还是很完善的,Node工具很多是渣,赶上是小概率事件吧?
|
|
38
joyee 2015-02-27 21:55:38 +08:00
@esyed 主要是Node确实适合快速迭代开发的模式，http://www.nearform.com/nodecrunch/release-the-kracken-how-paypal-is-being-revolutionized-by-node-js-and-lean-ux/里面就有提到Node团队3天内就用Node+bootstrap初步实现了David Marcus给他们打的草稿（用过Node的都很好想象Node干这种事情有多快……），接着进入快速迭代的阶段，不断地测试，接受反馈，改进。相比之下Java团队笨重得多，等他们搞完了controller层跑起来的时候，Node团队已经实现了最初的功能了。
另外个人参与过J2EE项目的前端开发，这种项目如果前端业务复杂度比较高的话后端的程序员很难独自搞定前端开发，必然要有专业的前端，分开前后端团队，这样就增加了一层沟通成本，也会拖慢项目进度。而Node的好处之一也是前后端可以一个团队完成，降低沟通成本 |
|
39
joyee 2015-02-27 22:06:40 +08:00
@esyed 虽然Node社区确实良莠不齐，不过好用的那些确实好用，如果工程师水平足够高的话，没有好用的也能自己造。像Paypal也提到了Express不适合大团队开发，他们就在上面再搞了个Kraken.js方便大团队合作，他们还fork了dust.js，为自己的业务改进。本来他们的Java团队也是自己在Spring上面再定制了一个框架的，大公司有造轮子的能力的话，工具啊开发体系啊这些并不是大问题……
|
|
40
joyee 2015-02-27 22:16:23 +08:00
@esyed 还有就是，不太可能是Node.js高手 v.s. Java菜鸟，毕竟Paypal用了多少年的Java，而当时Node才诞生不到三年……又是年收入 $3.5 Billion 的 checkout 系统，更不可能交给菜鸟玩了……
|
|
42
joyee 2015-02-27 23:17:33 +08:00
@esyed 感觉是的，linkedin的采访也说了Node不适合处理复杂的数据，主要优势还是I/O，这个确实是强项，而其他用异步I/O模型的技术又没有Node那么热闹的社区和V8这样的挂……
等到ES6和promise/generator的异步处理普及了可能应用场景会更广一点，不过JS里那堆坑……业务一复杂人一多难免就会踩啊踩…… |
|
43
esyed OP |
|
44
joyee 2015-02-27 23:26:25 +08:00
@esyed nearform的那篇采访说的是bear in mind that checkout is a system that generates $3.5Billion revenue for PayPal……
V8是个黑魔法外挂的意思……XD |
|
45
joyee 2015-02-27 23:29:00 +08:00
@esyed 你转的那个新闻说的是移动端的交易量……他那个Node和Java一起写的是整个checkout系统，数字应该是巧合吧……
|
 |
46
jun4rui 2015-02-28 11:24:22 +08:00
Nodejs用来处理复杂的逻辑还是不行，因为javascript那个异步+回调简直就是复杂逻辑的克星啊！
但是现在前端和取数据这一块的逻辑真的99%的网站都不复杂，而IO才是瓶颈。所以Nodejs缺点得以回避，优点得以发扬光大。 |
 |
47
futursolo 2015-02-28 12:55:34 +08:00
回调地狱23333
|
 |
48
hooluupog 2015-02-28 15:20:48 +08:00
性能吧，感觉js引擎提升后，js一下高大上了许多。
|
|
49
joyee 2015-03-01 08:52:23 +08:00
@jun4rui JS ≠ 回调，并且 JS ≠ 异步。是否异步和鼓励回调，都是由 runtime 决定的，Node.js 确实是异步并且整体上鼓励回调 ，但不代表 JS 本身就是这样不能改了。浅一点来说可以用 CPS，深一点来说ES6 的 promise 和 generator 都是回调的代替方案，Node.js 上的 Promise 和 Generator 也都开始普及了（比如 Q，co/Koa）。抛开 Node.js 来说，国内的 fib.js 就把异步逻辑放在了 runtime，上层的 JS 代码用同步的方式写，下层在 runtime 里进行异步的处理，应用层的程序员也完全可以避开回调。
|
 |
50
XadillaX 2015-03-01 12:41:39 +08:00 via Android
我就说一句话，我是一个被 NPM 宠坏的孩子，这让我不想去碰 ruby，python 等一样有包管理的语言。
|
|
53
XadillaX 2015-03-01 13:00:16 +08:00 via Android
@jun4rui 我只是说包管理的机制。python 是一套一套版本来的，npm 各版本互不干扰，一个项目可以有各种版本的包，py 等只能同时用一套版本，一切换就是一套。
|
|
56
jun4rui 2015-03-01 17:49:10 +08:00 via Android
@XadillaX 这个对架构现实的软件我觉得不重要，可能我这里环境没这个需求。
我这里要重建已经稀烂的Java项目，在nodejs、Python、PHP之间考虑，最后还是选择了Python，nodejs对太多的复杂逻辑写起来实在让人担心。而且框架django稳定性延续性都很棒，适合长期维护使用。 换nodejs+express我真没这个胆量去做一个长期维护的玩意。 但是一些短小精悍逻辑简单直接的我觉得nodejs倒是首选。 可能还和咱们开发要求不同有关系，也许你那边确实nodejs能抗大任。 |
 |
57
qiukun 2015-03-01 18:31:57 +08:00 via Android
@XadillaX 那你多个node的时候得nvm吧？在这个层面隔离py 和 ruby也很六呀。你这个黑的无力。（nvm也是从rvm来
|
|
59
joyee 2015-03-01 19:09:47 +08:00
@jun4rui 是的，JS确实不适合写复杂逻辑，但原因不是异步+回调，而是弱类型+语言设计本身的各种坑，多人协作容易出乱子……
|
|
60
joyee 2015-03-01 19:12:18 +08:00
@jun4rui 异步不一定要浮现在应用层代码，回调有很多替代方案，但语言本身的坑怎么填都填不过来……除非用 TypeScript 之类带类型检查和填了坑的编译到 JS 的语言，但是又有点隔山打牛了……
|
|
61
joyee 2015-03-01 19:19:47 +08:00
@jun4rui 其实看看 linkedin，ebay，paypal之类大厂的做法就知道了，他们都是用其他语言实现复杂的业务逻辑，提供接口给node来用。node主要是发挥I/O的优势起到胶水的作用，典型的就是 ebay/阿里系那样，node可以负责路由的逻辑，调用 Java 之类适合复杂逻辑的语言写的数据层，生成/返回 HTML和配套的前端CSS/JS，或者web service 的API。
|
|
62
esyed OP @jun4rui node在io方面与其他语言的比较资料网上好像不多,只找到一个和.net的比较
http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/ @XadillaX 你现在是node程序员么?现在整日撸node? 一个项目同个包可以有不同版本,这是node_modules嵌套吧?这么多node_modules目录,太浪费空间了吧? 执行也更浪费内存吧? @jun4rui 为何没选ror,而是选django? @joyee TJ好像投奔Go了,是不是被毁掉折腾疯了?哈哈 |
|
63
esyed OP @joyee paypal那个系统的业务逻辑也是用node写的吧? node调用其他语言,有人这么干过么?如何调用,哈哈有人用Node调用过其他语言么?
|
|
64
joyee 2015-03-01 20:31:49 +08:00
@esyed TJ现在在做分布式系统而不是 web 开发，明显go更合适嘛……而且他很明显认为generator才是node的希望，所以搞了co/koa，但现在generator还不够普及，node之前在joynet的独裁下，对V8和ES6的更新太慢（所以才闹出了io.js），失望了也很正常，不代表他再也不会回来的……
调用其他语言的数据层，也就是一个API的事情，并不是直接开一个进程这种调用啊……何况会要专门写一个数据层的网站，这些东西明显不在一台机器上…… |
|
65
joyee 2015-03-01 20:39:32 +08:00
@esyed 不同版本的包更浪费内存这个是怎么推出来的……不管node_modules怎样，反正只会加载代码里实际用到的那个版本进内存啊。怕浪费空间的话，定时npm dedupe一下合并重复的依赖就可以了。
|
 |
66
0987363 2015-03-01 21:26:06 +08:00
后端怎么没有我大c跟大go呢。
|
|
68
XadillaX 2015-03-02 08:52:14 +08:00 via Android
@qiukun 你跟我说的不是一回事，我说的不是 node 版本，而是依赖包的版本。python 的依赖包同时只能是一个版本，比如依赖的依赖是你的依赖的话，版本万一不兼容呢？而 node 的话项目依赖是在自己文件夹下。依赖的依赖是在依赖的依赖文件夹下，依赖的依赖是你的依赖，你可以任何版本无所谓。不会出现不兼容让你头疼的时候。
|
 |
69
angelself 2015-03-02 10:59:02 +08:00
数据挖掘总告诉我说ruby是冷门语言没几个人用的（鄙夷脸）
感觉也没那么冷门诶~还是经常看到有人用诶~感觉是最萌的耶~=w=还是挺喜欢Ruby的 |
 |
70
duzhe0 2015-03-02 11:41:07 +08:00
node.js是一个原生纯异步的web框架，异步是它和ROR最大的区别。在高并发的业务场景下，非异步框架往往都是抗不住的。
|
 |
75
fwee 2015-03-03 11:11:44 +08:00
说性能的就呵呵了，用ruby的很多都是不屑用callback那种别扭方式写代码，你以为ruby没异步io（EM）？人家早几年就开始用fiber封装了 node捡起来还当个宝了
|
 |
76
kurten 2015-03-03 12:04:31 +08:00
没有什么非用某种平台或者技术的理由，对于这个，争论来争论去没啥意义。看团队，什么熟悉用什么，或者对那个感兴趣用哪个。实在不行，自己在造个轮子又何妨？
|
 |
77
aksoft 2015-03-03 19:43:51 +08:00 1
十年经
|
|
78
joyee 2015-03-04 01:01:42 +08:00
@fwee 虽然有异步/非阻塞的库，但是如果社区的各种东西主流还是非异步/阻塞，要真正用上异步还是不容易，ruby和python都是这样。node这方面的优势不过就是新技术（在后端而言）的优势——没有包袱而已，相比之下node社区的主流都是各种异步的包，可以少造一点轮子。其实node本身就自带事件机制，有一定经验的人都会尽量避开callback hell，现在社区的异步处理也开始趋向promise/generator了，只是之前joynet一意孤行对ES6的支持进展太慢，所以才闹出了io.js。
ruby和node都有自己的长处和短处，没有哪个比哪个绝对好。拿node写CRUD应用肯定也没有用ruby来得快，但在ruby做异步编程，包就不如node好找。何况最后还是得看团队熟哪个再用哪个，不然哪个的优势都不能发挥出来。 |
|
79
fwee 2015-03-05 23:55:42 +08:00
@joyee 那是因为你不了解
https://github.com/postrank-labs/goliath （最近在node社区大火的generator？几年前rubyist用来开发api） EM.defer能很简单的使用同步库 python界同理 异步真心坑，没必要只因为个js来限制自己 |
 |
80
est 2015-03-06 09:15:33 +08:00
@fwee Goliath 用了太多C++魔法。。。。很多正统Rubyist看不惯。
要说纯Ruby风格的还只能算 Celluloid::IO 。 我工作也是用Goliath。这玩意能解决大问题，但是自身也有大问题。目前正在研究Einhorn，研究出来会发 ruby-china.org |
|
81
fwee 2015-03-06 11:08:55 +08:00
@est Goliath大量用Fiber，这是ruby标准库何来C++魔法？EM也没有C++的影子啊
Celluloid::IO前几年很坑，貌似已经脱离erlang(模仿erlang的api少了不少)向akka靠拢？(没用过akka) 很难说是ruby风格(倒是体现了ruby的表达能力) 其实现在microservice和云计算这么火，都是container level语言无关，个人很难看好这种在语言内部实现并行/并发来解决问题的方式.. |
|
82
est 2015-03-06 12:51:01 +08:00
@fwee 没看到C++可能是因为你真的没去看过而已。。。。
https://github.com/eventmachine/eventmachine/blob/master/ext/rubymain.cpp 这个就是EM的核心。。。 老文章一篇 http://www.paperplanes.de/2011/4/25/eventmachine-how-does-it-work.html |
|
86
joyee 2015-03-06 14:45:54 +08:00
@fwee **能够**使用同步库是没有意义的，因为一旦某个地方阻塞住了，整个非阻塞系统的优势就被消灭了。这也是为什么python早就有twisted但是没发展起来的原因，python的标准库和主流的包都是阻塞的，放到一个非阻塞的系统里，异步的优势就没了。既然里面的计算都是要阻塞的，为什么要勉强用非阻塞+单线程（事件机制），而不用原来的阻塞+多线程的方式呢？
|
|
87
joyee 2015-03-06 14:54:05 +08:00
@fwee 另外generator也不是近几年才有的，1999年发布的ES4就有了，但是ES（JS）当年主要活在前端，依赖浏览器厂商的支持，实现新特性的阻力要比其他语言大得多，ES4的改进太激进了所以失败得比较惨，才有了目前浏览器里实现得比较广泛的，做了更多妥协的ES5。node活在后端，已经算是比较轻松的了，现在io.js从node.js分裂出去，也是为了能够脱离joynet的独裁，使用更新的V8，用上ES6的新特性。
|
|
89
joyee 2015-03-06 19:16:36 +08:00
@alsotang 0.0 其实并没有什么好战的咩……ruby和node各有长处和短处嘛……
最美好的就是ES6成功，node merge 回 io.js 转用新版本V8，社区转用更正常的方式处理异步。ruby社区也能有更多异步库可以选择不用担心轮子问题。嗯这样大家爱用哪个用哪个，擅长哪门语言用哪门，天下太平~~ 不过现实一般比较骨感…… |
 |
91
jedihy 2015-07-21 22:01:05 +08:00
回调的方式写程序很蛋疼，只针对某些应用用nodejs写会好一些。如果你要做的跟非阻塞IO无关的话，那就很蛋疼，没什么优势。
|
Select Language