PHP 和 Node.js 的10项对比挑战

在最近 SitePoint 的 PHP vs Node.js Smackdown 一文中,Craig Buckler 对两种语言就如何应对一系列的10个挑战进行了比较来决定哪一个总体上更佳。

Craig 在书中讲到,这些比较总是有些矛盾。作为一个有意思的随访,我们要求 Bruno Škvorc (SitePoint 的 PHP 开发者)和 James Hibbard (SitePoint 的一个 JavaScript 开发者)对每一轮提供评论。

下面是他们详细的看法…

PHP 和 Node.js 的角摔

第一轮:开始

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 论坛经常能看到我。不写代码时我喜欢跑步。