11 paź 2025·8 min
Rasmus Lerdorf i PHP: od osobistego narzędzia do fundamentu sieci
Historia Rasmusa Lerdorfa i PHP — jak mały zestaw skryptów webowych stał się powszechną platformą i dlaczego PHP wciąż zasila wiele stron.
Historia Rasmusa Lerdorfa i PHP — jak mały zestaw skryptów webowych stał się powszechną platformą i dlaczego PHP wciąż zasila wiele stron.
PHP nie zaczęło się jako wielka platforma czy starannie zaprojektowany język. Powstało, bo Rasmus Lerdorf chciał rozwiązać konkretny problem: prowadzić własną stronę bez powtarzalnej ręcznej pracy.
To ma znaczenie, bo tłumaczy wiele z tego, jak PHP „się czuje” — nawet dziś.
Lerdorf był deweloperem tworzącym na wczesny web, kiedy strony były głównie statyczne i każda większa zmiana poza prostym HTML-em szybko stawała się uciążliwa. Chciał prostych skryptów do śledzenia odwiedzających, ponownego używania wspólnych części stron i generowania treści dynamicznie.
Innymi słowy: potrzebował narzędzi, które pozwolą mu szybciej wdrażać zmiany.
„Narzędzia osobiste” to nie była marka — to sposób myślenia. Wczesne osoby tworzące strony często pisały małe narzędzia, żeby zautomatyzować nudne rzeczy:
Najwcześniejsze wersje PHP kształtowało takie praktyczne, „zrób to” podejście.
Kiedy znasz korzenie PHP, wiele jego cech staje się logicznych: osadzanie kodu w HTML, bogata biblioteka funkcji skierowanych na typowe zadania webowe i preferencja wygody nad akademicką czystością.
Te wybory pomogły PHP szybko się rozprzestrzenić, ale też wprowadziły kompromisy, o których opowiem dalej.
W tym artykule prześledzimy, jak PHP rozrosło się z zestawu skryptów Lerdorfa do języka napędzanego przez społeczność, dlaczego pasowało do hostingu i stosu LAMP, jak ekosystemy typu WordPress przyspieszyły jego adopcję, oraz co zmieniło się w nowoczesnym PHP (wersje 7 i 8+), żebyś mógł ocenić PHP dziś na podstawie rzeczywistości, a nie nostalgii czy szumu informacyjnego.
W połowie lat 90. web był głównie statycznym HTML-em. Jeśli chciałeś czegoś dynamicznego — obsługi formularza, licznika odwiedzin, personalizacji treści — zwykle sięgało się po CGI, często pisane w Perlu.
To działało, ale nie było płynne.
Programy CGI uruchamiały się jako oddzielne procesy dla każdego żądania. Dla prostych zadań oznaczało to wiele elementów do ogarnięcia: plik skryptu z właściwymi uprawnieniami, konfiguracja serwera i mentalny model, który nie przypominał „pisania strony”. Nie mieszałeś tylko trochę logiki z HTML-em — budowałeś mały program, który wypisywał HTML jako tekst.
Dla hobby stron i małych firm typowe potrzeby były powtarzalne i praktyczne:
Większość ludzi korzystała z hostingu współdzielonego z ograniczonym CPU, pamięcią i małą kontrolą nad ustawieniami serwera. Instalacja własnych modułów czy usług działających w tle nie była realistyczna. Można było wgrywać pliki i uruchamiać proste skrypty.
Te ograniczenia skłaniały do narzędzia, które:
To była luka — między statycznymi stronami a cięższym skryptowaniem — którą PHP miało wypełnić.
Rasmus Lerdorf nie zamierzał wynaleźć języka programowania. Chciał czegoś zwyczajnego: lepszego sposobu na obsługę własnej strony.
Najwcześniejsze prace nad „PHP” zaczęły się od zbioru małych programów w C, których używał do śledzenia odwiedzin na swoim życiorysie online oraz kilku narzędzi pomagających w podstawowych zadaniach serwisu, bez ręcznego edytowania każdej strony.
W tamtych czasach zrozumienie, kto odwiedza stronę (i jak często), nie było trywialne. Skrypty Lerdorfa logowały i podsumowywały żądania, ułatwiając analizę ruchu.
Równocześnie stworzył pomocniki do typowych zadań — prosty system szablonów, drobne fragmenty dynamicznej zawartości i obsługę formularzy — by strona mogła wyglądać „żywo” bez stawania się pełną aplikacją.
Gdy masz narzędzia do śledzenia żądań, obsługi formularzy i ponownego używania komponentów, przypadkowo budujesz coś, czego inni też mogą użyć.
To kluczowy moment: funkcjonalność nie była związana z jednym układem czy stroną. Była na tyle ogólna, że inni właściciele stron mogli wyobrazić sobie jej wykorzystanie u siebie.
Ponieważ zaczęło się to jako skrzynka narzędziowa, ergonomia była praktyczna: zrób powszechną rzecz szybko, nie przeprojektowuj przesadnie i utrzymaj niski próg wejścia.
To podejście — przydatność najpierw, dopracowanie później — sprawiło, że PHP od początku wydawało się przystępne.
Wniosek jest prosty: korzenie PHP nie były akademickie ani teoretyczne. Były napędzane problemami — chodziło o to, żeby prawdziwa strona działała z mniejszym wysiłkiem.
PHP nie zaczęło się jako „język” w sensie, w jakim myślimy o nim dziś. Pierwszym publicznym kamieniem milowym było PHP/FI, czyli „Personal Home Page / Forms Interpreter.”
Ta nazwa dużo mówi: nie próbowało być wszystkim. Miało pomagać w tworzeniu dynamicznych stron i przetwarzaniu formularzy bez pisania pełnych programów dla każdej funkcji.
PHP/FI skomponowało kilka praktycznych idei, które razem znacznie ułatwiły wczesny development webowy:
Nie było to dopracowane, ale zmniejszało ilość kodu klejącego, który trzeba było pisać, by strona zaczęła działać.
Wczesne strony szybko natrafiały na barierę: gdy chciałeś formularz, księgę gości, rejestrację czy proste wyszukiwanie, musiałeś przyjąć dane od użytkownika i coś z nimi zrobić.
PHP/FI uczyniło obsługę formularzy centralnym przypadkiem użycia. Zamiast traktować formularze jako funkcję zaawansowaną, postawiło na nich — ułatwiając odczyt wartości i generowanie odpowiedzi.
To pasowało do potrzeb zwykłych właścicieli stron.
Jednym z najbardziej wpływowych pomysłów PHP/FI był styl szablonów: trzymaj HTML jako główny dokument i wplataj niewielkie fragmenty logiki serwerowej.
<!-- HTML-first, with small dynamic pieces -->
<p>Hello, <?php echo $name; ?>!</p>
Dla projektantów i majsterkowiczów to było naturalne: można edytować stronę i dodać „tyle dynamiki, ile potrzeba”, bez przyjmowania zupełnie innego systemu.
PHP/FI nie było eleganckie i nie próbowało takim być. Ludzie adoptowali je, bo było:
Te „killer features” nie były spektakularne — były dokładnie tym, czego potrzebował wczesny web.
Skrypty Rasmusa były po to, by rozwiązywać jego problemy: śledzić odwiedziny, używać wspólnych fragmentów strony i unikać powtarzalnej pracy.
To, co przekształciło ten mały zestaw narzędzi w „PHP”, jak je dziś rozumiemy, nie była jedna wielka przeróbka — to był stały napływ wkładów od innych deweloperów, którzy chcieli tej samej wygody dla własnych stron.
Gdy PHP trafiło do publicznego obiegu, użytkownicy zaczęli przesyłać poprawki, małe funkcje i pomysły. Ta pętla zwrotna była ważna: projekt zaczął odzwierciedlać potrzeby wielu webmasterów zamiast jednej strony.
Dokumentacja się poprawiała, rzadkie przypadki były łatane, a język zaczynał rozwijać konwencje ułatwiające jego naukę i użycie.
Przełom nastąpił z PHP 3, który przepisał rdzeń i wprowadził nazwę „PHP: Hypertext Preprocessor”. To nie była tylko zmiana marki.
Przepisany rdzeń uczynił język bardziej spójnym i łatwiejszym do rozszerzania, co pozwoliło PHP rosnąć bez stawania się niekontrolowanym zbiorem jednorazowych skryptów.
Szersza społeczność wymusiła integracje z narzędziami, z których korzystali deweloperzy. Pojawiły się rozszerzenia łączące PHP z różnymi bazami danych i usługami — nie byłeś już skazany na jedno podejście.
Zamiast „narzędzia do wypisywania HTML”, PHP stało się praktycznym sposobem tworzenia serwisów opartych na danych — działalności typu księgi gości, fora, katalogi i wczesny e‑commerce.
Kluczowa zmiana: wkłady społeczności nie tylko dodawały funkcje — zmieniały rolę PHP w stronę rozszerzalnej platformy, na którą można było polegać w realnych projektach.
PHP nie stało się domyślnym wyborem tylko dlatego, że było łatwe do nauki. Dużą rolę odegrały poważne ulepszenia „silnika” pod spodem — które uczyniły PHP szybszym, bardziej spójnym i prostszym do rozszerzania.
Zend (założony przez Andiego Gutmansa i Zeeva Suraskiego) wprowadził Zend Engine jako nowy rdzeń PHP. To trochę jak wymiana silnika w samochodzie, ale model auta pozostał ten sam.
Deweloperzy mogli dalej pisać znajomy kod PHP, ale runtime stał się lepiej zorganizowany wewnętrznie.
To miało znaczenie, bo pozwoliło na:
PHP 4 (oparte na Zend Engine 1) pojawiło się w idealnym momencie dla modelu „wypożycz kawałek serwera”.
Dostawcy hostingu mogli oferować PHP szeroko i tanio — i wielu to zrobiło. Ta dostępność stała się pętlą wzrostu: więcej hostów wspierało PHP, więc więcej ludzi go używało; większa baza użytkowników zmuszała hostów do dalszego wsparcia.
W praktyce PHP 4 było „wystarczająco dobre wszędzie”. Ta powszechność była równie istotna jak jakakolwiek cecha języka.
PHP 5 (Zend Engine 2) pchnął PHP w stronę lepszej obsługi większych kodowych baz. Główna zmiana to silniejsze wsparcie OOP: lepsze klasy, reguły widoczności i podstawa do nowocześniejszych wzorców.
Nie chodziło o to, by PHP stało się akademickie — raczej o to, by łatwiej organizować, ponownie używać i utrzymywać aplikacje.
Wraz z rozprzestrzenianiem się PHP pojawiła się presja: ludzie chcieli, by stary kod dalej działał. Hostingodawcy, platformy CMS i agencje polegały na stabilności.
Od tego momentu ewolucja PHP to nie tylko „dodawaj funkcje” — to także „nie psuj internetu”.
PHP nie wygrało, bo było najładniejszym językiem na papierze. Wygrało, bo sprawiało, że budowanie użytecznych stron było natychmiastowe.
Dla wczesnych twórców — często projektantów, hobbystów czy małych firm — PHP skracało czas do pierwszego działającego rozwiązania bardziej niż większość alternatyw.
Z PHP pętla informacji zwrotnej była niemal bez oporów: wgrasz plik, odświeżysz stronę, widzisz rezultat. Brzmi trywialnie, ale to kształtowało pokolenie twórców webu.
Ludzie mogli zacząć od jednej dynamicznej strony (formularz, księga gości, licznik) i rozwijać ją dalej.
Wczesne projekty webowe rzadko miały duże działy inżynieryjne. Zwykle był jeden deweloper, może dwóch, i masa pilnych zadań.
PHP pasowało do tej rzeczywistości: ograniczało ceremoniał wdrożeń i ułatwiało stopniowe zmiany.
PHP płynęło z falą taniego hostingu współdzielonego. Wielu dostawców miało je już zainstalowane, więc nie potrzebowałeś specjalnej infrastruktury czy drogich serwerów.
Wdrożenie często oznaczało „kopiuj pliki”, co pasowało do sposobu publikowania HTML-a.
Wraz z adopcją PHP stało się samonapędzające. Poradniki, fragmenty kodu, fora i przykłady były wszędzie.
Ta pamięć społecznościowa sprawiła, że PHP wydawało się przystępne — nawet gdy problemy webowe nie były trywialne.
PHP nie odniosło sukcesu tylko dlatego, że było łatwe — odniosło dlatego, że miało „dom” na wczesnym webie.
Tym domem był stos LAMP: Linux + Apache + MySQL + PHP. Przez lata ta kombinacja była standardowym przepisem na działające strony, szczególnie dla małych firm i projektów osobistych.
Linux i Apache były powszechne i tanie. PHP pasowało do modelu żądanie‑odpowiedź Apache: odwiedzający trafiał na URL, Apache przekazywał żądanie do PHP, a PHP generowało HTML.
Nie było osobnego serwera aplikacji do zarządzania, co utrzymywało wdrożenia proste i tanie.
MySQL dopełniał obraz. Wbudowane rozszerzenia PHP ułatwiały łączenie z MySQL, wykonywanie zapytań i renderowanie wyników.
Ta ścisła integracja sprawiła, że duży odsetek stron opartych na bazie danych można było zbudować przy użyciu tych samych narzędzi.
Dużym przyspieszaczem był hosting współdzielony. Wielu hostów oferowało konta z domyślnie skonfigurowanym PHP i MySQL — bez konieczności administrowania systemem.
Panel typu cPanel pozwalał utworzyć bazę MySQL, zarządzać tabelami w phpMyAdmin, przesłać pliki przez FTP i szybko ruszyć z projektem.
Pojawiły się też instalatory jednym kliknięciem (często dla WordPressa, forów i koszyków), które spopularyzowały model „strona to aplikacja PHP + baza MySQL”, czyniąc PHP najprostszą drogą dla milionów właścicieli serwisów.
Stos zachęcał do praktycznego przepływu: edytuj plik .php, odśwież przeglądarkę, popraw SQL, powtórz.
Kształtował też znane wzorce — include'y i szablony, obsługa formularzy, sesje i strony CRUD — tworząc wspólny model mentalny, który przetrwał długo po szczycie popularności LAMP.
PHP nie stało się „wszechobecne” tylko przez składnię. Stało się domyślnym wyborem, bo wokół niego powstały kompletne produkty — narzędzia rozwiązujące realne problemy biznesowe przy minimalnej konfiguracji.
Systemy zarządzania treścią sprawiły, że PHP stało się wyborem jednym kliknięciem. Platformy takie jak WordPress, Drupal i Joomla skupiały trudne elementy — panele administracyjne, logowania, uprawnienia, motywy, wtyczki — więc właściciel mógł publikować strony bez pisania kodu.
Każde z tych rozwiązań tworzyło własną grawitację: projektanci uczyli się tworzyć motywy, agencje budowały powtarzalne oferty, a rynki wtyczek rosły.
Gdy strona klienta zależała od takiego ekosystemu, PHP był wybierany wielokrotnie — czasem bez świadomości klienta.
Sklepy internetowe i serwisy społecznościowe były wczesnymi potrzebami sieci, a PHP pasowało do realiów hostingu współdzielonego.
Oprogramowanie takie jak Magento (a później WooCommerce na WordPressie) oraz fora typu phpBB dawały gotowe rozwiązania do katalogów, koszyków, kont i moderacji.
Te projekty normalizowały też model instalacji aplikacji, konfiguracji w przeglądarce i rozszerzania modułami — to pomogło PHP utrzymać pozycję.
Nie wszystkie projekty PHP są publicznie widoczne. Wiele zespołów używa go do dashboardów, narzędzi administracyjnych i prostych API łączących płatności, inwentaryzację, CRM czy analitykę.
Te systemy rzadko są zidentyfikowane w skanach „jaki CMS”, ale utrzymują PHP w codziennym użyciu.
Gdy duża część sieci opiera się na kilku masowych produktach (szczególnie WordPress), język pod spodem dziedziczy ich udział w rynku.
Zasięg PHP to w dużej mierze zasięg ekosystemów zbudowanych na nim — nie tylko cechy samego języka.
Sukces PHP zawsze wiązał się z pragmatyzmem — a pragmatyzm często zostawia szorstkie krawędzie.
Wiele krytyk ma korzenie w historii, ale nie wszystkie odzwierciedlają sposób, w jaki PHP jest używane dziś.
Częstą skargą jest niespójność: nazwy funkcji mają różne wzorce, parametry bywają w innej kolejności, a stare API żyje obok nowych.
To efekt szybkiego wzrostu PHP, dodawania funkcji w miarę zmian webu i utrzymywania starszych interfejsów dla milionów działających stron.
PHP dopuszcza też różne style programowania. Możesz pisać proste skrypty „zrób to”, albo bardziej uporządkowany, obiektowy kod.
Krytycy nazywają to „mieszanymi paradygmatami”; zwolennicy — elastycznością. Minusem jest to, że zespoły bez ustalonych standardów mogą mieć nierówną jakość kodu.
„PHP jest niebezpieczne” to uproszczenie. Większość incydentów wynika z błędów aplikacji: ufa się wejściu od użytkownika, buduje zapytania SQL przez konkatenację łańcuchów, źle konfiguruje upload plików lub zapomina o kontrolach dostępu.
Historyczne domyślne ustawienia PHP nie zawsze prowadziły początkujących w stronę bezpiecznych wzorców, a łatwość użycia sprawiła, że wiele początkujących wdrażało kod publicznie.
Dokładniejsze stwierdzenie: PHP ułatwia budowanie aplikacji webowych, a aplikacje webowe są łatwe do zepsucia bez podstawowej higieny bezpieczeństwa.
PHP wziął na siebie dużą odpowiedzialność: nie psuć internetu.
Ta kompatybilność pozwala długowiecznym aplikacjom działać przez lata, ale też powoduje, że stary kod pozostaje w użyciu — czasem znacznie poza terminem przydatności. Firmy częściej utrzymują stare wzorce niż przechodzą na nowe.
Słuszna krytyka: niespójność, stare API i nierówne bazy kodu są realne.
Niesłuszna krytyka: zakładanie, że współczesne projekty PHP muszą wyglądać jak z początku lat 2000 albo że język sam w sobie jest główną słabością bezpieczeństwa.
W praktyce różnica zwykle leży po stronie praktyk zespołu, nie narzędzia.
Reputacja PHP często wiąże się z kodem napisanym lata temu: mieszanie HTML i logiki w jednym pliku, niespójne style i „działa u mnie” podejście do wdrożeń.
PHP 7 i 8+ nie tylko dodały funkcje — przesunęły ekosystem w stronę czystszego, szybszego i bardziej utrzymywalnego kodu.
PHP 7 przyniosło duże przyspieszenie przez przeprojektowanie kluczowych elementów wewnętrznych (aktualizacja Zend Engine).
Prościej: ta sama aplikacja obsługiwała więcej żądań na tym samym sprzęcie lub kosztowała mniej przy tym samym ruchu.
To miało znaczenie dla hostingu współdzielonego, obciążonych stron WordPress i każdej działalności, która mierzyła czas ładowania w utraconych sprzedażach. Sprawiło też, że PHP znów stało się konkurencyjne wobec nowszych opcji serwerowych.
PHP 8 wprowadziło funkcje, które ułatwiają pracę z dużymi projektami:
int|string). To zmniejsza niepewność i poprawia wsparcie narzędzi.Współczesne projekty PHP zwykle korzystają z Composer, standardowego menedżera zależności.
Zamiast kopiować biblioteki ręcznie, zespoły deklarują zależności, instalują przewidywalne wersje i korzystają z autoloadingu. Dzięki temu współczesne PHP jest dużo „bardziej profesjonalne” niż era kopiuj-wklej.
Stare PHP często oznaczało skrypty ad hoc; nowoczesne PHP to zazwyczaj wersjonowane zależności, frameworki, typowany kod, testy automatyczne i wydajność, która sprawdza się przy realnym ruchu.
PHP nie jest wyborem z nostalgia — to praktyczne narzędzie, które wciąż dobrze pasuje do wielu zadań webowych.
Kluczem jest dopasowanie go do ograniczeń, nie do ideologii.
PHP błyszczy gdy budujesz lub utrzymujesz:
Jeśli twoje korzyści to „wielu deweloperów zna to już i hosting jest powszechny”, PHP może obniżyć tarcie.
Rozważ alternatywy, jeśli potrzebujesz:
Warto też wybrać inny stos, gdy budujesz zupełnie nowy produkt i chcesz mocnych domyślnych decyzji architektonicznych (typowane API, strukturalne serwisy, wyraźny podział odpowiedzialności).
Zadaj sobie te pytania:
Jedna lekcja z historii PHP jest ponadczasowa: zwycięskie narzędzia skracają dystans między pomysłem a działającym oprogramowaniem.
Jeśli oceniasz, czy inwestować dalej w PHP, czy zbudować nową usługę obok (np. frontend React z API w Go), szybki prototyp może rozwiązać wiele wątpliwości. Platformy takie jak Koder.ai są stworzone do podejścia „ship-first”: opisujesz aplikację na czacie, generujesz działający projekt (React + Go z PostgreSQL), iterujesz z trybem planowania, migawkami i rollbackiem — a potem eksportujesz kod, gdy jesteś gotowy.
Dla praktycznych przewodników zobacz teksty oznaczone: /blog. Jeśli porównujesz opcje wdrożenia lub usług, sprawdź: /pricing.
Rasmus Lerdorf stworzył zestaw małych narzędzi w C, żeby utrzymywać swoją stronę osobistą — śledzić odwiedziny, ponownie wykorzystywać części stron i obsługiwać proste dynamiczne treści.
Ponieważ celem było usunięcie powtarzalnych zadań (a nie zaprojektowanie „idealnego” języka), PHP od początku miał praktyczne podejście: szybkie wdrożenie, łatwe osadzanie w HTML i biblioteka przydatnych funkcji webowych.
W połowie lat 90. większość stron była statyczna. Cokolwiek dynamicznego — formularze, liczniki, treści dostosowane do użytkownika — zwykle robiono przez CGI (często w Perlu).
To działało, ale było niewygodne: zamiast edytować stronę HTML z małą logiką, trzeba było pisać program, który wypisywał HTML jako tekst.
Programy CGI zazwyczaj uruchamiały się jako osobne procesy dla każdego żądania i wymagały dodatkowej konfiguracji (praw plików, ustawień serwera) oraz innego podejścia do myślenia o stronie.
PHP sprawił, że dynamiczny wynik był bliski „edycji strony”: piszesz HTML, dodajesz krótkie fragmenty po stronie serwera, wgrywasz i odświeżasz stronę.
PHP/FI oznaczało „Personal Home Page / Forms Interpreter”. Była to wczesna publiczna wersja skupiona na tworzeniu dynamicznych stron i przetwarzaniu formularzy.
Kluczową ideą było osadzanie kodu po stronie serwera bezpośrednio w stronach oraz dostarczenie wygód dla typowych zadań webowych (zwłaszcza obsługi formularzy i podstawowego dostępu do bazy danych).
Obniżyło to barierę dla osób niebędących programistami: HTML pozostał głównym dokumentem, a do niego wplatano małe fragmenty logiki (np. wypisanie zmiennej czy iteracja po wynikach).
Takie podejście pasowało do pracy na współdzielonym hostingu — krok po kroku, bez konieczności natychmiastowego przyjmowania oddzielnego systemu szablonów.
Gdy PHP stało się publiczne, inni deweloperzy zaczęli przesyłać poprawki, małe funkcje i pomysły.
To sprawiło, że projekt zaczął odzwierciedlać potrzeby wielu webmasterów zamiast jednej osoby — dokumentacja się poprawiła, znalezione błędy łapano, a język zaczął wypracowywać konwencje ułatwiające użycie.
PHP 3 był dużym przepisaniem rdzenia i wprowadził nazwę „PHP: Hypertext Preprocessor”. To nie była tylko marka — zmiana uczyniła język bardziej spójnym i łatwiejszym do rozszerzania.
To moment, w którym PHP zaczął się bardziej zachowywać jak stabilna platforma niż zbiór jednorazowych skryptów.
Silnik Zend (opracowany przez Andiego Gutmansa i Zeeva Suraskiego) poprawił wewnętrzne działanie PHP — lepsza struktura, większa wydajność i prostsza droga do rozszerzeń.
Dzięki temu hostingodawcy mogli szerzej i taniej oferować PHP, a zespoły mogły tworzyć większe projekty z przewidywalnym zachowaniem.
LAMP (Linux, Apache, MySQL, PHP) stał się standardowym zestawem dla dynamicznych stron, szczególnie na współdzielonym hostingu.
PHP dobrze współgrało z Apache i MySQL, co sprawiło, że budowanie stron z bazą danych było proste i tanie — dzięki temu miliony serwisów przyjęły to rozwiązanie.
Współczesne PHP (7 i 8+) przyniosło duże przyspieszenie i funkcje ułatwiające utrzymanie kodu, a Composer ustandaryzował zarządzanie zależnościami.
Przy decyzji weź pod uwagę:
Jeśli rozbudowujesz istniejący system PHP, modernizacja krok po kroku często kosztuje mniej niż przepisywanie całości.