21 października około 16:00 polskiego czasu świat technologii przypomniał sobie o PHP.
Powód nie należał do przyjemnych.
Pojawiły się awaryjne wydania PHP 8.5.12, 8.4.27, 8.3.36 i 8.2.35, łatające dwie krytyczne podatności umożliwiające zdalne wykonanie kodu bez uwierzytelnienia.
Czyli sytuacja z kategorii:
aktualizujemy teraz, a nie „przy najbliższym oknie serwisowym”.
Internet zareagował w sposób równie przewidywalny:
„PHP jeszcze istnieje?”
„Kto tego używa?”
„Dlaczego ktoś nadal utrzymuje systemy napisane w PHP?”
I właśnie ostatnie pytanie jest najciekawsze.
Bo odpowiedź nie ma wiele wspólnego z sentymentem programistów.
Ma za to bardzo dużo wspólnego z biznesem.
PHP nie jest już PHP 5
Część opinii o PHP zatrzymała się gdzieś kilkanaście lat temu.
PHP kojarzy się z gigantycznym index.php, zapytaniami SQL składanymi ręcznie, globalnymi zmiennymi i projektami, których nikt nie chce otwierać bez rękawic ochronnych.
Takie systemy oczywiście nadal istnieją.
Internet ma bardzo dobrą pamięć.
Ale współczesne PHP to zupełnie inny ekosystem.
PHP 7 przyniosło gruntowną modernizację silnika i ogromny skok wydajności. PHP 8 rozwinęło system typów i język, a frameworki takie jak Laravel czy Symfony pozwalają budować duże, uporządkowane aplikacje z wykorzystaniem współczesnych praktyk programistycznych.
Czy nadal można napisać w PHP koszmarny kod?
Oczywiście.
Można również źle napisać aplikację w Pythonie, Javie, Go albo JavaScripcie.
Język nie zawsze jest winny temu, co programista zrobił z jego pomocą.
Skoro PHP jest martwe, dlaczego nadal jest wszędzie?
Według W3Techs PHP działa obecnie na około 69% stron, dla których możliwe jest określenie języka backendowego.
To ogromna skala.
WordPress.
WooCommerce.
PrestaShop.
Magento.
Systemy szyte na zamówienie.
Panele administracyjne.
Integracje.
Aplikacje budowane przez ostatnie dwie dekady.
Dlatego kiedy pojawia się poważna podatność w PHP, problem nie dotyczy kilku entuzjastów starej technologii.
Dotyczy hostingu, agencji, sklepów internetowych, administratorów i firm na całym świecie.
Paradoksalnie skala zamieszania po takiej aktualizacji najlepiej pokazuje, jak daleko PHP jest od technologicznego cmentarza.
Technologii naprawdę martwych nikt nie aktualizuje w panice.
Najważniejszy argument: biznes nie płaci za modny stack
W branży technologicznej bardzo łatwo powiedzieć:
„przepiszmy system”.
Na Pythona.
Na Go.
Na Node.js.
Na nową architekturę.
Tylko że decyzja technologiczna w działającej firmie wygląda inaczej niż decyzja przy weekendowym projekcie.
Jeżeli system:
- działa,
- jest już opłacony,
- posiada gotowe integracje,
- obsługuje klientów,
- generuje przychód,
- a organizacja wie, jak go utrzymywać,
to jego całkowite przepisanie oznacza ogromny koszt i nowe ryzyko.
Nowa aplikacja oznacza także nowe błędy.
Ponowne odkrywanie edge case’ów.
Odtwarzanie integracji.
Migrację danych.
Testy.
Wdrożenie.
Szkolenia.
I bardzo często po miesiącach albo latach pracy użytkownik otrzymuje dokładnie tę samą funkcję:
„Dodaj do koszyka”.
Technologia nie przynosi wartości dlatego, że jest nowa.
Przynosi ją wtedy, kiedy rozwiązuje problem biznesowy.
Ekosystem też ma wartość
Jedną z największych przewag PHP jest to, co powstało wokół niego.
Potrzebna jest strona z CMS-em?
WordPress.
Sklep?
WooCommerce, PrestaShop czy Magento.
Dedykowana aplikacja?
Laravel albo Symfony i gigantyczny ekosystem gotowych bibliotek.
Płatności, logowanie, poczta, kolejki, API, integracje — większość typowych problemów została już wielokrotnie rozwiązana.
To oznacza krótszy development, niższy koszt wejścia i mniejsze ryzyko.
Nie zawsze trzeba projektować nowy silnik.
Czasami trzeba po prostu zbudować samochód, który dowiezie klienta do celu.
Słoń w składzie porcelany
PHP można porównać do słonia, który trzydzieści lat temu wszedł do składu porcelany.
Na początku wszyscy mogli zastanawiać się:
„co on tutaj robi?”
Tylko że po trzech dekadach sytuacja jest trochę bardziej skomplikowana.
Wokół słonia powstały regały.
Poprowadzono instalacje.
Dobudowano piętra.
Ktoś oparł o niego kawałek konstrukcji.
I dzisiaj nie wiadomo już, czy słoń znajduje się w budynku…
czy może budynek został częściowo zbudowany wokół słonia.
Oczywiście można powiedzieć:
„wyprowadźmy go”.
Można.
Tylko najpierw warto sprawdzić, czy przypadkiem nie trzeba będzie przy okazji rozebrać połowy budynku.
Czy to znaczy, że wszystko należy pisać w PHP?
Nie.
PHP nie jest najlepszym narzędziem do każdego problemu.
Nie ma języka, który nim jest.
Nowe projekty warto oceniać indywidualnie, biorąc pod uwagę wymagania, kompetencje zespołu, skalę, infrastrukturę i przewidywany czas życia systemu.
Ale dokładnie z tego samego powodu nie ma sensu przepisywać działającego rozwiązania tylko dlatego, że technologia przestała być modna.
Modernizacja ma sens wtedy, kiedy rozwiązuje realny problem.
Nie wtedy, kiedy poprawia samopoczucie zespołu developerskiego.
PHP jeszcze długo z nami zostanie
PHP ma trzy rzeczy, których nie można zignorować:
ogromną bazę istniejących systemów, dojrzały ekosystem i bardzo dobrą ekonomię tworzenia typowych aplikacji internetowych.
To nie brzmi równie ekscytująco jak prezentacja nowego frameworka.
Ale biznes często nie potrzebuje ekscytacji.
Potrzebuje narzędzia, które dowiezie.
I właśnie dlatego prognozy śmierci PHP pojawiają się od lat, a słonik nadal spokojnie siedzi na produkcji.
Stary?
Trochę.
Modny?
Niekoniecznie.
Skuteczny?
Zdecydowanie.
A w biznesie to ostatnie pytanie zwykle okazuje się najważniejsze.
