Vlákno názorů ke článku PHP Jet vs Laravel od Humanoid č. 1264054 - poruchový - No, já naopak Laravelu holduju (resp. produktům na...

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.

Protože napsat generika správně je docela výzva. A tak to (asi) odkládají.

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.