PHP 可能在未来十年内消失？

犹提过，据 2001 年 7 月的 PHP 非官方文件格式叙述，“PHP 是迄今为止最合适的词汇，没有之一。它加速，十分强悍，而且全然免费。”不过，随着时间的插值，许多开发人员辨认出简而言之世界上最合适的词汇 PHP，虽然能很大地提升操控性，但是其机能不如健全最后引致 PHP 开始走入了上坡路，为此，你怎么看？

PHP 可能在未来十年内消失？

译者 | Italo Baeza翻译者 | 孙薇，白眉林 | 屠敏公司出品 | CSDN（ID：CSDNnews）

下列为译文：

自Wordpress、Drupal、CakePHP、Laravel、Symfony及许多其它的Web插件走入T台以来，人们辨认出词汇流程的建立这般单纯，或许也让词汇出现了这种类似于伊瓦诺革新的征兆。应用软件Web hosting再加之PHP + MySQL + Apache栈，就像Hardoi一般快速扩散，忽然每一人都在五分钟里盖起了自己的中文网站：网志、科季夫、快照之类，一应俱全。

PHP的反对者们乐意致力明显改善尖萼词汇，最后他们获得成功了——僵硬的老版渐渐被代替掉，PHP 7在操控性和机能方面都更佳，PHP 8即使还全力支持JIT发动机。

但我认为，之后PHP会渐渐消亡，即使全然被出局。根据官宣，PHP 8的惟一主要机能就是JIT发动机——在CPU受到限制的情景江苏舜天队提升操控性，但也Chavanges，其它预览显而易见，不能对我们原有或今后的插件产生任何人影响。

操控性不能成为毁灭性的难题，但机能缺少才是难题。

暂时的胜利，最后的失败

在PHP5暴露难题（慢、依赖混乱、机能缺少）的同时，Ruby、Python、Node.JS和Go都开始受到大众关注。Go出现得比较晚，但无论如何，我们可以看到这些词汇的用途：

Websockets

非阻塞IO

Promises实现（即“在我执行其它任务时，完成此项任务”）

更佳的数据流

本地服务器部署

桌面/移动应用的用法

更干净的配置（如php.ini）

软件包管理（后由Composer修复）

这些新机能除了composer，全都不包括在PHP的核心机能中，即使宣传和计划中都不涵盖。基本上，非官方是让PHP社区自行决断要自己做这些机能，还是干脆放弃了事。

你可能会说，这些机能并非各个项目必需的，其可用性要取决于具体情况，这话没错，但要实现上述机能，我们必须要选择是用非非官方的流程包，还是自己做一个。

举个例子，我们看一下WebSockets：必须在Ratchet、Swoole、Amp和React中作出选择。这意味着，针对关键性机能，作为开发人员，我们不但要确保遵守流程包的相关文件格式，保证流程包的可维护性，还要关注PHP的版预览情况，才能保证不出难题。我可以想象，PHP8出现时，要在新版上稳定下来，需要花费数周乃至数月的时间。

Swoole的案例是可以再讨论的。目前开发人员可能不太热衷于使用这个麻烦缠身的软件，尤其是考虑到词汇障碍的难题，但如果想要进一步研究的话，可以点击这里查看开源代码。

虽然近来，人们的关注点有些偏移向词汇本身添加某些helper和命令，但这些helper方法的混乱也是多年来未曾解决的难题：ucfirst(), strtolower(), str_replace()…我们为什么不能在使用统一命名上达成一致？为什么直到今日，仍然没有人能从数组中提取一些键？

回到重点，不要误会我反对使用第三方流程包，但我希望负责PHP本身的人员比随机的公司拥有更多的可维护性。

而且别让我用台式机或者移动应用流程。PHP是一种面向Web的词汇，大多数开发人员都默认这一点，但即便Node.JS被逐出了市场，PHP也不能有希望成为相应生态系统中的替代品。

具体到Node.JS的案例中，很大可能JavaScript编写的部分服务器代码模块是可以重用在之前的移动或桌面应用中的。对公司所有者而言，这意味着公司不必再雇佣另一个有其它词汇经验的开发人员了，除非收益大过成本。

恐怕这就是我们将要面临的局面：

应用一开始用PHP代码库开发；

管理者索要新机能；

某个其它词汇会填充PHP不提供的机能区；

最后开发人员要使用两个生态系统。

同样，每种词汇都有其特色和要警惕的难题，但我始终认为，一种词汇要有功用性，能够让使用者完成自己的任务，而不是让人吃亏——如果不是为了PHP社区的利益，很难设想PHP会达成以上要求。