作者 ｜ Italo Baeza Cabrera
译者 ｜ 张健欣
策划 ｜ Tina
对于一门古老的语言来说，支撑未来技术的东西不是与时俱进吗？
差不多一年前，我发布了一篇题为“PHP 可能在未来十年消失”的文章。我发布的这篇文章的总结就像一首《圣诞颂歌》，但不是 Ebenezer Scrooge（电影《圣诞颂歌》中的一个商人角色），而是 PHP：
- 过去，PHP 没有修复它的问题，所以其它语言变得更有吸引力。
- 现在，PHP 缺乏当前互联网所需的特性。
- 将来，PHP 仍然不会有有意义的特性。
请注意，我从来没有写过“垂死”、“不要用它”，甚至“现在就放弃你的 PHP 项目！”。我只是说它会在 2030 之前的任何时候变得不再有意义，并对此为什么会发生做了的一个简单的解读。
考虑到 PHP 庞大的用户基础，一些指出 PHP 缺点的文章，往往会引爆一些狂热者。他们认为 PHP 是完美的，仅仅因为它很方便，或者因为他们花了 10 多年时间使用 PHP。我的文章也不例外。不管如何，我决定把它从消极的阴云中拉出来，给予更多思考。
1这不是我的问题，而是你的问题
首先说明，我对 PHP 或者任何语言都没有个人恩怨。我认为它是一个非常成熟的工具，当我需要“昨天”的东西时，它也是我最喜欢使用的东西，因为它作为解释型语言非常方便，而且生态系统就在那里。
这也与代码质量无关。你不能因为开发人员没有“正确地”使用一种语言，而责怪它，至少不能全怪。不论你的福特或兰博基尼多么炫酷：如果你不关心它，维护就会很痛苦。
这也与世界上有多少人使用 PHP 无关。如果我们选择“用户基础最高”，那么现在就开始将代码迁移到 Javascript。这场比赛他们轻而易举就赢了，无可匹敌。
先不说“是否被重要公司使用”——稍后再谈。JavaScript 对于 SpaceX 的任务已经非常关键，所以显然它不是一种糟糕的语言，否则宇航员的生命就面临风险。
只是现在，PHP 变成了一个只会玩一种把戏的小马。这门语言以蓬勃发展的 web 开发闻名，但官方不愿采取进一步措施。而其它语言已经在进一步改进了。那是死亡的奥秘。
2语言会“死”吗?
让我们以古老的编程语言之一 COBOL 为例。
几十年前，银行和保险公司背后的一些老的金融系统都是用 COBOL 编程的。世界各地的许多金融机构仍在他们的大型机中使用 COBOL，主要的一个原因是：它仍然工作。这一点的证明是，由于流行病的爆发，COBOL 雇佣人数突然增加，以维持这些来自世界各地的不断受到冲击的古老系统。
COBOL 没有死，但这意味着什么呢？有一些工具可以使基于 COBOL 的软件与当今人们的需求兼容，比如网页，即使这意味着用一个简单的工具将火箭固定在砖块上。仍然有人需要编写和维护 COBOL。甚至有一些公司为基于 COBOL 的系统提供某种支持。
我们可以放心得出结论：编程语言是不可能被消灭的。总有一个混蛋用它来赚钱，还有一个混蛋提供第三方支持来赚更多的钱。这是一种双赢的局面。
在企业文化中，如果你的技术栈没有使公司“损失”任何钱，那就没关系了。否则，你就会像亚马逊因为他们自己的 AWS 数据库而抛弃了甲骨文一样。
3如果它没有死，那怎么“淡出”呢？
COBOL 没有死，它只是“淡出了”：没有一个头脑正常的人会使用 COBOL 启动一个新项目，因为有更好的工具。这些工具拥有更高的性能、更好的可靠性、更方便编程或者有用的特性。在 COBOL 时代，还没有 HTTP 协议、多线程和虚拟化等当今软件所使用的其它有用技术。
当人们不再在新项目中使用一种语言时，多米诺骨牌开始倒塌。针对这种语言的工具不再诞生和维护。由于没有需求，语言不再引入新特性，社区不再创造新的工具集，它不再传播到其它生态系统中——比如 Node.js 出现在服务器端。没有新的程序员学习这门语言，已经学习这门语言的程序员迁移到了“更绿色的牧场”。
这也意味着，公司不愿意投资于语言本身，包括雇佣程序员。与更丰富的语言相比，这变得更难找到这门语言的开发者，因此给这门语言的开发者支付的薪酬也需要更高。此时，迁移到劳动力成本更低的新平台成为公司的一种选择。
COBOL 的情况与 Visual Basic、ASP .Net、Pascal、Fortran、ActionScript、Objective C、Haskell、Ruby 等许多其它服务端语言一样。它们完成了它们的技术周期，更好的语言用更多特性和工具集，或者更少的烦恼，取代了它们，就像 PHP 在 2000 年代中期针对互联网做的那样。一旦 Rust 成为 Linux 内核开发的标准，它也很可能发生在 C 和 C 中。
与其它替代语言相比，PHP 的崛起主要与 Wordpress 的首次出现和 PHP 在服务器领域的易卖性有关。特别是那些需要被编译成二进制的语言，即使这些替代语言有更多的特性或更好的性能，而 PHP 曾经两者都缺乏。正是因为 Wordpress 的崛起，媒体巨头们害怕自己的作品被“一个有博客的家伙”扼杀，于是接受了这一趋势，开始使用 Wordpress 来增强他们的互联网影响力。Wordpress 甚至为这些公司提供了 VIP 模式。
PHP 上的这种“硬锁”现在正在改变，这主要归功于云服务为其它编程语言提供了新平台，但即使到了今天，租到一台运行 PHP 的服务器并在一天内开始使用也不稀奇。事实是，今天也很容易租到一台运行 Node.JS 或 AWS Lambda 的服务器。你不需要多年的培训来使用一家云服务提供商，或者一个服务器服务，甚至谷歌也提供了一个使用谷歌云平台的教程。
尽管如此，PHP 仍然是能够支持网站开发的屈指可数的语言之一。随着越来越多的人参与进来，社区和官方都推出了工具：Opcache 用于 I/O 性能处罚、PDO 用于通用数据库层、Autoloader 用来使大型项目更易管理、Composer 用于依赖部署、PSR 用于标准化代码规范、PHPUnit 用于测试、PECL 用于扩展等等。
所以，回到概念上来，淡出意味着被取代。它的使用量不会增长，而是变得停滞不前。唯一可能发生的事情就是慢慢被其它解决方案取代。这不是发生在一夕之间，而是常年的积累。
从公司的角度来看，改变技术栈需要花费大量的资源，而没有立即的 ROI：迁移到新的技术栈不是没有代价的，更不是一天就完成的。更糟糕的是，有些工具可能不存在，比如分析、调试、甚至部署工具，这些都必须从头开始。
这使得很难说服老板进行“技术栈”迁移。这些老板，不是负责你的人，而是那些投资为了保持利润比上一时期更高的人。除非你能证明有一个新的“商业机会”，旧的技术栈无能为力，或者与其它新技术栈相比会相对性地赔钱，否则通常很难改变已经生效的一些东西。
4锤子是可靠的。射钉枪更好。
结合上下文，看看 W3Tech 对 PHP 的看法，你会发现 PHP 仍然因为被使用地最多而主导着因特网，但不是在 100% 的真实流量上，而是在头部网站上，包括非美国平台。换句话说，如果 Facebook 使用了一个 PHP 脚本，那并不意味着整个平台都是基于 PHP 的——以及会更多地在该公司上。
Wordpress 仍然是事实上被广泛使用的 CMS，与 WooCommerce 一起成为企业的首选。虽然也有 SaaS 提供相同的服务，但可能没有必要修复没有损坏的东西。
由 W3Techs.com 收集的网站使用的服务端编程语言的比例
以上说明：PHP 仍然是任何 web 项目都要考虑的工具。到目前为止，Wordpress 是 PHP 的巅峰之作。仍然有新的网站正在使用 PHP 创建。当 PHP 满足所有的复选框时，一两个人建立一个互联网公司仍然是完全正常的... 直到它不能满足所有条件。
今天有很多 web 技术可以使用：WebRTC、WebSockets、QUIC、HTTP/3、WebAssembly、WebAuthn、渐进式 Web 应用、机器学习、JSON Web 身份验证、gRPC 和服务端事件等等。这些技术支持了在线聊天系统、多媒体流、持续实时数据、新的身份验证机制等等。这些技术，PHP 都很难支持，甚至不可能支持；例如，很难支持流式那样传输大文件而不会阻塞自身，或者不可能支持 WebSockets。
Hack 只是大公司的未来，因为他们一开始就能烧钱运行 HHVM...
因为有很多工作要做，所以从一种语言过渡到多种语言，或者将服务推给向你提供所需功能的公司，比如让 Mux 处理视频平台，让 Pusher 处理事件传播，已经成为一种常态。有人可能说你是花钱图方便，但也有人会说你付钱是因为你的技术栈无法处理这些问题。
另一方面，你可以自己掌控所有东西。前端可以在 PHP 下工作，也可以是一个基于 JavaScript 或像 React、Angular 或 Vue 框架的单页应用（Single Page Application，SPA）。后端可以运行在基于 Rust、Go、F#、HHVM、.Net Core、Node.js 或者别的什么语言的应用上。因为 PHP 不能做所有事情，开发地狱就开始了，一致性会快速丧失。你开始从依赖一个生态系统到依赖非常多生态系统。
PHP 项目与其它 SaaS 或者基于 Node.js、Python、Go 或 Rust 编写的运行时结合在一起就不足为奇，添加另一个要维护的代码库或应用程序。这可能弊大于利，因为你必须为项目的每个部分处理两个（或更多）部署方案。
虽然有少数人能够处理所有事情，但向一个人提供合同的可能性非常小，主要是因为能处理所有事情的人很少，而且也不便宜。
5“但是这个伟大的公司使用 PHP”
我经常听到的一句话是“但是 Facebook 使用 PHP”，好像它是一种蓬勃发展的 Web 技术。以 PHP 起家的顶级公司已经明确表示，Hack 及 HHVM——“现代化 PHP 但消耗内存”——是公司的后续措施：
- Facebook 迁移到 Hack/HHVM 并从 2014 年开始运行。
- Wikipedia 也在 2014 年通过 HHVM 的支持抛弃了 PHP。
- Etsy 也在 2015 年从 PHP 迁移到了 Hack。
- Slack, 被 SalesForce 用 277 亿美元收购，也在 2020 年从 PHP 迁移到了 Hack。
注意，我强调了“企业后续措施”。Hack 就是未来？事实上，Hack 只是大公司的未来，因为他们一开始就有钱运行 HHVM，而且他们不想迁移 90% 的代码。剩下的非百万富翁公司只能使用 PHP 和廉价的服务器。
任何一家拥有大笔资金的公司都可以为自己的利益创造自己的语言，就像 Facebook、Apple、Google 和 Mozilla 那样，因为他们有人、有头脑去做，有服务去实现。无论好坏，我们只是附带的。
拥有一门内在需求稳定的语言可以让它进步，即使有时这意味着做出不太好的决定。
6它足够了，直到它不能
有时候说“你不能在 PHP 上做那件事”有点儿让人难过。新的 JIT 引擎很受欢迎，但它并不是将它与其它新兴语言相结合的灵丹妙药。性能过去是 PHP 的一个非常重要的问题，但现在它不是唯一的问题。互联网在发展，而 PHP 没有。
图片来源：Carl Heyerdahl on Unsplash
如今，网页只是起点。正在发生的 COVID-19 大流行表明，你需要系统针对不同数据类型的不断变化的状态做出反应。如今，PHP 还不够，当它足够的时候——看看最近的发展有多慢——开发人员将拥有更好的工具。没人会等着 PHP 实现自身的现代化，也没有企业会这样做。这就是所谓的进步：新工具取代老工具。
当你需要的不仅仅是显示一个具有基本交互的网页时，问题就出现了。就在那时，PHP 展示了其二十多年的历史，它是如何与当今的技术和产品需求脱节。
我肯定不是唯一一个等了足够时间让 PHP 成为一个像样的技术竞争对手的人。从业务逻辑的角度来看，PHP 非常方便，因为它的语法允许在专家手中非常有表现力的声明操作，特别是在“业务逻辑”部分，但它不是万能的。
PHP 是现在，但不是未来。
我认为这些段落表明 PHP 因为其本质而仍然是王者。没有哪一种语言在提供便利和成熟的同时获得如此大的吸引力，而不是功能——另外，就是 Wordpress 效应。
PHP 如何将被淘汰？每个人只需点击几下就可以创建它们自己的简介、商店、图片库、云存储、群聊等等；无需托管，无需服务器和代码。
我个人认为，现在，由于 SaaS 和一键安装的激增，我们已经超越了像 Wordpress 那样的“杀手级应用”。我们现在处于“杀手级生态系统”，一种语言已经描述了部分，而你带来自己的胶水。也许是 Node.js? 也许是 Go？也许是 Python？也许是 TypeScript 编译为二进制？也许是 Rust 的垃圾收集器？也许是一种全新的语言？
7也许是 PHP 9?
我看到一些人希望对 PHP 进行大的修改。除非 Rogue Wave（Perforce）内部有什么变化来推动 Zend 引擎在技术上向前发展，否则绝对不会。他们很可能是想要卖掉 Zend 服务器。我不认为他们是成功的，当你考虑到大公司尽快离开 PHP 的趋势，并使博客文章对每个人进行嘲讽。
并不是说 PHP 明天就会停止使用：它仍然工作，而且很容易掌握，因为总有一个 MVP 可以开始，它不需要花里胡哨的东西。只不过，PHP 是现在，而不是未来，负责这一点的人其实并不在乎。也许一旦一种新的语言出现，提供 PHP 和其它语言中最好的部分。Hack 刚刚证明了公司级 PHP 有很好的代码重用市场。
一旦下一个大事件席卷互联网，PHP 就来不及赶上了。
没有语言会完全死掉。PHP 没死，只是其它语言已经超越了它。当然，它们不像 PHP 那样经过战斗测试... 但他们正在实现。
当你认为人类对未知事物有固有的恐惧时，就会很容易同情那些被告知尝试另一种工具时的语言狂热者的愤怒。这适用于走出舒适区进入新事物，在本例中，这是从一种可靠的语言（如 PHP）迁移到更适合您需求的其它语言。没有人会因为仅仅“浪费”一周或一个月去学习和了解新的生态系统而死掉。最坏的情况是，你学会了不再去哪里，就像你选错了度假目的地。
通过多年的软件开发解决问题，我认识到，走向（而不是跑向）技术的地平线是工作的一部分，即使这意味着接受我们曾经热爱的东西走向命中注定...
... 未完待续。
作者介绍：
Italo Baeza Cabrera 平面设计师毕业。全栈 Web 开发者。退休的技术和游戏编辑。
原文链接：
PHP “dying” this Decade: One Year After
https://www.infoq.cn/article/hUV9vD24kfRRhzo5tFW1
