PHP 和 Node.js 的角摔
在最近 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拥有计算机科学，英语和文学三个硕士学位。他是 SitePoint 网站 php 专栏作家，还是 Diffbot.com 的开发布道者. 他避免像瘟疫一样的遗留代码，挑选项目是尽管使用最新技术，他还是一个 treadmill desk enthusiast 和活板玩家，他有一个博客：sometimes blogs.
我是一个网站开发者，目前居住在阳光明媚的德国北部。我喜欢使用 JavaScript 和 Ruby 编程，你在SitePoint 的 javascript 论坛经常能看到我。不写代码时我喜欢跑步。