PHP发展记事
2010-09-20 09:28:28 
阿炯
PHP是一种开源的通用计算机脚本语言，尤其适用于网络开发并可嵌入HTML中使用。其语法借鉴吸收了C语言、Java和Perl等流行计算机语言的特点，易于一般程序员学习。主要目标是允许网络开发人员快速编写动态页面，但PHP也被用于其他很多领域。本文收录了一些重要的发展轶事。短短两年使用率下滑 40% 曾经风靡全球的 PHP 为何逐渐失去优势
短短两年使用率下滑 40% 曾经风靡全球的 PHP 为何逐渐失去优势
2024年4月下旬消息，根据 WordPress 联合创始人 Matt Mullenweg 的说法，PHP 的受众比例急剧下降，疑似受到 WordPress“JavaScript 优先”主张的影响。TIOBE 编程语言人气指数发布更新并提出“PHP 的魔力是否正在消散？”的灵魂拷问。2024年4月，PHP 在 TIOBE 编程语言指数榜上仅位列第 17，“成为其有史以来的最低排位”。
暴露 PHP 人气急剧下滑的还不只是 TIOBE 榜单。在年度 Stack Overflow 开发者调查报告中其市场占比也从 2018 年的 30.7%（即受访者当中使用 PHP 的百分比）下降至 2023 年的 18.58%。JetBrains 开发者生态系统调查同样观察到类似的趋势，PHP 占比从 2017 年的 30%下降至 2023 年的 18%。而且最后一项数据尤其值得关注，因为 JetBrains（以及 WordPress 托管厂商 Automattic）正是 PHP 的最大赞助方之一。
JetBrains 公布的开发者调查结果
这种下滑趋势在 BuiltWith 上体现得尤其明显，自 2020 年底以来 PHP 的流行度增长线开始断崖式跌落。
BuiltWith 公布的 PHP 趋势图
截至 2021 年 11 月的一项调查显示，PHP 在互联网前百万个网站中的占比仍在 3 万以上。但如今两年多过去，其占比已经下滑至 1.5 万左右。而且截至202年4月，BuiltWith Quotes 公布的实际占比数字为 18.19%。18%这个比例与 Stack Overflow 及 JetBrains 的调查发现高度吻合，因此可以基本确定，PHP 在开发者中的受欢迎程度已经从之前的约 30%萎缩至现在的 18%。换言之，在短短两年之间下降了 40%。所以结论是什么？在过去几年里到底发生了什么样的变化，才导致 PHP 在 Web 编程语言的竞争当中迅速落败？
WordPress 高调宣布“JavaScript 优化”
可以说，PHP 衰落的最大原因就是 WordPress（迄今为止最具人气的 Web 内容管理系统）正在从 PHP 转向 JavaScript。WordPress 联合创始人兼 Automattic 公司 CEO Matt Mullenweg 在上月于中国台湾召开的 WordCamp Asia 2024 大会上也就此做出论述。
他在回答观众提问时表示，“我觉得 WordPress 中的大部分新代码现在都是由 JavaScript 编写而成，而且这种趋势已经持续了一段时间。因此从方方面面来讲，如今的 Gutenberg 已经转化成了一个 JavaScript 优先的项目。”
大家绝没看错：Matt Mullenweg 直言现在的 WordPress 就是个“JavaScript 优先的项目”。而他所提到的 Gutenberg，其实是该公司备受争议的全新用户界面，同时也是推动 JavaScript 全面替代 PHP 的主要原因。当然他也承认从 PHP 转向 JavaScript“并不容易”。
这倒不是说 WordPress 不再依赖于 PHP。毕竟在撰写本文时，恰好就是在 WordPress 中以“/wp-admin/post-new.php”结尾的 URL 输入这篇文章；但只能说目前如此，未来的 WordPress 已经确定要走向另一条道路。
Mullenweg 还谈到，他希望能在 WordPress 中看到进一步改进——令人惊讶的是，他已经开始从 JavaScript 的视角出发看待这些变化。比如说PHP是一种服务器端脚本语言（意味着代码通常在 Web 服务器上处理），而 Mullenweg 希望 WordPress 能使用 JavaScript 把更多操作交由客户端执行。他意味深长地表示，“我真心觉得我们应该把更多处理任务留在客户端。比如对于正在编辑的内容，这部分处理就可以交给客户端。这种在浏览器运行 JavaScript 的速度可能会更快，因为现在虚拟机和性能极强的处理器已经相当普遍。”
在演讲即将结束之时，有观众向 Mullenweg 询问他对 Gutenberg 项目的感受，以及开发人员为其做出贡献时遭遇到哪些困难。提出这个问题的开发者还希望“降低 Gutenberg 的抽象级别”。Mullenweg 回应称，“说实施，我觉得大家必须适应这种发展态势。我认为 Gutenberg 的开发方式和 JavaScript 优先理念才是大部分 Web 开发工作的未来方向。顺带一提，其实我也得重新学习，这些东西跟我当初熟悉的方式也有区别。也许我们可以把某些抽象调整得更简单一点，但总体而言，我会选择深入研究一下。”
他还补充称，Gutenberg 项目、包括向 JavaScript 语言的转变，目前还远未完成。“在启动 Gutenberg 项目时，我们就知道这可能是个为期 10 年的项目。目前我们才刚刚完成 60%到 70%的工作。”
与此同时，在 PHP 基金会这边……
不得不承认，WordPress 项目（也是 PHP 能够在 Web 领域保持流行的最大动因）正坚定向着 JavaScript 世界迈进。这几乎必然会阻止更多年轻开发者选择 PHP，同时迫使其他开发人员（例如那些致力于服务 WordPress 客户的开发人员）从 PHP 转向 JavaScript。但好消息是，仍然有相当一部分开发者群体会继续使用 PHP——毕竟两轮大规模开发者调查中的这 18%对应着相当体量的从业受众。而 PHP 基金会将继续为他们提供支持。
PHP 基金会于 2021 年 11 月正式成立，希望以非营利组织的身份承担起 PHP 项目的管理职责。PHP 基金会是由 JetBrains 领导的企业联盟所建立，其中包括 Automattic、Zend、Laravel 以及 Acquia（Drupal 的托管商）等。JetBrains 工程师 Roman Pronskiy 则出任项目负责人，目前在基金会网站上的头衔为“运营主管”。
在2024年 2 月的 Laravel 会议上，Pronskiy 主要探讨了技术问题，同时也承认“PHP 基金会目前最艰巨的任务，就是扭转 PHP 在公众心目中的形象。”虽然他没有具体说明是哪些原因导致 PHP 的公众形象下降，但 Matt Mullenweg 在解释 WordPress 转向“JavaScript 优先”的理由时已经基本给出了答案。无论如何，Pronskiy 正快速投身于 PHP 项目的后续开发，并为其组织起由 10 名有偿开发者组成的全职团队。
PHP 基金会团队
总而言之，2024 年的 PHP 几乎成了 Web 开发领域爹不疼、娘不爱的“孤儿”，而 JavaScript 则是在家、在校都备受关注的宠儿。对 PHP 来说更加可悲的是，目前的这种人气下滑趋势短时间内恐怕无法停止——毕竟 WordPress 那边的开发团队还在积极适应新的 JavaScript 规范。但至少 PHP 基金会还在为此而努力，也许这股颓势能够逐渐迎来转机。
协程提案 Fiber 引发激辩
PHP 社区于2021年3月8日发起了将 Fiber RFC 添加到 PHP 的投票。根据 Fiber RFC 中的描述，Fiber 主要用于为异步 I/O 实现协程，提供了独立栈分配、函数调用的暂停和恢复功能，它将作为扩展集成到 PHP 中。按照计划，投票将于3月22日截止，最新数据为 38 票赞同、11 票反对。从目前的结果来看，Fiber RFC 很大可能会通过投票从而被添加到 PHP(获得 2/3 的赞成票即可通过)。当前公开的投票结果显示，两位创始人——PHP 创始人 Rasmus Lerdorf 和 Swoole 创始人韩天峰均投了反对票。
Swoole 是一个 PHP 协程框架，为 PHP 提供协程、高性能网络编程支持，并提供了多种通信协议的网络服务器和客户端模块，可以方便快速地实现 TCP/UDP 服务、高性能 Web、WebSocket 服务、物联网、实时通讯、游戏、微服务等，使 PHP 不再局限于传统的 Web 领域(来自 Swoole 官网介绍)。
Reddit 上的一篇帖子引起了不少讨论，有人认为 Fiber 是 generator 的升级版本，它是协程的最小化核心实现，并且不会对 PHP 产生不利影响，将它集成到 PHP 有利于发展和探索未来的异步生态。也有人质疑其投反对票是因为担心此提案会对 Swoole 的商业化 (Swoole Plus) 造成影响。对于 Fiber RFC 的观点是，建议先作为一个 PECL 扩展，PHP 内核开发者能够思考清楚 PHP 未来协程的整体技术体系和实现方式后再做决定。实际上异步编程颠覆了 PHP 一直以来的设计哲学和编程模式。如果 PHP 语言官方决定要支持像 Node.js、Golang、Swoole 这样的异步/协程并发编程模式，那么就需要系统性思考一下整体的架构，以及完整的实现。
韩继续发表文章(关于 PHP 8.1 的 Fiber RFC)从技术细节详细地解释了自己反对 Fiber RFC 的原因。他认为用户真正需要的是一种完整的、系统性、成体系、简单易用、可靠的一整套技术方案，并根据自己的经验提出可从 7 个方面进行考虑：
EventLoop API
协程(对应 ext-fiber)
IO 调度器(Socket/FileSystem/ChildProcess/Signal/Timer/Stdout/Stdin)
CPU 调度器
现有同步阻塞 IO 扩展(redis、curl、php_stream、sockets、mysqli、pdo_mysql 等)和内置函数(sleep、shell_exec、sleep、gethostbyname 等)如何实现支持协程，变成异步非阻塞模式
协程通信(channel)
服务器：实现 PHP-FPM 协程版，或者提供一个新的协程 HttpServer
虽然他给出了充分的理由投反对票，但从目前看来，许多人并不认可他的做法。他们认为，即便实现 PHP 的协程化难度很大也不需要等到有成熟方案之后才合并，也不能因为 Fiber 不够完善，就猜测它不能满足大多数人的要求。反而因为 Fiber 是最小化实现，集成到 PHP 不会对使用者造成很大的维护负担，却又能满足很多人的项目需求，他们可以在此基础上进行更多实现，为用户开放了探索各种协程方案的可能。因此，这一部分开发者认为没有理由反对将 Fiber RFC 添加到 PHP。双方思考角度不同，所以给出了截然相反的投票结果，而且他们都有各自的立场——虽然初衷都是希望 PHP 变得更好，但无论如何，最后还是以投票结果为准。
关于轻量级高性能的 API 和 MVC 应用服务框架-Swoolefy
Swoolefy是一个基于swoole扩展实现的轻量级高性能的常驻内存型的API和Web应用服务框架，高度封装了http，websocket，udp服务器，以及基于tcp实现可扩展的rpc服务，同时支持composer包方式安装部署项目。swoolefy抽象Event事件处理类，实现与底层的回调的解耦，支持同步|异步调用，内置view、Log、session、mysql、redis、memcached、mongodb等常用组件等。
核心特性
1、轻量级的框架，实现路由与调度，MVC三层，当然也可以配置多层
2、支持composer的PSR-4规范和实现自定义注册命名空间
3、支持多协议，目前支持http，websocket，tcp，udp，以及基于tcp实现的rpc，开放式的系统接口，可自定义协议数据格式
4、抽象Event的事件处理与底层的事件监听解耦，屏蔽不同协议之间的应用差异，大部分代码实现共用
5、实现超全局变量，IOC，静态延迟绑定，组件服务常驻内存化，trait的多路复用，钩子事件，单例，工厂模式等
6、简单易用的异步务管理TaskManager， 定时器管理TickManager， 内存表管理TableManager， 进程管理ProcessManager，超全局管理
7、灵活多层的配置,配置参数即可实现底层已封装的复杂功能
8、应用对象的深度复制，实现对象的常驻内存，每个请求只需要从内存中复制应用对象，不需要再重新创建，减少IO消耗
9、封装View，Log，Mysql，Redis，Mongodb，Swiftmail，Session等常用组件，其他组件根据业务按照约定即可封装成组件
10、实现异步半阻塞与全异步非阻塞，EventHander与底层解耦
11、基于inotify实现自动监控swoole服务的文件变动，实现worker自动reload，智能邮件通知
12、命令行形式高度封装启动|停止控制的脚本，简单命令即可管理整个框架