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.