@djyde 你听说过安利吗？XD

@esyed flash应该是吃大厂付的专利钱和卖IDE赚钱，Adobe本性就是卖工具的，就好比他们弄出了PDF，就能卖acrobat赚钱了。

现在大势已去了，就算Adobe倒贴，恐怕浏览器厂商也不愿意把重心转过来。何况 flash 在移动端表现实在太惨，更被看衰了……

@jun4rui 其实看看 linkedin，ebay，paypal之类大厂的做法就知道了，他们都是用其他语言实现复杂的业务逻辑，提供接口给node来用。node主要是发挥I/O的优势起到胶水的作用，典型的就是 ebay/阿里系那样，node可以负责路由的逻辑，调用 Java 之类适合复杂逻辑的语言写的数据层，生成/返回 HTML和配套的前端CSS/JS，或者web service 的API。

@jun4rui 异步不一定要浮现在应用层代码，回调有很多替代方案，但语言本身的坑怎么填都填不过来……除非用 TypeScript 之类带类型检查和填了坑的编译到 JS 的语言，但是又有点隔山打牛了……

@jun4rui 是的，JS确实不适合写复杂逻辑，但原因不是异步+回调，而是弱类型+语言设计本身的各种坑，多人协作容易出乱子……

@Comdex java/c转到C++的学习成本也不低吧，rust本来就是冲着C++去的

@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 里进行异步的处理，应用层的程序员也完全可以避开回调。

@esyed 如果只做PC，flash是还有蛮多年可活的，但是当阵地被HTML5蚕食到一定程度，Adobe可能就直接割肉了……说到底还是因为HTML5是多家制定标准+多家浏览器进行实现，虽然少不了撕逼拖慢进步速度但是死期也远得多，而flash基本就只有Adobe维护，哪天Adobe觉得它没前途了完全可以停止支持，就等死了……

@esyed 你转的那个新闻说的是移动端的交易量……他那个Node和Java一起写的是整个checkout系统，数字应该是巧合吧……

@esyed nearform的那篇采访说的是bear in mind that checkout is a system that generates $3.5Billion revenue for PayPal……

V8是个黑魔法外挂的意思……XD

@esyed 感觉是的，linkedin的采访也说了Node不适合处理复杂的数据，主要优势还是I/O，这个确实是强项，而其他用异步I/O模型的技术又没有Node那么热闹的社区和V8这样的挂……

等到ES6和promise/generator的异步处理普及了可能应用场景会更广一点，不过JS里那堆坑……业务一复杂人一多难免就会踩啊踩……

与其说擅不擅长……不如说目前因为 HTML5 兼容性有问题，所以应用才不广吧。

但是HTML5的兼容性肯定是越来越好的，即使是老IE迟早有一天也会淘汰掉，而目前新IE已经开始跟上标准了。反而Flash，目前在iOS和WP都没有直接支持了，亲爹Adobe也明确表示要缩水它的阵地了（http://blogs.adobe.com/conversations/2011/11/flash-focus.html） ，等到HTML5的实现足够好的那一天（真的有那一天的话），Adobe恐怕会毫不心软地直接割肉吧……

不过按照目前浏览器厂商和W3C撕逼的程度，Flash应该还有好几年可活，但是确实要做好被抛弃的心理准备

@esyed 还有就是，不太可能是Node.js高手 v.s. Java菜鸟，毕竟Paypal用了多少年的Java，而当时Node才诞生不到三年……又是年收入 $3.5 Billion 的 checkout 系统，更不可能交给菜鸟玩了……

@esyed 虽然Node社区确实良莠不齐，不过好用的那些确实好用，如果工程师水平足够高的话，没有好用的也能自己造。像Paypal也提到了Express不适合大团队开发，他们就在上面再搞了个Kraken.js方便大团队合作，他们还fork了dust.js，为自己的业务改进。本来他们的Java团队也是自己在Spring上面再定制了一个框架的，大公司有造轮子的能力的话，工具啊开发体系啊这些并不是大问题……

@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的好处之一也是前后端可以一个团队完成，降低沟通成本

和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

从 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框架