

Odkąd pracuję w tej branży — a zaczynałem na początku lat dwutysięcznych — mniej więcej co roku ktoś ogłasza śmierć PHP. I co roku po tej uroczystości internet wstaje rano i dalej działa w dużej mierze na PHP: od milionów blogów i sklepów na WordPressie i podobnych silnikach, przez Wikipedię, po systemy, o których nawet nie wiesz, że tam pod spodem jest PHP. Ta rozbieżność między opinią a rzeczywistością jest ciekawa sama w sobie. A dla Ciebie, jeśli masz lub planujesz system webowy, jest wręcz praktycznie ważna — bo od niej zależy, czy ktoś namówi Cię na kosztowne przepisywanie czegoś, co wystarczyło unowocześnić.
Z prawdziwych grzechów młodości. Mała ciekawostka: PHP zaczęło się w połowie lat dziewięćdziesiątych jako prywatny zestaw skryptów Rasmusa Lerdorfa do obsługi jego strony domowej — skrót pochodził pierwotnie od „Personal Home Page". Narzędzie pisane do liczenia odwiedzin własnej witryny przeżyło potem niejedną „poważną" technologię projektowaną przez komitety. Historia lubi takie żarty.
Ale ta domowa geneza miała swoją cenę. PHP przez lata było językiem, w którym każdy mógł coś sklecić — więc każdy klecił. Hosting za grosze, kod wklejany z forów, logika wymieszana z HTML-em w jednym pliku. W efekcie po sieci krąży do dziś ogrom fatalnego kodu PHP i to na jego podstawie język dorobił się opinii niechlujnego. Trochę jak z osiedlem, które ma złą sławę sprzed dwudziestu lat, choć od dawna wygląda zupełnie inaczej.
Do tego dochodzi mechanizm czysto ludzki: programiści lubią nowości i lubią o nich pisać. „Postawiłem kolejny solidny sklep na sprawdzonej technologii" nie jest tytułem, który zbiera kliknięcia. „PHP nie żyje, przechodzimy na modny język X" — owszem. Tyle że mody mijają, a systemy zostają na lata.
Tu dochodzimy do sedna. Mówienie dziś o PHP przez pryzmat wersji sprzed kilkunastu lat to jak ocenianie współczesnych samochodów na podstawie malucha. Współczesne PHP 8 ma porządny system typów, wyłapujący błędy, które kiedyś wychodziły dopiero u użytkownika, i wydajność, która od wersji 7 skoczyła tak mocno, że wiele firm po samej aktualizacji mogło zmniejszyć serwery. Do tego doszły dojrzałe frameworki jak Symfony i Laravel, które narzucają porządną architekturę, oraz Composer — menedżer pakietów, dzięki któremu korzysta się z tysięcy przetestowanych bibliotek zamiast pisać wszystko od zera.
Piszę to wszystko z pozycji praktyka: budujemy i utrzymujemy w PHP duże portale i aplikacje, więc widzimy na co dzień, jak ten język wygląda w nowoczesnym wydaniu. Nudno? Może. Ale w systemach, na których stoi czyjś biznes i pensje pracowników, nuda to najpiękniejszy komplement.
Zauważ, że do tej pory ani razu nie padł argument „bo składnia jest ładniejsza". Celowo — bo z perspektywy właściciela firmy wojenki technologiczne są jałowe. Liczy się kilka przyziemnych rzeczy. Dostępność programistów: specjalistów od PHP jest w Polsce mnóstwo, więc nie jesteś zakładnikiem jednego wykonawcy; gdy współpraca się kończy, kolejny zespół podejmie kod bez egzotycznych poszukiwań. Koszt utrzymania: hosting i administracja dla PHP to najlepiej przetarty szlak w internecie, tani i przewidywalny. Dojrzałość: język ma prawie trzydzieści lat, jego pułapki są znane i opisane, a rozwiązania większości problemów ktoś już przećwiczył.
Egzotyczna technologia potrafi być świetna inżyniersko i jednocześnie fatalna biznesowo — bo za dwa lata trzech programistów, którzy ją znają w Twojej okolicy, będzie pracować gdzie indziej. To nie jest argument przeciw nowościom w ogóle; to argument za tym, żeby technologię dobierać do ryzyka, jakie firma może udźwignąć. Duża korporacja z własnym działem IT może eksperymentować. Firma, której system utrzymuje zewnętrzny zespół, powinna cenić technologie, przy których łatwo o zastępstwo.
Najwięcej „dowodów na śmierć PHP" pochodzi z systemów, które po prostu zostawiono samym sobie. Sklep postawiony dziesięć lat temu na PHP 5.6, nieaktualizowany, bez testów, rozwijany metodą „dopisz tu ifa" przez pięciu kolejnych wykonawców — taki system faktycznie jest wolny, dziurawy i drogi w rozwoju. Ale identyczny los spotyka zaniedbane systemy w każdej technologii. Gdyby te same praktyki zastosować w najmodniejszym języku sezonu, wynik po dekadzie byłby ten sam.
Wniosek jest niewygodny, bo przenosi odpowiedzialność: o system trzeba dbać. Aktualizować wersje na bieżąco, porządkować kod przy okazji zmian, nie odkładać modernizacji w nieskończoność. Zaniedbany kod to dług — a dług obsługiwany po latach kosztuje wielokrotność tego, co regularne raty. Po czym poznać, że Twój system wszedł już w tę strefę? Każda drobna zmiana trwa tygodniami, programiści boją się dotykać niektórych miejsc, a hosting nie chce przedłużyć wsparcia dla Twojej wersji PHP. Znajome? To znak, że pora działać, zanim zdecyduje za Ciebie awaria.
No dobrze — masz starszy system PHP i co dalej? W większości przypadków odpowiedzią jest modernizacja, nie rewolucja: podniesienie wersji PHP, uporządkowanie kodu, czasem przepisanie najgorszych modułów na framework, etapami i bez zatrzymywania działającego biznesu. Tak właśnie prowadzimy takie projekty — opisaliśmy to podejście szerzej w tekście o przepisywaniu starych systemów na najnowsze wersje PHP.
Zmiana technologii ma sens rzadziej i prawie nigdy „z powodu języka". Sensowne powody to raczej: system wymaga architektury, której obecna konstrukcja nie udźwignie, kod jest w stanie, w którym taniej napisać od nowa niż rozplątywać, albo nie sposób już znaleźć ludzi do bardzo starej, niszowej platformy. Decyzję podejmuje się po przejrzeniu kodu i policzeniu obu wariantów, a nie po lekturze rankingu popularności języków.
Masz system PHP i nie wiesz, czy go modernizować, czy odpuścić? Podeślij nam go do wglądu przez formularz kontaktowy — powiemy, w jakim naprawdę jest stanie i który wariant wychodzi taniej w perspektywie kilku lat. Bez wojenki technologicznej, za to z konkretami.
Data publikacji: 26 lipiec 2026 rok, czas aktualizacji: 2026.07.26, rodzaj publikacji: "Ciekawostka".