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.
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.
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.
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.
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.
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á.
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:
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!
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í…
V první řadě díky za seriál - musí to dát hodně práce a pozitivních reakcí se moc očekávat nedá (protože prostě jsme na internetu). Za druhé oceňuju, že většina dnešního článku je text, sledovat videa většinou nestíhám.
A za třetí klobouk dolů, je vidět, že do frameworku šla fakt hromada času a spoustu toho umí. Můj šálek kávy to není (obecně nemám rád generování kódu a ani Laravel se mi moc nelíbí - používám Symfony s vlastní nadstavbou), ale určitě existují lidi, kterým jeho filozofie bude bližší.
Kosmetická poznámka k videu - je hrozně potichu. Musel jsem vytočit hlasitost úplně na maximum, abych něco slyšel.
Faktická poznámka k videu - Jet TODO list nedělá úplně to stejné, v Laravelovém byly tlačítka "Mark as complete" jako formuláře, které odesílaly POST request (což je správně), v Jet jsou to GET odkazy. O kolik by se řešení v Jetu zkomplikovalo, nedokážu posoudit.
Ohledně Composeru nemůžu souhlasit, ale opět je to subjektivní záležitost. Zkuste ale zapřemýšlet, jestli nechcete Jet nabízet i jako Composer balíček. Můžete se zbytečně připravit o uživatele, kteří Composer mají rádi.
Srovnání množství věcí, co dělá při requestu Laravel vs Jet je fajn, ale tvrzení, že "s rostoucí velikostí projektu se ten rozdíl v neprospěch Laravelu bude více a více prohlubovat" podle mě neplatí. Naopak ten overhead na request bude konstantní a u složitější aplikace se víc ztratí.
Každopádně díky a těším se na další díl :-)
Ja jsem si pustil jen ta videa pro TODO list. Modularita vypada skvele. Nevim jestli je k vyvoji potreba to Jet Studio, nebo jak zde bylo zmineno by to slo zabalit do composer balicku + popisu jak ho pouzit. Mne by se to jako composer balicek taky libilo.
...tak uz jsem si to nasel v dokumentaci: Jet není sada nezávislých knihoven ... a je to záměr. Jet je jeden celek. I když ten celek je flexibilní, zcela (nebo určitě do hodně velké míry) ovlivnitelný a přizpůsobivý, ale je navržený jako jeden celek a jedna koncepce.
Jen si dovolím zdůraznit to, že v Jet je vše vyměnitelné.
Například autentizace a autorizace je kontroler + modul. To je v aplikačním prostoru. Tedy když vám nevyhovuje předpřipravená implemetnace, je snadné si to upravit, nebo udělat vlastní (například napojenou na podnikovou doménu) a tak dále.
Rámcově jde o to, že nemusíte pustit composer a rovnou je vše připravené k práci.
Ale zároveň je to celé modulární. Úplně vše je tam modulární. I práce s chybami je modulární. Autentizace a autorizace je modulární a tak dále. A ty jednotlivé stavební kameny můžete modifikovat či vyměňovat a při tom zůstane zachován celek.
Je to vlastně micro service architektura. S tím rozdílem, že mezi micro services není žádné HTTP rozhraní (ani SOAP, ani REST), ale běžné OOP rozhraní.
Ale jak mě napadá, tak přirovnání k micro services je asi nejvýstižnější.
Jet Studio potřebné není. Vše se dá dělat bez něj.
Ale s ním je to opravdu o hodně snadnější a méně otravné.
Díky za perfektní reakci!
Ano, máte pravdu se zvukem. Zápasím s tím. Mám profi mikrofon, extra "zvukovku" a ty tak výsledek nic moc. O této oblasti nic nevím (dělání videí pro YT) - učím se za pochodu :-) Snad se to zlepší a pokud má někdo nějakou radu, díky za to!
Ano, to co píšete o Coposeru je ke zvážení. Taky mi to vrtá hlavou. V tom máte asi pravdu, ještě popřemýšlím. Ale mě jde primárně o ten koncept "nějak něco poskládat" bez znalosti co vlastně. To vnímám jako potenciálně nebezpečný trend ...
Budu se snažit hodně psát, ale pokud si uděláte čas na videa, budu rád. Ve videu toho mohu ukázat víc a názorněji - alespoň se mi to tak osvědčilo vůči koncovým uživatelům našich projektů :-) A na tom zvuku fakt zamakám ...
Díky moc za velice příjemnou reakci!
Mirek
No, já naopak Laravelu holduju (resp. produktům na něm postaveném) a musím s některými závěry nesouhlasit.
Také jsem si kdysi napsal svůj framework, také byl jedinečný a v konkrétních způsobech použití nejpřímočařejší na celém světě, jenže... problémy.
První problém byl, že to nikdo nechtěl (zadávat produkty, které v něm budou vyvíjené), protože jsem ho znal a uměl jen já a každý další by se ho musel učit, což je drahé. Proč investovat peníze do učení jedné specifičnosti, když se jede všude Nette (tehdy).
Druhý problém byl, že i kdyby byl zájem o učení, můj framework nepostihoval všemožné postupy a nástroje, které tvoří ten "balast" nad těmi moderními frameworky (třeba cmd, komplexní asynchronní řešení). Vyhovoval jednomu přístupu, ostatní si dodělej sám. Proč by to někdo dělal, když to jiné frameworky, třebaže je to tíží jako onen balast, nativně umí?
Nakonec jsem po letech (strávených něčím jiným) zjistil, že jsem v zásadě vymyslel kolo a když to srovnám s Laravelem, tak jsem se nelišil v základní filozofii, lišil jsem se jen ve schopnosti pokrýt všemožné potřeby jiných vývojářů, protože toho není jeden člověk schopen, a tedy především v té kritizované komplexnosti. Tady je třeba otázkou - umíte z hlavy napsat správně HTTP response s vrácením souboru? Nebo očekáváte, že právě tohle za vás správně vyřeší onen framework?
A teď k věci. Composer. Dobrý sluha, špatný pán. Umožňuje velice snadno udržet problémy s kompatibilitou (semver), což vám odstraní problémy s migrací pod úrovní major verze (viz vaše kritika na konci). Major verze porušují zpětnou kompatibilitu, to je jejich vlastnost. A týká se to i PHP, viz všechny ty deprecated vlastnosti v každé nové verzi.
Integrace knihoven třetích stran a převzetí odpovědnosti: Ano, měl bych vědět, co a jak to dělá, ale pokud knihovna žije, dostávám současně s ní i její opravy (minor releases, patches), které neničí můj produkt (a kdybych měl podezření, píšu si přece testy;-) ), ale naopak odstraňují chyby, které jsem mohl přehlédnout. A psát si vlastní PDF parser - děkuji, nechci, není čas, nikdo to nezaplatí.
Co se týče závislostí, tak PHP svět (viz Laravel: https://github.com/laravel/framework/blob/9.x/composer.json) není tak hrozný, jako třeba JS svět, kde je to hlavně v případě Nodejs těžce za hranicí přijatelného. Když to srovnám s Denojs nebo Rustem...:-)
Téma řešení problematiky jinou cestou: Od toho ten framework je, že nabízí standardní postupy pro standardní úkoly, ale nic mi přece nebrání si vyklonit v routeru, ale klidně i dřív, nějakou vlastní programovou větev, kterou si vyřeším po svém to, co potřebuju, ne? Stejně jako se můžu vykašlat na celý ten MVC a v routeru rovnou mastit výstup, tak můžu přeskočit i jej a použít z Laravelu jen nějaké vybrané knihovny. Však Laravel sám je jen rozšíření Symfony balíčků, které jsou použity také výběrově, selektivně. Stejně nakonec dospěju k tomu, že mnoho knihoven je tak dobrých, že stojí zato je používat i jen tak, protože řeší standardní úkoly jednodušeji a rychleji, než je datlovat (a znovu objevovat kolo) v PHP.
A k vývoji PHP - já jsem naopak docela zklamán. Deklarativní přístup (anotace) se mi nelíbí, a dost zásadně mi chybí asi nikdy neimplementovaná generika (viz Google a proč PHP nemůže mít generické typy). Ten jazyk má díky své historické rozkročenosti a dynamickému typování tolik skrytých bubáků, kterého drží při zemi, že je těžké z toho vybřednout, byť se o to vývojáří zjevně snaží, za což jim patří velký dík. Bohužel ale neočekávám žádný šílený a progresivní skok, který by hodil celý jazyk o patro výš, třeba přepsat jádro do jiného jazyka, aby se mohlo zapojovat víc a víc vývojářů. Ono to s tím Céčkem do budoucna nevypadá úplně růžově.
Věčná škoda je, že se nechytl Hack lang (https://hacklang.org). Ostatně i to jejich HHVM přepisovali raději do Rustu.
To je len vyhovorka z Golangu :D :D :D
Ako viem, akym PHP preslo vyvojom. Od "naco su nam typy, duck typing je lepsi", cez "naco su nam typy mi si ich napiseme do komentara" az po sucasne type hinty, co je velmi velmi velmi velmi vlazne pouzitie typov.
Osobne si mylsim, ze skutocne typy alebo generika sa do PHP nikdy nedostanu, lebo je to v ostrom rozpore s tym ako sa PHP historicky pouziva. To je jedne z dovodou, preco som ho opustil, no vzdy ked sa k nemu vratim, zistim, ze sa prakticky nic nezmenilo.
Proste ked chcem generika vo webovej , tak siahnem po modernom jazyku, co ich realne aj ma napr. C#, Java.
Samozrejme genrika sa do PHP daju pridat, ale nasledne s toho vznikne nieco tak sialene ako je Typescript, kde polka constraintov a syntaxe je len na to, aby osetrila to co si v tom beztypovom javascriprte vymslia za somarinu.
Když jsem přečetl váš komentář, připomnělo mi to jistou hlášku z mého oblíbeného seriálu, dovolim si ji trochu poupravit:
Používáme oba to samé PHP?
> az po sucasne type hinty, co je velmi velmi velmi velmi vlazne pouzitie typov.
...
> modernom jazyku, co ich realne aj ma napr. C#, Java
?
Teda, mě by jako moderní jazyk, nebo příklad silného užití typů C# fakt nenapadl. Pokud vám přijde tak výrazně "moderní", tak bych vás rád upozornil, že nemáte úplně rozhled.
> Používáme oba to samé PHP?
Ano, PHP pouzivam viac ako 10 rokov, teraz uz menej ale casto sa k nemu vraciam.
> Teda, mě by jako moderní jazyk, nebo příklad silného užití typů C# fakt nenapadl.
Tak ako definujete moderny jazyk?
Ja viem, preco som presiel na C# a aj preco som nepresiel na nejaky iny, hoci som ich skusal mnoho.
A to já nic neříkám, že ten C# používáte. Používejte si, když vám vyhovuje. O tom vůbec není řeč. C# je výborný průmyslový jazyk. Nic chytrého, nic složitého.
Co mě se týče, tak já v práci přepínám mezi C# a PHP, a pro mě v tom není rozdíl. U obou mi toho spoustu schází, ale co bych si stěžoval - dělám v nich pro peníze.
Pokud chci moderní jazyk s moderními typy (a mohu si vybrat), tak šáhnu po Rustu, Haskelu, nebo Scale.
Co su to moderne typy?
Rust (bol som nim nadseny ale to ma po par mesiacoch preslo) neprinasa o moc viac ako C#, popripade veci, ktore idu nahrait pomocou source generatorov.
Díky, odpoledne si to vyzkouším :)
Guzzle "je" (ve většině případů použití) zlo. Přesně to mě napadlo a jsem rád, že je v článku zmíněno zrovna tohle. Opravdu často se setkávám s tím, že lidi kvůli jednoho file_get_contents, případně pár řádků curl_* nainstalujou guzzle (1.3 MB kódu, 160 souborů), přičemž jeho konfigurace a inicializace je delší a složitější kód, než to curl. OMG..
Taky používám cizí knihovny, ovšem použít tak obrovskou knihovnu na jeden wget vyžaduje opravdu mimořádný "talent" :)
Já asi vážně používám jiné php než autor. Tvoříme weby, většinově na php, již téměř 20 let, zažil jsem s php opravdu mnoho a poslední roky jsem víc manažer než klasický vývojář. Jsem podepsán pod mnohými projekty. Některé jsou, myslím, i v top100 českých webů nebo získaly nějaká ocenění. A mám přesně opačné zkušenosti než autor. A když vidím něco jako Jet, tak mám spíše pupínky a zdvižené obočí než souhlasné pokyvování hlavou. Nechci tu apriori hejtit něčí práci, koníček nebo proof of concept. Spíše by mě zajímalo, kolik reálných lidí skutečně řeší problémy, které stojí za vývojem Jetu. A kolik z nich je ochotno je řešit touto cestou.
Ve WebTom 100 jsme se určitě potkali ;-) A neskromně říkám, že řada projektů, kolem kterých jsem se motal to dokonce vyhrála (vodafone, hypoteční banka a další).
Pane kolego, já netvrdím, že mám všeobecnou pravdu. Pouze říkám, že na projektech se kterými jsem se setkal jsem dospěl k tomuto a tomuto.
Že to může být jinde jinak je zcela legitimní a ne že to tak může být, ale ono to tak je. Prostě mé zkušenosti jsou determinované oblastí, kde se pohybuji. Ale to není střed vesmíru ... ;-)
Tak ať se Vám daří. Třeba se někdy potkáme osobně a zkušenosti si vyměníme.
dle mne se na to da koukat i tak. ze proste programatoru je malo a proto framweorky a ruzne knihovny resi jednoduse to co by se musel programator ucit slozite.
Proste ta krivka klesa, a je jednoduchsi a rychlejsi napsat par init veci a mate guzle se kterym umi makat kazdy podprumerni programator nez chtit po nem neco co by mu trvalo spoustu casu se naucit curl a vsechny veci s tim souvisejici.
Sam i kdyz php programator mne v posledne dobe nadchl prave jednoduchosti golang.
Jinak mne prijde ze programatori sou jako vcelari(sam sem vcelar) a to co programator tak jinej nazor jina zkusenost a jinej pristup...
Pozastavil bych se u toho composeru.
Myslím si, že autor tento nástroj zle pochopil.
Jeden příklad za všechny: pokud mi guzzle vadí, tak si vytvořím vlastní odlehčené řešení (sám jsem to tak použil). A to dám jako balíček. Nikdo mě přece nenutí používat balíčky, které mi nepřijdou optimální.
Composer slouží k řešení situace, kdy máte desítky aplikací, a v každé chcete mít nějakou, klidně vlastní, knihovnu. Pomůže vám v tom, že v každém okamžiku budete vědět, v jakém stavu ta knihovna je. Tedy, nestane se vám, že v jedné aplikaci máte tu knihovnu patchnutou tak, v druhé jinak, ve třetí vůbec.
Composer řeší situaci, když pracujeme v týmu, a kolega dostane za úkol udělat über optimální a odlehčenou implementaci něčeho, a mě pak řekne, až bude mít hotovo. Nebudu si složitě stahovat jeho repo v nějaké verzi, a řešit jak requirovat jeho knihovny - protože toto je již standardizované.
Z tohoto důvodu jsou námitky autora bohužel liché.
Napadlo me to same. Composer je jen nastroj, pomoci ktereho je mozne udrzovat verze balicku (at uz cizich, tak vlastnich) v projektu, taky mi prisel pomerne nestastny priklad platebni brany ci guzzle, protoze to skutecne neni problem composeru, ale toho konkretniho balicku.
A ono to prece neplati jen pro balicky tretich stran, ale i pro framework jako takovy. Pokud bych se rozhodl Jet na svem projektu pouzit, tak predpokladam, ze se bude take casem vyvijet, budou se opravovat chyby, vydavat novejsi verze kompatibilni s novou verzi PHP, atd. Casem proste bude potreba udelat aktualizaci, protoze stara verze PHP uz nebude dostavat bezpecnostni aktualizace, a ja tak budu muset krome PHP upgradovat i framework. Jak udelam jeho aktualizaci na novejsi verzi ? Composer mi tohle jednoduse pomuze vyresit, bez composeru se takove veci resi dost tezko.
Nakonec i realny priklad - v jednom z minulych dilu mel kolega z komentaru problem s chybejici extension a verzi PHP. Pokud bych Jet instaloval pres composer, tak bych bylo i v definici composer.json jasne definovano, jakou verzi PHP a jake extensions framework ke svemu behu potrebuje. Nemohlo by se tak stat, ze mi instalace spadne na neznamem problemu, ale composer by mi okamzite a jasne sdelil co mi chybi.
To samozrejme nemeni nic na tom, ze autor do frameworku jiste vlozil hodne usili a casu, a za to ma rozhodne muj obdiv. Ale s vetsinou nazoru se bohuzel neztotoznuji
PS: jen tak pro zajimavost, nekolik pomerne velkych projektu, ktere udrzuji dodnes jedou na Zend Frameworku 1. Konkretne tedy na zf1-future forku, ktery je zpetne kompatibilni s puvodnim ZF1, zaroven ale bez problemu bezi na PHP 8.1. Predstava, ze bych mel Zend v kazdem projektu udrzovat sam, a distribuovat jej do vsech projektu bez composeru je skutecne desiva :)
Spíš jsem to špatně napsal.
Composer jako nástorj je fajn. Souhlas.
Vadím trend "nějak to poslepovat".
Ostatně Composer není jediný. PHP mělo a stále má PECL a PEAR.
A hlavně PECL jsem ve starších verzích PHP používal velice časti.
Tedy nic proti nástroji. Ale i dobrý nástroj se musí správně použít. A podle toho co jsem viděl je to někdy až extrémní. Viz to co píšu v článku.
Ale jak píše jiný kolega zde. Nad Composerem se ještě zamyslím ...
Díky za zpětnou vazbu.
Ja souhlasim s tim, ze "nejak to poslepovat" neni z pohledu aplikace idealni, nicmene moje zkusenost je takova, ze ten trend existoval vzdy, nemyslim si, ze by to byla zalezitost posledni doby. Ale ano, s tim, ze je ted k dispozici mnohem vice ruznych balicku je to asi viditelnejsi. Na druhou stranu jsou ty zavislosti alespon formalne zdokumentovane a nestava se, ze je jeden balicek v aplikaci nakopirovany trikrat v ruznych verzich, a kazda cast aplikace pouziva jinou :) Ale mozna mame jen jine zkusenosti, dost uz o tom
Jeste k PECLu - ten ja osobne nepovazuju za alternativu composeru (ani by byt nemel, protoze instaluje extensions napsane v C). Urcite se hodi na nektere konkretni veci, ktere je lepsi mit jako extension (pripadne je na tom zalozena jejich podstata, viz napr. Phalcon, myslim ze sveho casu experimentovali i s Twigem). Ale nelze jej brat jako alternativu composeru, je to nastroj, ktery ma jine vyuziti. Navic vyzaduje administratorsky pristup k serveru a musi extensions kompilovat primo na systemu, coz taky neni vzdycky mozne
Nedalo mi to a zkusil jsem si sesmolit, jak by vypadal TODO list v ideálním frameworku pro mě - který neexistuje a jmenuje se Unicorn:
https://github.com/kostislav/unicorn-todolist
Možná to pomůže osvětlit, proč mě Jet neláká, je to totiž v podstatě jeho opak :-)
- Composer balíček
- Žádné generování kódu, žádní wizardi (pokud potřebuju generovat boilerplate, tak mi chybí abstrakce)
- Templatovací jazyk (už jen kvůli escapování by default by se vyplatil) - tady jsem se nechal trochu unést a vymyslel vlastní kříženec mezi HAML a PHP
- Žádný ORM, jen pomocné funkce na SQL (dělat SELECT *, když ve skutečnosti potřebuju UPDATE, zase přijde jako zvěrstvo mně)
- Routování pomocí atributů
- Dependency Injection místo propletence statických volání
Budu rád, když se na kód lidi podívají a přispějou do diskuse, co se jim na něm líbí/nelíbí.
Přečteno 20 749×
Přečteno 18 600×
Přečteno 17 812×
Přečteno 17 563×
Přečteno 16 269×