PHP Jet vs Laravel

Úvod

V první řadě chci říct, že nemám rád to čemu se dnes říká „hejtování“ – tedy kritizování jen pro kritizování. Je důležité se navzájem respektovat a v rámci tohoto respektu jako správný technici diskutovat o problémech. To je běžná část technické práce a lidského pokroku. Bez konfrontace nápadů, úhlů pohledů a argumentů(!!!) by lidstvo stále sedělo v jeskyni – asi už u ohně, ale v jeskyni. Diskuze je potřebná součást pokroku, stejně tak jako přinášení vlastních zkušeností, nápadů a novinek na trh. Tedy hurá do této diskuze, ovšem s veškerým respektem k obrovské práci, kterou autoři frameworků jako je Laravel a dalších zmíněných projektů udělali. Ano, nejde jen o Laravel, ale o všechny frameworky s podobnou architekturou, filozofií a zaměřením.

Na konci článku pak najdete přímé porovnání realizace konkrétního úkolu v Laravelu a v PHP Jet s tím, že v PHP Jet je z této ukázkové miniaplikace vytvořeno něco reálněji použitelného.

Rozdílná filozofie a architektura

Začneme úplným základem, od kterého se vše odvíjí. PHP Jet má na rozdíl od Laravelu a jiných podobně koncipovaných frameworků jinou filozofii. Autoři Laravelu (a podobných) se z nějakého důvodu rozhodli nad PHP vytvořit poměrně masivní ekosystém – nadstavbu, která si řeší spoustu věcí po svém. PHP Jet je naopak dělaný tak, že si vystačí se standardním PHP a standardním webserverem a standardními principy objektově orientovaného programování (s návrhovými vzory). Nic víc není třeba. Žádné externí nástroje, žádné extra vědomosti, žádné extra nastavení. 

To je pro mne velice důležité. Například je pro mne nemyslitelné řešit to, že framework (aplikace na něm postavené) není možné standardně a naprosto triviálně provozovat na běžném rozšířeném hostingu. Proč bych něco takového měl vůbec řešit? To je jeden z mnoho a mnoha rysů, které přináší konkrétní důsledky na efektivitu (respektive efektivity – jak procesní při vývoji aplikace, jejím provozu, ale i vlastní technickou efektivitu aplikace) a k těmto důsledkům a rozdílům se dostanu v tomto článku, případně v dalších článcích v budoucnosti.

Mé uvažování je takové, že autoři PHP odvedli a odvádějí skvělou práci, oni tvoří základ ekosystému. A pochopitelně i autoři web serverů a databází. Ale zůstaňme u PHP. Nevidím žádný důvod proč bych měl nad tím vytvářet něco složitého, nějakou mezivrstvu. PHP se kdysi tak masivně prosadilo díky své geniální jednoduchosti. A jednoduchost je dobrá – není na ní nic špatného. Platí zlaté pravidlo: To nejjednodušší řešení je obvykle to správné řešení. Nechme stranou to, že v dřevních dobách bylo „normální“ díky této jednoduchosti až moc špagetové aplikace. To nebyla chyba nástroje, ale nás co jej používáme. Prostě: jednoduchost je dobrá věc. Ne subjektivně, ale objektivně (k tomu se dostanem). A PHP Jet maximálně zachovává jednoduchost. Jet je ve své podstatě velice jednoduchý. PHP Jet nevytváří žádnou další (nestandardní) nadstavbu nad PHP. Pro jeho pochopení (naučení se) postačí znalost PHP a objektově orientovaného programování. Nebo pokud jste frontenďák spolupracující na projektu, tak bohatě stačí znalost PHP a základní informace o tom, kde se máte pohybovat (kde jsou view a proč tam jsou).

Druhým silným rysem Laravelu (a podobných) je fakt, že vývojáře vedou tím směrem, kterým uvažují autoři frameworku, ale běda jak potřebujete (z objektivních důvodů) řešit věci trochu jinak. Dobře to u jednoho drinku v našem oblíbeném baru vystihl můj kamarád Honza, který má v jeho firmě s takovými věcmi opravdu mnoho zkušeností: „Je fajn, že na řadu věci najdeš nějaký řešení … Ale běda jak chceš něco udělat jinak než to autoři zamýšleli. To je pak goooglení jak to a to obejít“. Ostatně Honza zdaleka není jediný kdo to říká. A to je pro mne opět opravdu nemyslitelné. Svět sám o sobě je tak rozmanité místo, že to lidský mozek nedokáže stoprocentně pobrat. A taková je i naše práce. Nelze diktovat jeden způsob jak něco dělat. Při vší úctě to mi připadá i trochu pyšné myslet si, že ta „má cesta je správná“. Ano, určitá cesta – určité řešení může být správné a dobré pro určitou situaci, ale nikdy nepostihne vše. PHP Jet jsem proto navrhl tak, aby nediktoval jednu cestu. Jet nabízí řešení, nástroje a možnosti, ale nic nediktuje. Ve světě PHP Jet je možné zvolit mnoho cest a pokud nenajdete tu objektivně nejlepší, tak Jet nabízí možnost si vytvořit cestu svojí, ale zároveň zachovat celkovou jednotnou koncepci a elementární řád. Základní pravidla platí pro strojařinu, stavebnictví, ale i software. Ale pouze základní principy mohou být to co určuje směr. A těmi základními pravidlu jsou obecná a obecně platná pravidla vývoje SW. Nikoliv nutnost používat další nástroje a postupy.

Když už mě napadla ta stavařina, tak to použiji na jednoduché přirovnání. Laravel (a spol) je něco pro stavbu panelákových sídlišť. Jasně, nějak z toho poskládáte barák. Má to své plusy (může být relativně rychle hotovo) i mínusy (např. místnosti budou vždy „nudle“ určené délkou panelů). PHP Jet je navržený tak, aby s ním bylo možné postavit cokoliv. Bez limitů. PHP Jet nenabízí žádné „prefabrikované panely“ ale dejme tomu kvalitní stavební stroje, nářadí a přípravky a trochu toho know-how od kterého je možné se odpíchnout. A pokud správně pochopíte tuto filozofii, tak můžete to „cokoliv“ postavit i mnohem rychleji než ten „panelák“.

Ostatně, koukněte se na ukázkovou aplikaci v balíčku ve kterém je Jet distribuování. Je patrné, že instalátor je vytvořen a funguje jinak, než Jet Studio, to je úplně jiné než administrace a ta je zase jiná než web určený pro návštěvníky. Ale vše používá OOP a jeho návrhové vzory, všude je přítomná MVC filozofie, vše má svůj jednotný řád a pořádek a i když jsou použity různé přístupy, tak vše tvoří jeden společně fungující celek. A ty různé přístupy nejsou použity pouze pro demonstraci toho jak rozmanitě lze k aplikaci postavené na PHP Jet přistupovat, ale hlavně z toho důvodu, že různé typy online aplikací je prostě vhodné (ne-li nutné) vyvíjet různě, protože je to tak efektivnější. Už jsem si půjčil stavařinu, tak teď si půjčím strojařinu. Prostě a jednoduše jinak budete navrhovat formuli, jinak rodinný kombík, jinak kamion a jinak dumper do kamenolomu. Vše jsou to auta, vše má kola, vše má nějaké základní obecně platné principy platné pro storjařinu, ale jsou to prostě různé věci a různé cesty.

Závislosti? Děkuji, raději nezávislost!

Jo, jo … Composer. A také pejsek a kočička, co pekli dort. Ne, nemám nic proti balíčkům a závislostem. Ostatně jako uživatel Linuxu už to používám desítky let a je to super. Ale je to super pro mne jako pro koncového uživatele (i když řekněme pokročilého uživatele).

Ovšem ve vývoji online aplikací se mi celý ten koncept nelíbí. A hned řeknu proč. Ale nejprve praktický příklad.

Jako příklad použiji ukázkovou implementaci API jedné nejmenované banky. To při implementaci stáhnu a dle instrukcí pustím composer. Ten chvíli něco dělá a pak mám najednou na disku dalších 33MB zrojáků. 33 mega! 33 mega na něco tak jednoduchého jako je napojení na platební bránu. Komplet Jet včetně všech nástrojů a celé ukázkové aplikace má 22MB. Mimochodem reálná implementace onoho napojení té platební brány má 16KB.

Ovšem já potřebuji hlavně a zároveň pouze ukázku napojení API, nebo ještě lépe opravdu dobře navrženou nezávislou třídu do které si mohu sám vložit takové závislosti jaké potřebuji. Nechci aby to sebou tahalo celý cizorodý ekosystém. (Jak ideálně navrhovat takové nezávislé obecné třídy ukážu v budoucnu v dalším článku). Jasně, pokud někdo používá daný ekosystém, dejme tomu. Ale stejně se bude muset prokousat k podstatě věci. Ale i tak … Jako člověk pro kterého je napojování „něčeho někam“ denní chleba je věc jako například Guzzle spíš na obtíž. Jak stále píšu a říkám: svět je neuvěřitelně rozmanitý. Na světě jsou bambiliony různých API a i když třeba patří do kategorie REST, tak se liší zdánlivě drobnými, ale podstatnými detaily. A mohou to být věci velice exotické, na které si prostě musíte udělat klienta sami. Nelze je všechny nastrkat do jednoho mustru. Z praxe vím, že je mnohem efektivnější místo věcí jako je Guzzle použít starý dobrý CURL přímo a pár desítek řádků kódu s tím, že naprosto přesně a dokonale vidím (a nejen já) co to doopravdy dělá. Bez jakékoliv magie, bez přehnané (a v tomto případě zcela zbytečné) abstrakce. Mimochodem vědět naprosto přesně co co dělá je také nosná myšlenka.

Ale pojďme od tohoto příkladu. Dejme tomu, že svůj projekt takto „zkomponujete“. Tak nějak to funguje – dejme tomu. Ale váš ekosystém se změní, potřebujete jej aktualizovat – dejme tomu, že opravdu musíte. Pustíte aktualizaci a ejhle … Jedna z těch věcí ještě není připravena. Nebo dvě, tři … A teď babo raď.

Jasně že v mých projektech používám knihovny / třídy třetích stran. Opravdu se nechci plácat s věcmi jako je čtení a generování XLSX souborů, PDF, případně s tvourbou vlastního klienta na ne zrovna masovou službu když už je ten klient k dispozici. Od toho knihovny jsou. Ale když už knihovnu přebírám do projektu, přebírám za ní i odpovědnost. A je v praxi zcela běžné, že původní autor knihovnu / třídy opustí. Nebo se rozhodne vše zcela radikálně změnit. Co pak? Předělat projekt? Možná, ale někdy (vlastně často) může být daleko efektivnější prostě převzít nad knihovnu správu a udržovat jí v rámci svého projektu. Záleží co vyjde levněji – co je efektivnější. Každopádně aby bylo možné nad cizím kódem převzít garance vůči klientovi pro kterého SW/projekt vytváříme, musí tento kód být co nejmenší, bez závislostí, má dělat to co má dělat a to co má dělat má dělat dobře. Linuxáci tuto filozofii moc dobře znají. Nic víc, nic míň.

A celá ta filozofie že se to nějak poslepuje jde přímo proti tomu. Myšlenka určitě perfektní. Ale v reálu tím celý svět a všechny situace co v něm existují nepokryjete. V určitém typu projektů to určitě může mít opodstatnění. Ale pro mne je to spíš pro zlost. Se vší úctou k monumentální práci, která za tím vším je. Já z objektivních důvodů ocením a především potřebuji nezávislost, jednoduchost a jednoznačnost. A (zdánlivě paradoxně) díky těmto vlastnostem pak snáze vzniká cokoliv komplexního. 

Jet nepotřebuje žádný ekosystém. Jet je nezávislý a podporuje nezávislost. V Jet aplikací lze integrovat cokoliv, ale vždy je to plně pod vaší kontrolou. Naprosto o všem rozhodujete vy. Proč? Protože nelze nést odpovědnost bez toho, aniž by člověk měl pod kontrolou to za co odpovědnost má. Tedy to z čeho se aplikace bude skládat, jaké knihovny použije, v jakém rozsahu a jak přesně budou integrovány a kdy a jak budou aktualizovány – to vše musí řešit ten, kdo ve finále nese kůži na trh a za projekt ručí.

A ano. Pro někoho může být snadnější věci nějak poslepovat. Při vší úctě … Vývojář má mít vše pod kontrolou. Vlastně ne „má mít“, ale musí. A musí vědět co přesně aplikaci dělá, proč to dělá a jak to dělá. Ano, s různou mírou znalosti detailu, ale vždy s obecným přehledem o situaci a chování apliakce. Ostatně programátor (hlavně ten kterému se dnes říká honosně backend developer) by měl vědět kdo to byl George Bool a John von Neumann. Vývojář by měl vědět co to je ALU, registr a jak se adresuje paměť a je úplně jedno že pracuje s PHP, nebo Javou a ne nutně starým dobrým čistým C. Vývojář by měl řešit co jeho aplikace přesně dělá a proč to dělá a tomu se má věnovat primárně. A (nejen) dnes moderní přístup, že se aplikace „poslepuje“ co prostě „nějak“ funguje jde proti tomu. Ano, někde ten přístup může fungovat. Ale jen do určité míry a dříve či později (s růstem projektu) to přinese nepříjemnosti. A tím se dostáváme k dalšímu bodu.

Technická stránka věci

Do teď jsem tu teoretizoval o obecné architektuře software. Což je teda podle mého názoru základ, ale vás určitě zajímají konkrétní technické aspekty. Ale ony jsou to spojené nádoby … Tak pojďme se na to mrknout.

Stále opakuji, že je důležité vědět, co aplikace vlastně dělá. V našem oboru je to opravdu extrémně důležité. Tak se pojďme podívat co dělá Laravel a co dělá PHP Jet a to s úplně jednoduchou statickou informační stránkou. Jak se na to kouknout? Existuje úplně super věc XHProf. Pokud se nepletu, tak tento profiler původně vznikl v dílnách Facebook a je to velice užitečný nástroj, který velice rád používám a který je integrovaný v profileru, který je součástí PHP Jetu. Znáte? Pokud ne, tak vězte, že je tento perfektní nástroj umí vygenerovat graf volání. Je vidět co v rámci aplikaci bylo voláno, odkud a kolikrát. Hned na první pohled je možné vidět co aplikace „prováděla“.

Nainstaloval jsem si nejnovější Laravel, integroval do něj jednoduše XHProf a nechal si vygenerovat úplně jednoduchou statickou stránku. Co celý ten ekosystém (již po zahřátí cache atd) kvůli tak jednoduché operaci prováděl? Toto: (račte si rozkliknout na plnou velikost)

Je vidět opravdu velké množství volání, velké množství nahrávaných tříd a tak dále.

A teď to samé Jet: (opět si račte rozkliknout – obrázek je zmenšený a nevystihuje naprosto extrémní rozdíl)

A pozor! PHP Jetu zde dokonce dost křivdím! Cca třetina volání by v grafu vlastně vůbec neměla být. Graf je vygenerován v situaci, kdy je aktivní interní profiler Jetu, který hlídá běhové bloky a je tedy zaznamenána i jeho činnost.

Napadne vás: „No a co? Jde přece o statickou stránku!“ Omyl. Právě úplně jednoduchá situace ukazuje celkovou architekturu systému. A architektura Laravelu a jemu podobných frameworků je přehnaně a neoprávněně složitá. Naopak s rostoucí velikostí projektu se ten rozdíl v neprospěch Laravelu bude více a více prohlubovat! (Pochopitelně i v závislosti na schopnostech vývojářů koncové aplikace). Už to je pro mne důvod tuto technologii zcela diskvalifikovat pro mé projekty. To že je Laravel (a nejen on) pomalý, toho je plný internet. Ale důležité je proč to tak je. Je to díky samotnému návrhu systému. Díky tomu, že tyto druhy frameworků řeší jednoduché věci složitě a nad čisté PHP přidávají spoustu balastu. Jeden můj vážený kolega to před lety pospal vtipně takto: „Proč jíst polévku lžící, když mi na dvoře parkuje bagr!“ Velice přesné a vtipné přirovnání. A také se mi líbí to o tom rovnáku na ohýbák …

Jasně, bylo by možné napsat celou knihu a rozebírat jednotlivé technické aspekty. Ano, ale k čemu? Základní aspekt je totiž už ve filozofii a návrhu systému. Ale OK, třeba se v budoucnu k problematice vrátím v dalším článku (či článcích) a porovnáme si více zcela konkrétních věcí a aspektů. Ovšem základ je opravdu v odlišné filozofii. 

Manažerská stránka věci

A také finanční … Framewrok jako je Laravel a jemu podobné sebou přináší vlastní ekosystém a spoustu vlastních věcí a „nadstaveb“, které se musí vývojář naučit. Ve skutečnosti se tak úplně neučí PHP, jako konkrétní framework a jeho fígle.

Ale to je přesně to co já z manažerského pohledu nechci. PHP je extrémně rozšířená a standardní technologie. Objektově orientované programování a návrhové vzory jsou standardní věc, která se běžně učí na školách. Oboje je dostatečně silné a mocné. PHP má kontinuální a standardní a předvídatelný, dobře zvládnutý vývoj. Je to technologie, která evolučně zraje a lze ze na ni spolehnout. OOP je něco co je univerzální způsob myšlení pouze s různou mírou aplikovatelnosti dle vlastností daného jazyka. Ale myšlení je stejné ať je to PHP, Java, C++, nebo C# (a JavaScript sem fakt netahejte prosím … To opravdu ne …)

To znamená, že potřebuji něco co bude primárně využívat vlastností PHP a OOP a nebude zbytečně vymýšlet kolo a budovat další ekosystém. Protože ten ekosystém například omezuje okruh lidí, které mohu k projektu přizvat. PHP Jet je navržený tak, že se dá snadno vysvětlit, dá se snadno říct: Franto, tady je modul X.Y.Z a potřebuji tam poladit to a to. Pokud je pomyslný Franta frontenďák, tak mu stačí znalost jeho řemesla (a respekt před nimi – dobrý frontenďák toho musí umět hodně tak jako tak) a znalost PHP a prostě nepotřebuji aby se kolega či kolegyně učil něco dalšího – navíc něco, co není tak široce standardní jako PHP samotné. A pokud je Franta backenďák, tak si spolu můžeme sednout a můžeme debatovat o návrhu datového modelu, s tím si třeba formou prototypování hrát, můžeme se bavit o uspořádání modulů, o rozhraní uvnitř aplikace, o použití vhodných přístupů na vhodných místech. Prostě můžeme řešit návrh architektury rozsáhlé aplikace a to bez limitu. Bez ohledu na nějaký ekosystém nějakého frameworku, protože Jet žádnou cestu nezavírá, ale mnoho cest nabízí a ty co nenabízí teď lze vytvořit. 

Ano, PHP Jet je také nutné pochopit. Je také nutné se něco naučit. Ale věřte, že to opravdu není nic složitého. A hlavně není to nic nestandardního, nejsou tam žádná kouzla a čáry. Vše je maximálně přímočaré, transparentní. Celý Jet se opravdu nesnaží dělat žádnou nadstavbu nad PHP. Ale při tom všem se Jet maximálně snaží zbavit vývojáře toho co je otravné a co dělá stále dokola. Ovšem způsobem, který má vývojář plně pod kontrolou.

V konečném důsledku se lidé pracující na projektu soustředí na to na co mají – na to aby uživatelům a zákazníkovi dodali to co chce a potřebuje. Tým který dobře ovládá PHP, OOP a pochopí Jet bude mít komplexní projekt vyvinutý rychleji než tým pracující třeba s právě Laravelem.  Na projektu bude méně jalových hodin a tak dále.

Manažerský pohled ještě jednou – stabilita projektu a evoluce

Myšlenkami se na chvíli vrátím o mnoho let zpět v čase, do doby kdy jsem nadšeně sahal po Zend frameworku ještě v řadě 1. Někde jsem tenkrát četl článek o tom, jaké to bude boží a že budou držet zpětnou kompatibilitu a že bude probíhat evoluční vývoj. Říkal jsem si: Jo! To je přesně to co do firmy chci! To pro firmu potřebuji!

Ona to totiž není legrace, když dáte velké prostředky (čas a peníze) třeba do vývoje nějakého produktu a to na čem je ten produkt / projekt postavený se živelně mění. To se těm co sedí na penězích opravdu špatně vysvětluje … 

Zend tenkrát byl úzce propojený s JS frameworkem Dojo / Dijit. Ten sliboval to samé. O to mé nadšení bylo větší. A pak jednoho „krásného“ dne bum! Vše bylo jinak … 

Laravel a podobné framwroky postrádají kontinuální vývoj. 

Co tím myslím? Pro mne je perfektní ukázkou postupné evoluce to jak se vyvíjí samotné PHP. Já jsem fakt pamětník. Začal jsem na verzi 3, která neměla ani sessions! A z toho se postupně stala verze 8.x, která už se mi opravdu líbí a je stále lepší. PHP se postupně značně pretransformovalo, ale byl a je to řízený a dlouhodobý proces. A je to tak naprosto v pořádku.

Já pro komerční praxi nechci nic, co mi může jednou za X měsíců přinést problémy. Nechci nic, co se mi pod rukami najednou změní, protože někdo prostě řekl „změníme to a basta“. Mé klienty to totiž nezajímá. Oni se ptají, co jim to přinese. Když vydají X peněz, tak za to chtějí výsledek a ideálně X*3 peněz zpět. To klienty zajímá.

A to je také důvod, proč pouštím Jet do světa až v momentě, kdy jsem si jistý, že se ráno nevzbudím a nebudu chtít nic překopat a kdy jsem plně odhodlaný dále postupovat evolučně po vzoru PHP samotného.

Mě samotnému živelnost komplikuje život. A co mě … Firmy prostě potřebujou stabilitu a kontinuální evoluci.

Ano, je nutné hledat úplně nové cesty a experimentovat. To je v pořádku. Ale nazvěme to například primárním výzkumem. A ten patří třeba na univerzity, do projektů které jsou k experimentování přímo určené, ale ne do komerční praxe. A v tom například (nejen) Laravel zrovna nevyniká. 

Závěr – konečně přímé porovnání!

A teď konečně asi to nejzajímavější. Pojďme si ukázat práci s Laravelem a s PHP Jet pěkně vedle sebe.

Nejprve se koukněte na video, kde jeden zahraniční kolega vyvíjí TODO list na Laravelu:

A teď to samé v mém podání na PHP Jet:

Jak vidíte, PHP Jet je mnohem více čisté PHP a přes to se dá udělat totéž rychleji.

Krom toho zde předváděný TODO list rozhodně nepovažuji za samostatnou aplikaci, ale spíš jednu z komponent nějakého projektu a hlavně vytvořený výsledek není tak úplně reálně použitelný … Pojďme z toho tedy vytvořit něco reálnějšího a zajímavějšího:

PS:

Chtěl bych poděkovat těm, kteří si již Jet vyzkoušeli a také mi nahlásili chyby odhalené díky tomu, že se Jet dostal mimo můj mikrokosmos. Moc si toho vážím.

A velice si vážím i reakcí, které jsem našem v e-mailu. Jsem si jistý, že tak jako uvažuji já uvažuje i řada z vás. Určitě ne všichni, ale už teď vidím, že Jet si postupně „své lidi“ najde.

Vážím si vaší podpory. A tímto vás zvu k tomuto projektu. Byl bych rád, aby se postupně z Jetu stal ne „můj“ framework, ale náš framework. Práce je opravdu hodně a ocením každého, kdo se bude chtít aktivně podílet na tomto open source projektu a to jakkoliv.

Jo a prosím o trpělivost. Toto momentálně není komerční aktivita a já pochopitelně, jako každý z nás, musím primárně platit účty a primárně jsem táta – to je to nejdůležitější v životě. 

A také musím přiznat, že i když za sebou mám opravdu slušnou řadu různých zajímavých projektů, tak open source projekt je pro mne něco nového a některé věci se budu učit za pochodu.

Ale kdo chce, pojďme do toho společně! PHP Jet se dostal na veřejné světlo světa teprve „včera“, tak bude zajímavé kam by bylo možné jej dotáhnout „zítra“.

Kdo chce, tak mě prosím kontaktujte primárně na e-mailu. To je můj pracovní nástroj a tam reaguji pravidelně a nejrychleji. Rád vám odpovím na vaše dotazy, rád vám poradím a budu rád za nahlášení každé nesrovnalosti, na kterou narazíte. Chyby můžete hlásit i na GitHub projektu. Předem díky!

Bonus …

Jako bonus přidávám video s názory samotného otce PHP. Teda nemyslím si že „all suck“, ale chápu o čem pan Lerdorf mluví…