2026'da PHP ile uygulama geliştirmek: ekosistemin hali
PHP'nin 2026'daki gerçek durumu: dil olgunluğu, ekosistem sağlığı ve 'öldü' söyleminin neden hâlâ yanlış olduğu.
“PHP öldü” cümlesini ilk duyduğumda galiba 2012 ya da 2013’tü. O günden beri bu cümleyi her yıl yeniden duyuyorum — bazen Node.js’in yükselişiyle birlikte, bazen Python’ın veri bilimi dalgasında, bazen de “modern web” söylemlerinin altında. Aradan on yılı aşkın zaman geçti. PHP hâlâ burada, hâlâ yazılıyor ve hâlâ işler üretiyor.
Bunu bir savunma olarak yazmıyorum. Bir dilin “ölmediğini” kanıtlamak için vakit harcamak verimli değil. Bunun yerine şunu yazmak istiyorum: 2026’da PHP ile uygulama geliştirmek nasıl bir şey ve ekosistem gerçekten nerede duruyor?
Dil artık başka bir dil
PHP 5.x dönemine dair eleştirilerin büyük çoğunluğu hâlâ tekrarlanıyor, ama o dönemden bu yana dilin üstüne birkaç kat daha konum geldi. PHP 8.0 ile gelen union type, match ifadesi ve nullsafe operator sade birer sözdizim şekeri değildi — bunlar dilin tip sistemine yapılan ciddi yatırımlardı. PHP 8.1’deki enum ve readonly property, PHP 8.2’nin readonly class desteği ve PHP 8.4’ün property hook mekanizması art arda geldi.
Bugün PHP’de yazdığım kod, 2014’te yazdığım kodla aynı dil görünümünü taşısa da neredeyse farklı bir şey. Tip güvenliği var, value object’ler temiz yazılabiliyor, enum domain katmanını anlamlı kılıyor. Bunlar küçük eklemeler gibi görünebilir ama uygulama yazarken hissettikleri birikimli bir fark yaratıyor.
<?php
// PHP 8.4 ile property hook kullanımı
class Money
{
public function __construct(
public readonly int $amount,
public readonly string $currency,
) {}
public int $inCents {
get => $this->amount * 100;
}
}
$price = new Money(25, 'TRY');
echo $price->inCents; // 2500
Bu kod PHP’den beklenmedik bir şeydi, değil mi? Ama 2026’da bu olağan PHP.
Ekosistem sağlığı
Composer Packagist’teki paket sayısı 2024’te 400.000’i geçti ve büyümeye devam ediyor. PHP’nin kütüphane ekosistemi, birçok dile kıyasla çok daha olgun ve kullanılabilir durumda.
Framework tarafında Laravel tek lider olmaktan çıkmıyor. Symfony ekosistemi kurumsal çevrelerde güçlü duruyor. Slim ve Lumen gibi mikro seçenekler, Pest gibi test araçları ve çok iyi tasarlanmış paketler mevcut. Livewire ve Inertia.js (tek sayfa uygulamalar için bir köprü katmanı) sayesinde PHP kökenli geliştiriciler, ayrı bir JavaScript uygulaması yazmak zorunda kalmadan modern arayüzler sunabiliyor.
PHP-FPM performansı, RoadRunner (kalıcı süreç PHP çalıştırıcısı) ve Laravel Octane ile birleştiğinde gerçekten rekabetçi seviyelere çıkıyor. “PHP yavaştır” söylemi de artık 2026 için geçerli değil; doğru yapılandırmayla PHP servisleri çok makul iş yüklerini kaldırıyor.
”Öldü” söylemi nereden geliyor
Bu söylemin bir kısmı meşru tarihsel bir eleştiriye dayanıyor: PHP 4-5 dönemi gerçekten dağınıktı. register_globals, tutarsız fonksiyon adlandırması, tip yokluğu — bunlar gerçek sorunlardı. Ama bir dilin geçmişteki sorunlarını bugünkü kararlarınıza taşımak, 2010’dan bu yana değişmeyen bir fotoğrafa bakmak gibi.
Bir kısmı ise ekosistem dinamiklerinden kaynaklanıyor. JavaScript topluluğu gürültülüdür, çok konuşur. PHP topluluğu sessizce iş üretir. Sessiz olan daha az görünür olur; daha az görünür olan “yokmuş gibi” algılanır. Bu bir algı meselesi, gerçeklik meselesi değil.
Hangi problemler için hâlâ doğru seçim
PHP’nin güçlü kaldığı alan bence hâlâ web uygulamaları ve API geliştirmedir. İçerik yönetimi, SaaS ürünleri, monolitik uygulamalar, çok sayfalı uygulamalar — bunlarda PHP ekosistemi hem üretkenlik hem sürdürülebilirlik açısından rekabetçi.
Eğer Go veya Rust gibi düşük seviyeli sistem performansı gerekiyorsa, orada PHP’nin yeri yok. Eğer veri bilimi veya makine öğrenmesi pipeline yazıyorsanız, Python daha uygun. Ama bunlar PHP’nin iddia ettiği alanlar da değil.
Nerede duruyorum
On iki yıldır PHP yazıyorum. Bu süre içinde Go, Python ve TypeScript de öğrendim ve kullandım. Ama PHP bugün hâlâ birincil dilim. Bunun nedeni alışkanlık değil; PHP’nin uygulama geliştirme için sunduğu olgunluk ve ekosistem derinliği, 2026’da hâlâ pratik bir tercih olmasını sağlıyor.
Bir dilin değerini onun hakkında yazılan haber sayısına ya da konferans konuşmalarına göre ölçmek yanlış. Değer, problem çözme kapasitesi ve ekosistem sağlığıyla ölçülür. Bu ölçütle PHP, 2026’da oldukça iyi bir yerde duruyor.
Bu yazının arkasındaki araştırmalar
Laravel'in preload eğrisi: 123 dosya, 1.912 dosyadan sekiz kat fazla kazandırıyor
Laravel için elle seçilmiş bir preload nereye kadar iner, ve her dilim ne kadar açılış bedeline mal olur?
Bulgu
Eğri hacimle orantılı değil. İlk 1.592 dosya (Laravel çekirdeği) 30 ms kazandırıyor ve açılışa 1,2 saniye ekliyor. Sonraki 1.094 Symfony dosyası 9,5 ms kazandırıyor, bedava. Ondan sonraki **123 dosya** (psr, carbon) 15,7 ms kazandırıyor — kendinden önceki 1.094 dosyadan fazla. Ve son 1.912 dosya yalnız 1,8 ms kazandırıp açılışa 1,2 saniye daha yazıyor. Yani önceki kaydın tavan olarak ölçtüğü "hepsini derle", eğrinin başlangıç noktası dışındaki en kötü fiyat/performans bölgesi: 2.809 dosyada durmak 12,77 ms ve 1.514 ms açılış verirken, 4.721 dosya 10,96 ms için 2.691 ms istiyor.
25 gün önce ölçüldü
opcache preload deploy faturasını on dört kata kadar siliyor — ama yedi framework'ün beşi onu size vermiyor
`opcache.preload` açıkken yedi PHP framework'ünün deploy sonrası ilk isteği ne kadar sürüyor, bu kazanç neye mal oluyor, ve kimler ona erişebiliyor?
Bulgu
Preload, soğuk ilk isteği 3,5 ile 14,2 kat arasında kısaltıyor: Symfony 35,58 ms'den 2,50 ms'ye, yani Phalcon'un çıplak seviyesine iniyor. Ama yedi adayın yalnız ikisi (Symfony, CodeIgniter) resmî bir preload dosyası yayınlıyor; kalan beşinde kazanç masada duruyor ve kullanıcının kendi yazmasını bekliyor. Yazmak da göründüğü kadar kolay değil: classmap'ten körlemesine üretilen preload Symfony'yi hiç ayağa kaldırmıyor, CodeIgniter'da ise elle seçilmiş resmî dosyadan (3,13 ms) daha kötü sonuç veriyor (5,29 ms). Ve bedel kaybolmuyor: Laravel'in classmap preload'ı ziyaretçiden aldığı 62 ms'yi php-fpm'in ayağa kalkışına 2.340 ms olarak yazıyor.
25 gün önce ölçüldü
PHP ekosistemi yeni sürümü beklemiyor — ama desteklediğini de söylemiyor
Bir PHP sürümü çıktıktan sonra en çok kurulan 500 Composer paketi onu desteklediğini ne zaman beyan ediyor, ve o beyan ne kadar bilgi taşıyor?
Bulgu
Kurulumların %43,5'i üst sınırı hiç yazmayan bir kısıtla geliyor — `symfony/console` bugün `>=8.4.1` diyor, yani PHP 12'yi de desteklediğini iddia ediyor. Üst sınır yazan 280 paketin 247'si taahhüdünü sürüm daha doğmadan vermiş: `guzzlehttp/guzzle` 8.4'ü Ekim 2020'de, dört yıl önceden kapsamış. Geriye gerçekten bekleyen 33 paket kalıyor, medyanları 325 gün. Ham sayılar sürümden sürüme düşüp 'ekosistem hızlanıyor' diye okunuyor; eşit gözlem penceresinde bakınca trend tersine dönüyor (238 → 215 → 325 gün).
25 gün önce doğrulandı
Bir PHP framework'ünü kurmanın sabit maliyeti: disk boyutu hiçbir şey söylemiyor
Yedi PHP framework'ü kurulduğunda diskte kaç megabayt, istek başına kaç dosya ve ilk istekte kaç milisaniye tutuyor — ve bu sayılardan hangisi gerçekten yük altındaki hızı öngörüyor?
Bulgu
Disk boyutu hiçbir şey öngörmüyor: Yii2 en büyük vendor'a sahip (34,1 MB) ama istek başına yalnız 62 dosya yüklüyor — sahanın en azlarından. İstek başına dosya sayısı da öngörmüyor: CodeIgniter 96 dosya yükleyip 6.431 istek/sn veriyor, Symfony 224 dosya yükleyip 13.067 veriyor. Gerçekten ayrışan tek şey opcache soğukken ödenen ilk istek: Phalcon 2,2 ms, Laravel 72,2 ms — otuz üç kat. Bu, her deploy'dan sonra ilk ziyaretçinin ödediği derleme faturasıdır ve framework başına birkaç kilobayt değil, onlarca milisaniye tutuyor.
27 gün önce ölçüldü
Yedi PHP framework'ü aynı yükte ölçtüm: fark, istek gerçek iş yaptıkça küçülüyor
Aynı donanımda, aynı PHP sürümünde ve aynı yedi rotayla, Laravel, Symfony, CodeIgniter, Yii2, Phalcon, Laminas ve Slim saniyede kaç isteği ne gecikmeyle karşılıyor?
Bulgu
Boş bir rotada en hızlı ile en yavaş arasında 4,4 kat var (Slim 25.975, Laravel 5.966 istek/sn). Ama istek gerçek iş yapmaya başlayınca fark kapanıyor: veritabanından tek satır çeken bir istekte 3,7 kata, yirmi satır çekende 3,5 kata iniyor. Phalcon boş rotada üçüncüyken veritabanı isteğinde beşinciye düşüyor — C eklentisi olmak, sorgu beklerken bir işe yaramıyor. Asıl pahalı olan şey framework seçimi değil: Laravel'in kendi varsayılan web middleware grubu, aynı yanıtı 5.858'den 2.176 istek/sn'ye düşürüyor — yani tek bir varsayılan, framework'ler arasındaki farkın çoğundan daha pahalı.
27 gün önce ölçüldü
Bu konudaki deneyler
Framework'e bağlanmadan çalışan modüler PHP kütüphaneleri; 39 paketlik InitPHP ekosistemine ve Framework3'e dönüştü.
Şu an ne yapıyor
39 paketlik bir PHP kütüphane ailesi: Router, Database, Cache, Mailer, Socket ve diğerleri hem tek başına hem birlikte çalışıyor, hepsi Composer/Packagist üzerinden MIT lisansıyla dağıtılıyor. Framework'e bağlanmadan parça kullanmak isteyen PHP geliştiricisi bugün kurabilir.
Yorumlar
Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.