在最近 SitePoint 的 PHP vs Node.js Smackdown 一文中，Craig Buckler 对两种语言就如何应对一系列的10个挑战进行了比较来决定哪一个总体上更佳。
Craig 在书中讲到，这些比较总是有些矛盾。作为一个有意思的随访，大家要求 Bruno kvorc （SitePoint 的 PHP 开发者）和 James Hibbard （SitePoint 的一个 JavaScript 开发者）对每一轮提供评论。
下面是他们详细的看法…
第一轮：开始
Round 1 挑战是看你用每种语言多快可以构建一个“Hello World”的页面。这个包括搭建服务器环境所花的时间。
据 Craig 估计，PHP 赢得这一轮，部分原因是因为这种语言“概念上更简单”，并且“对于新的开发者来说不那么吓人”。
Bruno:
PHP 赢得”开始”这一轮纯粹是因为更多的主机支持这种语言因此开始非常简单。这是拿来就好用了而不需要做额外的事情。假如更多的主机忽略使用 Node 命令行而直接采用文件上传的方式，并且在控制面板上用一个简单的 “reload app” 键，那么两者将会一样。然而就在屏幕上显示东西的实际语法而言，PHP 是更简单些——特别是对那些没有编程经验的人而言。
James:
当在本地机器上开发的时候，我没有在两者之间看到很大的不同。在你的浏览器上运行 PHP 脚本，你需要安装一些服务器软件；要运行 Node 脚本，你需要安装 Node， 并且最好安装一个 web 框架比如express. 然而，正如 Craig 说的， PHP“概念上更简单”.Node 的进入门槛更高。对此没有争议。
第二轮: 帮助和支持
第二轮会考量在两种语言中，获得帮助和支持的难易程度。PHP赢得了这一轮，主要因为它出现的更久一些。
Bruno:
关于这个保持沉默。
James:
我同意这个说法。Node是一门新技术，所以目前，帮助会少一些。可是当Node越来越成熟的时候，这方面就不是问题了.
第三轮: 语法
第三轮比较了理解两种语言语法的难易程度。Craig判定这一轮Node获胜。
Bruno:
我非常不同意这个观点。PHP的语法中的确有一些怪象，其中的很多已经被修复了，在新的版本中，还有很多要被移除。另一方面，JS中也有“this”这个问题~
关于bullet 3 (开发的时候，使用js你不需要在client端开发和Server端开发的时候做切换)，我不同意这个观念。服务器环境和客户端的开发环境已经完全不通了，大脑中的切换还是需要的。总是有些新的语法你不能再浏览器中使用，反之亦然，所以这某种程度上也是语言的切换。
Bullet 4 (理解 JS 会让你更希望使用它) 这从某种程度上来说我是赞同的。 我在工作中使用 JS 和 PHP多年，使用 JS 的时间更久，但我对它却喜欢甚少——尽管那纯粹是个人倾向。
James:
我爱 JavaScript。我知道它有它的怪癖，并且我知道一些原因，ECMAScript 2015 将会修改掉一些，并给语言带来一部分令人激动的新特性。JavaScript 是强有力和灵活的，并能适应很多不同风格的编程。与 PHP 对照，我享受使用 JavaScript。Node（Node.js）就是其中之一。
第四轮：开发工具
Round 4：考虑这两种技术所使用的开发工具，Node 因为有开发工具 npm，所以略胜一筹。
Bruno：
虽然，开发者最初受到 npm 的鼓舞，但是现在有 leaps 和 bounds 比 npm 用着更舒服，而且假如你在电脑上安装了同一个库的两个版本的话，leaps 和 bounds 不会让你的系统崩溃。而且相对于 npm 而言，leaps 和 bounds 允许设计者使用递归思想，而递归思想是如此的重要，以至于当开发者准备着手建立一个包管理器时，首先考虑的就是这一点。
npm 还有一个致命的缺点，我把它称为“开发者协作友好”，npm 不能很好地做到这点，对于 npm 而言只有开发者本身能够理解自己写的东西。最后，npm 与 Vagrant 不能很好地兼容，这直接的妨碍了您开始自己工作，就更别说 npm 不关注用户们的需求了。npm 有一个 bug 已经存在了很多年，它导致该软件在 windows 上基本不能使用，这可不算是小问题了。当然 PHP 也有很多愚蠢的错误，但是这些错误并不会与你的系统之间发生问题。
的确，PHP并没有自带编译器，但我不认为它应该这样做。这样的便利不应该由一个包管理器或者说是一个独立的应用来完成。假如将来有一天，有人为 Node 开发了一个很好的包管理器，把它与现有的编译器替换将会极其困难。让它相对独立，人们可以便于切换。此外，安装它仅需要在终端上输入一行代码，或者下载一个安装程序。
书中提到的编译器影响很小的说法，是显而易见的错误。自从PHP开发完成后，编译器就影响了每一位新加入进来的 PHP 开发者，他们中的一些佼佼者不得不将它添加到现有的流程中。只基于编译器存在之前就有很多 PHP 用户的理由，并不能说明它的作用较小。事实上，自从有了它，它就产生了巨大的影响。一些人所说的“对社区造成的影响很少“的言论根本没有事实依据。
现在，我不能在大多数 PHP 开发者都希望安装 Node 这个问题上争论，这是真的事实。可悲的是，很多好的工具都首先基于 Node 下开发，但我仍然希望就像 Node-free 开发环境一样，也可用于开发BowerPHP。
James:
我很高兴有人加入Node。
我喜欢 npm。它易于安装，易于使用，并有数以千计的包可用于几乎任何需要。我也喜欢这样的事实，npm 可以选择全球的和本地的程序包（相比之下，一些语言如Ruby，它的标准需要将你的程序包安装在你的 Ruby 版本的旁边）。它的工具也很棒。一些工具，例如 Bower 和 Grunt，在我工作流中都有一个固定的位置，它们成倍地提升了我的工作效率。
另外值得一提的是，npm 已经开发出了第3版的 β 版。它解决了 Bruno 提到很多问题，例如嵌套node_modules 方法错误等。
下文引用自entire smackdown：
PHP开发人员可能希望（或需要）在某些场合安装Node.js。反过来不是真的。
第五轮: 环境
第5轮要说的是技术的可用性和部署情况，以及被哪些平台和生态系统支持。Craig 对于这一点也不十分明确，但是看起来似乎更偏向于 Node。
Bruno:
Craig 说他曾比较 PHP 和 Node 在 web 方面的优势（常见的 web 开发问题），然后说到处都用到了 JS。首先，我们来比较 Node.js，而不是 JS 本身，其次，我们比较了两种语言在什么环境下可以运行。猴子比鱼要厉害，因为鱼太蠢了不能爬树，但是猴子和鱼都会游泳。那么我们来比较它们做得怎么样吧。
在 web 开发环境中，PHP 获胜了。这里是一些基于 PHP 的桌面程序工具——是的，也许你不会使用它们，但你一定会用这些基于 PHP 的命令行程序。
James:
我和 Craig 又一次达成一致。一些特性让 Node.js 变得如此流行（速度，可扩展性，与 JSON 密切相连，低资源占用）使它适合于许多其他类型的应用程序，例如强有力的物联网设备。我觉得，谁会不喜欢机器人呢？
Node 使得项目获得了提升，诸如NW.js（一个基于 Chromium 和 Node.js 的应用），它允许你在 HTML 和 JavaScript 上编写本地 APP。这多令人兴奋！
第六轮: 整合
第 6 轮我们来看一下数据库和驱动的整合方面，PHP 胜出主要是因为它的年龄比较大。
Bruno:
整合方面其实是平局的，PHP 有年龄的优势，可以有更多可选项，但是也意味着要照顾很多过时技术，如 mysql 扩展 —— 我们可以升级到 PHP7 来摆脱，但多年来一直不可用。
James:
我当然同意这个观点，这虽然看起来模糊其词，而且我很喜欢这个例子：“过时的，更受欢迎的技术”。这也很好突了 Node一个很大的优点 —— 它原生支持 JSON。JSON 或许是 web 中最重要的数据传输格式了，同时也是最新的 NoSQL 数据库的通用结构。JavaScript 程序中使用 JSON 是非常容易的，意味着当你使用 Node 工作时，数据可以非常简洁地进行传输，不用进行格式转换了。你可以只使用一种语法（JSON 格式）传递在浏览器、服务器和数据库之间。
第七轮：主机和部署
第七轮会看看将新应用部署到 Web 服务器是否容易，在 Craig 看来，PHP 在这方面明显是赢家
Bruno:
Bruno 再一次保持沉默。
James:
这是 Node 需要努力改进的区域。每个提供 Web 主机的公司，都提供了 PHP 和 MySQL。你想看到输出，只需要建立一个以“.php”为扩展名的文件，在< 和 >间写一些有效的代码，上传，用浏览器访问。但同样的方法不适用于Node。当然，Node 主机有很多选项，但是它们需要更多的设置和命令行方式的访问，这对于初学者来说可不愉快。毫无疑问，PHP 在这一轮赢了对手。
第八轮: 性能
第八轮 主要关注速度。虽然这项经常依赖于经验以及开发团队到底多上心，Craig 注意到 Node 在一些方面的优势。
Bruno:
错误比比皆是。首先，该文 有关于性能的详细讨论， 其中排除了开发者经验以及应用类型对性能的影响。假如那篇文章依然无法让你明白抛开上下文谈性能有多愚昧，那来我来谈谈我的观点：
PHP 正在嵌入一个多线程服务器。这使得完全绕过外部服务器成为可能，但暂时还不推荐使用。另外也有一些超快速的的服务器（像 Nginx），他们使得整个启动 PHP、派发请求的过程快到可以忽略。 PHP 的原生异步 (无阻塞 I/O)支持将在 PHP7 中推出，而且多年前 ReactPHP 就实现了类似的模式，因此这一点也毫无意义。 PHP single-request 的生命周期模式是最大的负担。确实，假如你单纯的追求速度，但是这条依然可以很容易绕开，不止可以通过 Memcached 和 Craig 说的类似的方法， 而是通过类似；Ajax 的方法。顺便说一下——服务端 JS 应用默认也是 single-request的。另外——这种 single-request 的生命周期也是一种优势，每次请求重新构建应用，避免了很多内存问题，清空垃圾内存，保持苗条干净。你上次使用一个稳定的长时间运行的的无内存泄露的 Javascript 应用是什么时候，不论前端或后端？关于性能的讨论现在是，而且以后也将是——平局（除非你用的是 Java，那 Java 一定输）
James:
Node 以高性能低延迟的运行时环境而闻名，而且它也找到了属于自己的方式来嵌入部分500强公司的代码栈。由于它的无阻塞 I/O 机制以及 Google Chrome V8 引擎技术，现在 Node 已经成为了“快速”以及“可扩展的”的同义词。 现在网上有很多故事，像Node 如何让公司获取更好的性能提升 以及给开发者提供更高的生产力。我很高兴，这回合 node 胜，但我也理解有人质疑这点。
第九轮: 程序员情结
第九轮来看一看 Craig 觉得一般程序员们对于 PHP 和 Node 有多少感情，最后他认为，Node 获胜了。
Bruno:
你肯定看错地方了，Craig，PHP 社区令人难以自信地热情和活跃，每年有超过 20 个大会和非常精彩的主题讨论。正是这样才完成了 HHVM 的 PHP7。
另外，我想说的是我很好奇 Node 的开发者们在使用哪个版本来工作（v0.12.5 已经开始在写了），即使经过了 6 年的必展。这是不成熟的和危险的（天啊，你使用一个不稳定的技术，你在故意让你的企业挂掉吗），加上一点，它忽略了一些操作系统中的旧 bug，将导致一些重要的开发人员从这个语言的生态系统中离开。
一些负面的经历让我不喜欢 Node，主要是因为 npm。未来或许会改变，但现在每次使用 Node 都觉得恐惧和失望。我们都有自己的喜好，但保持客观，选择正确的工具来工作是很重要的。但同样重要的是要允许别人试错，因为人人都是马后炮。所以不要听 Craig 的，不要听 Jim 的，也不要听我的。大胆去试，看看什么可以用，找些让你感觉不错的来使用，最终，那些让你感觉富有成效的就是最好的，而不是哪些只能节省一些加载时间的。
James:
Node 很火，在 Node 的领域有很多创新，尽管激情是不客观的，但很高兴 Node 赢得了这一局。
第十轮：未来
第十轮着眼于两种语言的前景，基于两种语言在现阶段看起来都有一个前程强劲的未来，Craig 断定这一轮的结果是平局。
Bruno：
Bruno 不得不赶快去写多写一些关于 PHP 的文章，还要维护那让人惊叹的 SitePoint PHP 频道。
James：
James 也等不及要回到他挚爱的 JavaScript 频道，但是他留下了这些观点：
平局对于这一轮来说是公平的。Node 是一颗崛起的明星，但是假如想撼动 PHP 的宝座，他还需要付出巨大的努力。
总的来说，假如锤子是你唯一的工具，那么每个问题看起来都像一颗钉子。Node 并不会完美适配于每一个方案，当然很多时候不使用 Node 也是非常合理的。然而，Node 能做到的，他可以做得非常好。这完全由你自己来做一个明智的决定，去选择一个适合自己项目的最好的工具。
既然 Bruno 和 James 都发表了自己的观点，那么你是怎么看这个问题的呢？
Bruno Skvorc
克罗地亚的程序员Bruno拥有计算机科学，英语和文学三个硕士学位。他是 SitePoint 网站 php 专栏作家，还是 Diffbot.com 的开发布道者. 他避免像瘟疫一样的遗留代码，挑选项目是尽管使用最新技术，他还是一个 treadmill desk enthusiast 和活板玩家，他有一个博客：sometimes blogs.
James Hibbard
我是一个网站开发者，目前居住在阳光明媚的德国北部。我喜欢使用 JavaScript 和 Ruby 编程，你在SitePoint 的 javascript 论坛经常能看到我。不写代码时我喜欢跑步。