ぶっちゃけどうなのPHP

ぶっちゃけどうなのPHP

Honestly, What's the Deal with PHP?

pixiv Inc.

USAMI Kenta

1 2025-11-08 #phpcon_fuk

PHPカンファレンス福岡2025

お前誰よ

• うさみけんた (@tadsan) / Zonu.EXE / にゃんだーすわん

• ピクシブ株式会社 Platform Div > WebTechnology Team PHPer

• 2012年末から現職、APIとかCIとかいろいろなところを見つめてきました

• 最近チームが再編されてインフラっぽい仕事もしてます

• Emacs PHP Modeを開発しています (2017年-)

• プログラミング言語にちょっとこだわりのある素人 (spcamp2010)

2

今回のお題

3

<?php

4

PHP… ぶっちゃけどう思う？

5

おぼろげながら浮かんできたんです

C#… ASP.NET…

Node.js…

Rust…

Go… Common Lisp…

Python… Java…

TypeScript…

Ruby on Rails…

Smalltalk…

Kotlin… Swift…

6

いろいろな選択肢が

あるのに我々は

PHPにしがみつくのか

7

個人的には楽しい

言語をいろいろ

選んできた

8

俺 vs プログラミング言語

• 2005-2009: PHS(携帯電話)でぽちぽちHTMLとJSを書いてた

• 2010: 札幌でRubyコミュニティに出入りしてた

• この頃からプログラミング言語論とか言語処理系に興味を持つ

• 2011: 札幌でPython勉強会に参加したり、F#を教わる

• 2012: 東京に引っ越してRubyKaigi, Shibuya.rbなどに出入り

• 2016-: PHP系のカンファレンス発表、Emacsのイベント運営

9

仕事では12年くらい

登壇は9年くらい

10

プログラミング言語と

Webとフレームワーク

にこだわりのある人間

11

アジェンダ

•前PHP時代 〜 Rasmusは何を革命したのか

• Webフレームワークの中世期断絶

• PHPが往かなかったWebフレームワークの世界線

• 非同期I/OとWeb

12

話は

1993年に

さかのぼる

13

出典: フリー百科事典『ウィキペディア（Wikipedia）』より引用

14 https://ja.wikipedia.org/wiki/ラスマス・ラードフ 2021-07-01T14:10:55版

出典: 伝説のPHP作者「Rasmus Lerdorf」名言集を聞くと嫌PHP厨がファビョる

15 https://web.archive.org/web/20100501140915/http://anond.hatelabo.jp/20100427231539

出典:伝説の喫煙者「黒木 灰次郎」名言集を聞くと嫌煙がファビョる

16 http://blog.livedoor.jp/hokanisurukotoha/archives/1121714.html

出典: ウィキクォート https://ja.wikiquote.org/wiki/ラスマス・ラードフ

17

PHPは多くの人から疎まれ、

まじめなプログラミング言語として

考察対象とされていない節がある

18

出典: IT Conversations | Rasmus Lerdorf | PHP on Hormones

19 https://web.archive.org/web/20130729204354/http://itc.conversationsnetwork.org/shows/detail3298.html

Rasmus LerdorfはMySQLとPostgreSQLの両方に

導入されているSQL標準(ANSI92 SQL)を無視した

mSQLのLIMIT句のオリジナル作者です

出典: IT Conversations | Rasmus Lerdorf | PHP on Hormones

20 https://web.archive.org/web/20130729204354/http://itc.conversationsnetwork.org/shows/detail3298.html

21

22

23

24

CGIとは何か

• Common Gateway Interfaceの略、1993年頃に登場

• HTTPサーバを独自実装しなくても、シンプルなスクリプトを書くだけで

動的ページを実現できる

• ユーザーからリクエストが来る度にプロセスを起動する

• シェアードナッシング (並行して処理するリクエストと干渉しない)

25

CGIとプログラミング言語

• 仕様上、標準入出力(stdio)と環境変数が使える言語ならなんでもいい

• 開発の利便性などから、Perlスクリプトが普及した

• 文字列処理のしやすさ、正規表現、cgi-lib.pl、言語としての書き心地…

• C言語での文字列処理は本質的に難しい

• ラスマスが重要視したのはそこではなかった

• パフォーマンス、HTMLとSQLとの統合…

26

27

Rasmusは何をしたか (〜1995年くらい)

• パフォーマンスのため、C言語でCGIを書いた

• 自分で書いたCGIツールに「PHP」という名前をつけた

• CGIをやめ、Apache HTTP Serverのモジュール化した

• ソースコードごとフリーソフトウェアとして公開した

• Perl, Apacheなどの先例はあるが、「オープンソース」ブーム前

28

1993年時点で存在したデータベースソフトウェア。

フリーソフトウェアではないがソースコードが

公開されていて、MySQLなどに影響を及ぼした。

29

30

31

32

33

34

35

36

37

38

39

40

Q. つまりPHPって

何だったの？

41

A. 異常に行動力があるRasmus

さんが自分のためにPHPを作っ

て、何回か書き直した後に利己的

な動機でソースコード公開したら

世界的に開発が盛り上がっちゃった

42

43

PHPはWebに何をもたらしたか

• HTMLテンプレート (HTML内に制御構造や変数展開)

• JSP(Java), eRuby/ERBなどのHTMLテンプレートに影響

• それ以前は print "<div>Hello</div>"; のようなコード

• CGIの代替としてのサーバーモジュール組み込みと開発者体験

• 現代ではコンパイルが必要な言語でも「ホットリロード」が普及

• フリーソフトウェアとして公開された言語(の先行事例のひとつ)

44

第2部

Webフレームワークの

中世期断絶

45

あるいは

幼年期の終わり

46

コードを書くと

何らかの単位で

抽象化したくなる

47

コードが増えると

バグも増える

48

コードが減れば

バグも減る

49

ライブラリ化

フレームワーク化

レイヤー化

50

ライブラリ化

• 処理を関数やクラスの形でまとめて呼び出せるようにする

• ある人曰く「PHPの関数の数は、人間がWebでやりたいことの数」であると

• 完全に同意するわけではないが、本質の一面を捉えていると思う

• PHPの関数は外付けのライブラリに留まらず、HTTPをネイティブサポート

• これは良し悪しあるが、セキュリティに関しては単なるCGIライブラリでは実

現できないレベルでヘッダインジェクションの対策ができる

51

フレームワーク化

• ライブラリとの最も明確な違いは「制御の反転」

• あなたはコードを書いてライブラリ関数を呼び出す

• フレームワークはあなたの書いたコードを呼び出す

• どのような規則でコードを実行するかはフレームワークの性質による

• Webフレームワークはユーザーのリクエストによって対象を起動

• テストフレームワークはディレクトリやファイル名によって対象を起動

52

レイヤー化

•処理を「層(レイヤー)」に分けて整理する

• これにはさまざまな観点がある：

• MVC (Model-View-Controller)

• 3層アーキテクチャ、Ports and Adapters(クリーンアーキテクチャ)

• HTTPインフラとロジックの分離

53

HTTP層のレイヤー化

• PHPはHTTP機能を言語が直接サポートする(Server API)

• mod_php, php-fpm, cgi, cliなどがあるが、あまり意識の必要がない

• 他言語では従来のCGIスクリプトは廃れて、サーバとアプリケーションを

分離するインターフェイスを定める方向にシフトした

• Python=WSGI, Ruby=Rack, Perl=PSGI

• GoやNode.jsも標準でHTTPサーバをバンドルしている

54

Ruby on Railsの登場

• Webフレームワーク界の風雲児・フルスタックフレームワーク

• CoC (設定より規約)： 重厚な設定が必要なFWのアンチテーゼ

設定を書かなくても慣習通りに配置すれば勝手に呼び出してくれる

• 多数の高機能な組み込みライブラリ:

O/Rマッパー、ルーター/URLヘルパー、

• 積極的なコード生成(スキャフォルディング)：

最初期は「15分でブログを作れる」と宣伝された (2005年)

55

RubyにとってRailsは何を変えたか

•Rails 1.0は独自のHTTPレイヤーで実装されていた

• 現代のRails(Rack)アプリケーションをCGIで実行することは可能だが、

オーバーヘッドが大きい

• CGI時代のRubyスクリプトと、RailsのControllerクラスの実装は

互換性がない

• 「コード書き直し」 or 「捨てる」の二択を迫られる

56

PerlとHTTPレイヤー

• 2000年代まで「WebアプリといえばPerlでCGI」という感じだった

• SNS以前はKENT WEBの掲示板やチャットをレンタルサーバーに置いて

コミュニケーションをとっていた時代もあった

• CGI時代のPerlスクリプトと、業務で開発するPerlアプリケーションの

世界は分たれてしまった…

57

PHP界への余波

• 2004年を画期として、「フレームワーク」というものの見方が変わった

• CakePHPは当時の機能で再現可能な範囲で最大限Railsを模倣している

• ルーティングすら書かなくてもコントローラーが呼ばれる(!)

• GET /users → UserController::index()

• さらに後発のフレームワーク(Laravelなど)は、Rails風の便利さは

残しつつも明示的に設定させることでコードの追いやすさを意識

58

/data/www/www.pixiv.net (document root)

├── index.php

├── novel

│ └── show.php

├── yyy.php

└── zzz.php

59

NovelController#show

# routes.rb

get '/', to: 'index'

get '/n/:id', to: 'novel#show'

get '/u/:id', to: 'user#show'

get '/yyy', to: 'yyy'

get '/zzz', to: 'zzz'

60

PHPにとってのFW

• RailsアプリケーションはControllerを書かないと、そもそも実行されない

• PHPにとってのフレームワークは、便利ライブラリ集と見分けがつかない

• あるいは、お行儀よいアプリケーションを書くための拘束具に過ぎない

• Controllerで setcookie() や header() 関数も動く(!)

• そんなことをするとユニットテストが書けなくなってしまう！

• PHP自体は依然としてCGI時代と地続き

61

PHP以外は

CGI時代との

分断・断絶を経験

62

PHPは

FWが一般化後も

断絶を経験してない

63

ここまでは

過去の栄光

64

PHPは現在も

パフォーマンス改善

されているが、

65

頭にはいろんな言語が浮かぶ

C#… ASP.NET…

Node.js…

Rust…

Go… Common Lisp…

Python… Java…

TypeScript…

Ruby on Rails…

Smalltalk…

Kotlin… Swift…

66

PHPよりもっと

速い言語で書いた方が

いいじゃん

67

PHPより

エレガントな言語で

再構築すべきだ

68

常にさまざまな

誘惑がある

69

70

71

コードをエレガントに

書き直すのは

今やるべきなのか？

72

高速な言語で

書き直すのは

今やるべきなのか？

73

リソース配分

⚖

74

PHPはどこでも

65点を出せる言語

75

…と言いたいが、

PHPにも歯が

立たない局面もある

76

C10K Problem

77

チャットアプリで

結果をリアルタイムに返す

78

WebSocket

Server-Sent Events

79

preforkモデル

(mod̲php, PHP-FPM)は

相性最悪

80

PHPはこのまま

白旗を上げる

しかないのか

81

82

勝った！

PHP大勝利

83

……とは行かない

84

グローバル変数や

静的プロパティが

リセットされない

85

CGIとは何か

• Common Gateway Interfaceの略、1993年頃に登場

• HTTPサーバを独自実装しなくても、シンプルなスクリプトを書くだけで

動的ページを実現できる

• ユーザーからリクエストが来る度にプロセスを起動する

• シェアードナッシング (並行して処理するリクエストと干渉しない)

86

この環境を全部

捨てることになる

87

Notes on Programming in C

ルール2: 計測すべし。計測する

までは速度のための調整をしては

ならない。コードの一部が残りを

圧倒しないのであれば、なおさら

である。

̶ Rob Pike

https://www.lysator.liu.se/c/pikestyle.html

訳語はUNIX哲学 - Wikipediaより引用

(2025年10日2日12:33:03版)

88

問題になっていない

ことを悩んでも

仕方ない

89

本当にPHPに

不得意な仕事をさせる

必要があるのか？

90

本質的な問題を

解決できる

言語を使おう

91